Phân biệt giữa phiên, dialog, các giao dịch và nhánh (branch)
Phiên, là thuật ngữ mô tả kết nối truyền thông giữa các user (ví dụ Tobias muốn gửi các luồng audio và video đến Theresa). Sự truyền thông này gọi là mức mang (bearer level): các gói RTP được gửi từ hai UE đến GGSN và GGSN sẽ thực hiện truyền các gói này một cách trực tiếp qua mạng. Phiên ở đây được thiết lập dựa trên SIP và báo hiệu SDP (giao thức mô tả phiên) được truyền trên mặt bằng điều khiển (control plane).
SIP dialog là báo hiệu giữa hai UE cần để thiết lập, điều chỉnh và giải phóng phiên đa phương tiện. Một dialog bắt đầu được thiết lập với yêu cầu INVITE và tồn tại đến hết kết
thúc phiên bằng phản hồi 200 (OK) cho yêu cầu BYE. Mọi dialog đều được nhận dạng bằng giá trị chứa ở mào đầu Call-ID và các nhãn (tag) ở mào đầu To và From của các yêu cầu SIP.
Một giao dịch SIP gồm một yêu cầu SIP và tất cả các phản hồi liên quan đến yêu cầu đó. Ví dụ để thiết lập phiên, UE của Tobias gửi một yêu cầu INVITE đến UE của Theresa và sẽ nhận được phản hồi 100 (Trying) từ P-CSCF, phản hồi 183 (Session in Progress) và 180 (Ringing) và 200 (OK) từ UE của Theresa. Như vậy có năm bản tin cho giao dịch đó, và cả năm bản tin đêu thuộc một dialog và có cùng số Csep.
Sau khi đã thiết lập được IPsec SAs, UE của Tobias sẽ đặt địa chỉ port đã được bảo vệ (1357) ở mào đầu Contact, đặt địa chỉ port đã được bảo vệ của nó tại mào đầu Via để có thể nhận được tất cả các phản hồi qua port được bảo vệ đó. Địa chỉ của port được bảo vệ của P- CSCF (7531) được đặt ở mào đầu Route đầu tiên để P-CSCF có thể nhận được tất cả các yêu cầu của UE qua cổng bảo vệ kết hợp bảo mật đó. Các mào đầu To và From không được dùng cho mục đích định tuyến mà nó chỉ có mục đích nhận dạng.
Khi nhận được yêu cầu, P-CSCF sẽ thực hiện: xóa mào đầu Route thứ nhất liên quan đến địa chỉ của P-CSCF, kiểm tra xem thông tin định tuyến chứa ở trong yêu cầu có theo đúng như thông tin định tuyến P-CSCF đã lưu trữ trong quá trình đăng ký hay không, đặt thêm địa chỉ của nó ở mào đầu Via trên cùng (sẽ giúp nhận được các gói phản hồi), thêm vào mào đầu Record-Route và đặt địa chỉ của nó vào đó (giúp tất cả các gói tin đều phải đi qua P- CSCF này), rồi gửi cho S-CSCF của Tobias.
S-CSCF của Tobias nhận được yêu cầu đó, nó sẽ xóa mào đầu Route liên quan đến địa chỉ của chính S-CSCF đó và thực hiện các thủ tục (*). S-CSCF tiếp tục định tuyến yêu cầu INVITE sang I-CSCF của Theresa (S-CSCF của Tobias dựa vào DNS để tìm địa chỉ của I- CSCF). Nếu S-CSCF biết được khả năng định tuyến của I-CSCF thì nó sẽ thêm địa chỉ của I- CSCF vào mào đầu Route và thực hiện gửi theo SIP, tuy nhiên vì S-CSCF của Tobias và I- CSCF của Theresa ở đây nằm ở hai mạng khác nhau nên S-CSCF sẽ không thực hiện được điều đó. S-CSCF của Tobias sẽ đóng gói UDP chứa yêu cầu INVITE đến I-CSCF.
I-CSCF mạng thường trú của Theresa cần tìm ra địa chỉ của S-CSCF sẽ phục vụ cho Theresa. Nếu Theresa chưa đăng ký, I-CSCF cần tìm ra địa chỉ của S-CSCF mặc định cho Theresa thuê bao dịch vụ như một user không đăng ký. Thông tin S-CSCF đã cấp cho user được lưu tại HSS, nếu có nhiều HSS thì I-CSCF cần truy vấn SLF để tìm ra HSS phù hợp chứa thông tin về S-CSCF cấp cho Theresa. Sau khi đã tìm ra địa chỉ S-CSCF, I-CSCF sẽ xóa địa chỉ của nó ở mào đầu Route và thêm vào yêu cầu INVITE địa chỉ đó ở mào đầu Route trên cùng, và thêm vào địa chỉ của I-CSCF vào mào đầu Via trên cùng. Vì nhiệm vụ của I- CSCF chủ yếu để tìm S-CSCF do vậy những gói tin sau đó không cần thiết phải qua I-CSCF mà sẽ tới thẳng S-CSCF, do đó I-CSCF sẽ không thêm địa chỉ của nó vào mào đầu Record- Route của yêu cầu INVITE này.
S-CSCF của Theresa nhận được yêu cầu INVITE, nó sẽ xóa địa chỉ của nó tại mào đâu Route, thêm vào địa chỉ của nó ở mà đầu Via, và S-CSCF sẽ thực hiện thông tin với AS của Theresa tương tự các thủ tục (**). Bằng việc này, S-CSCF sẽ thay request URI bằng địa chỉ liên lạc đã đăng ký có cổng server bảo vệ là 1006 (cũng chính là port của UE Theresa),
cùng với địa chỉ của P-CSCF (của Theresa) có được từ mào đầu Path của yêu cầu REGISTER của Theresa. S-CSCF sẽ đặt địa chỉ của P-CSCF vào mào đầu Route.
P-CSCF của Theresa nhận được yêu cầu INVITE nó sẽ xóa tất cả mào đầu Route và thêm địa chỉ của nó vào mào đầu Record-Route và Via, đồng thời thêm địa chỉ port bảo vệ (1511) vào yêu cầu INVITE rồi gửi đến UE của Theresa.
Sau khi UE của Theresa nhận được yêu câu INVITE nó sẽ lưu lại giá trị của mào đầu Contact và danh sách mào đầu Record-Route để phục vụ cho việc định tuyến các bản tin tiếp sau.
(*)Khi S-CSCF nhận được yêu cầu INVITE khởi tạo, nó sẽ so sánh thông tin các tiêu
chuẩn lọc. Nếu yêu cầu dịch vụ phù hợp với tiêu chuẩn nào đó, S-CSCF sẽ gửi yêu cầu đến AS của tiêu chuẩn ấy (tiêu chuẩn lọc được S-CSCF tải về từ HSS trong quá trình đăng ký và nhận thực, mã của tiêu chuẩn lọc có dạng XML và việc thực hiện tải về sẽ thông qua điểm tham chiếu Cx).
Bảng 2.3. Tiêu chuẩn bộ lọc của S-CSCF của Tobias
Element of filter criteria
Filter criterion #1 Filter criterion #2 Filter criterion #3
SPT: session
case
Originating Originating Terminating
SPT: public user identity Tel:+44-123-456- 789 sip: tobias@homel.fr tel:+44-123-456- 789 sip: tobias@homel.fr SPT: SIP method * INVITE SUBSCRIBE
Further SPT - - SIP header: event:
pres Application
server
sip:as1.homel.fr;lr sip:as2.homel.fr;lr sip:as3.homel.fr;lr
(**) Như vậy so sánh ta thấy rằng yêu cầu INVITE sẽ hợp với tiêu chuẩn lọc số 2 vì: có chứa sip:tobias@hom1.fr, và yêu cầu là INVITE. Sau đó S-CSCF thông tin với AS Hình 2.16:
Hình 2.16. Mào đầu giao dịch SIP [3] 2.4.4 Nén thông tin
Khi yêu cầu có tham số SigComp tức là nội dung của nó đã được nén (***). Ví dụ INVITE sip: [5555::5:6:7:8] : 1006;comp=SigComp SIP/2.0. Khi nhận được yêu cầu có nén này, P-CSCF sẽ thêm tham số com=sigcomp vào mào đầu Via của chính nó, để Theresa gửi tất cả các phản hồi cho yêu cầu (hoặc phản hồi) đã nén này. P-CSCF thêm tham số com=sigcomp vào mào đầu Record-Route để Theresa gửi tất cả các yêu cầu (với phản hồi cũng tương tự) cho dialog đã nén này qua P-CSCF đó.
(***) Các thuật toán nén thay thế các biểu thức dài được sử dụng thường xuyên trong các bản tin bởi các từ mã ngắn hơn. Bộ xử lý xây dựng một từ điển ánh xạ các biểu thức dài thành các từ mã ngắn và gửi từ điển này đến bộ giải nén, như được chỉ ra ở hình 2.17.
Hình 2.17. Quy luật SigComp [5] 2.4.5 Dàn xếp phƣơng tiện truyền thông[4 ] (adsbygoogle = window.adsbygoogle || []).push({});
Cơ chế SDP offer/answer cho phép hai UE thống nhất dùng tập các phương tiện truyền thông cho phiên và thống nhất dùng các mã hóa tương ứng được sử dụng cho mỗi loại phiên khác nhau. Quá trình dàn xếp truyền thông thực hiện qua mấy bước:
UE chủ gọi gửi SDP offer đầu tiên trong yêu cầu INVITE. SDP này chứa danh sách tất cả các loại phương tiện truyền thông (như audio, video, các ứng dụng nào đó như chat hoặc whiteboard) mà chủ gọi muốn dùng cho phiên này, SDP còn chứa danh sách các mã hóa khác nhau mà UE chủ gọi hỗ trợ cho việc mã hóa những phương tiện truyền thông khác nhau này.
UE bị gọi sẽ phản hồi bằng SDP answer đầu tiên, ở đó nó có thể từ chối một số loại phương tiện truyền thông vừa được đề xuất ở SDP offer. UE đó cũng có thể bỏ đi những mã mà nó không hỗ trợ.
Sau khi nhận được SDP trả lời đầu tiên, UE chủ gọi cần quyết định sẽ dùng mã hóa nào. Nó sẽ gửi một đề xuất thứ hai đến UE bị gọi, sẽ chỉ ra mã nào sẽ được dùng cho loại truyền thông tương ứng sẽ dùng trong phiên.
UE bị gọi sẽ chấp nhận đề xuất thứ hai và gửi lại UE chủ gọi một xác nhận. (hình 2.18).
Hình 2.18. SDP offer/answer trong IMS [4]
SIP cho phép thiết lập phương tiện truyền thông sau khi offer/anser exchange đầu tiên (ở SDP answer có nhiều mã như ví dụ trên thì sự thiết lập phương tiện sẽ thực hiện ở exchange thứ hai tức là sự chuyển thứ hai).
Sau Khi UE Theresa nhận được SDP offer thứ hai này, nó xác định được cả hai đã ứng thuận dùng các luồng truyền thông và mã phù hợp tưng ứng, và phản hồi UE Tobias một SDP answer có nội dung giống SDP offer thứ hai trên (tất nhiên mào đầu SDP answer thứ hai này sẽ giống SDP answer đầu tiên).
2.4.6 Dự trữ tài nguyên – Resource Reservation
Các phiên giữa Tobias và Theresa được đàm phán nhờ báo hiệu SDP trên SIP giữa hai UE. Các signalling PDP context được dùng để chuyển báo hiệu SIP, còn các media PDP context dùng để chuyển các luồng phương tiên truyền thông. Thủ tục thiết lập media PDP context được gọi là Resource Reservation.
Thiết lập media PDP context là thủ tục chiếm một khoảng thời gian nào đó và nó có thể không thực hiện được nếu liên kết vô tuyến bị thiếu tài nguyên truyền dẫn (thiếu kênh truyền hoặc chất lượng kênh không đủ để truyền). Vì thế UE của Theresa sẽ không có hồi chuông khi chưa xác định được Resource Reservation bên chủ gọi đã hoàn thành tốt. Cơ chế thực hiện điều này theo:
UE Tobias gửi yêu cầu SIP UPDATE đến UE bị gọi khi Resource Reservation đã thành công ở UE của Tobias;
UE Theresa sẽ không có chuông cho đến khi nó nhận được yêu cầu SIP UPDATE của UE Tobias.
Ta xét trường hợp khi UE không hỗ trợ cơ chế điều kiện (precondition) (giả sử UE của Theresa không hỗ trợ cơ chế này). Khi đó không cần biết đến tài nguyên mặc định (Resource
Reservation) của UE Tobias có thành công hay không, UE của Theresa cũng có hồi chuông và cuộc gọi bắt đầu. Ở đây ta thấy được sự thành công cuộc gọi ở mức báo hiệu nhưng thông tin trên mặt bằng truyền thông media thì lại không đạt được, kết quả là cuộc gọi vẫn không thành công (nếu UE Tobias vẫn chưa thực hiện được Resource Reservation). Khi một yêu cầu từ UE có hỗ trợ cơ chế này, mào đầu của nó có tham số precondition: Require: see-agree, precondition. Nếu UE tại đó không hỗ trợ precodition thì nó sẽ phản hồi bằng 420 (Bad Extenstion) cho INVITE.
Hình 2.19. SDP offer/answer và các tiền điều kiện khi thiết lập phiên SIP [7]
Sau khi nhận được SDP answer trên trong phản hồi 183 ở trên, UE Tobias gửi yêu cầu PRACK, quá trình tiếp theo hoàn toàn giống như mục 2.4.5, nhưng có thêm vào các mào đầu liên quan đến qos precondition đối với mỗi luồng truyền thông tương ứng với mỗi dòng m. Như vậy khi cả hai phía đã thực hiện Resource Reservation (*) và cả hai đều xác định được sự thành công đó thì cuộc gọi bắt đầu thực hiện được với tín hiệu chuông.
(*) Resource Reservation thành công - GPRS đã thiết lập được các media PDP context –
Packet Data Protocol context sơ cấp và thứ cấp. Kích hoạt PDP context sơ cấp tức là thiết lập kết nối logic giữa UE và GGSN theo QoS, sau khi thực hiện điều này thì UE có thể gửi các gói IP qua môi trường không dây. PDP context thứ cấp được kích hoạt sẽ cho phép UE
2.4.7 Điều khiển phƣơng tiện truyền thông
PDP
GGSN
(4) Media PDP Context establishment including token
(1) INVITE / 183
(2) P-CSCF requests / gets from PDF the media
authorization token
(5) GGSN queries PDF (3) INVITE / 183 media
authorization token
(6) GGSN cut through media (adsbygoogle = window.adsbygoogle || []).push({});
P-CSCF
Hình 2.20. Truyền tài thông tin trao quyền media [3] 2.4.8 Sự trao đổi thông tin liên quan đến tính cƣớc cho phiên [12];[17]
Kể từ khi dữ liệu lưu lượng truyền thông được truyền qua PDP context, GGSN sẽ thực hiện đo đạc tính cước lượng dữ liệu truyền qua PDP context. Những bản tin tính cước được GGSN ghi dựa theo GPRS Charing ID (GCID) được tạo bởi mạng truy nhập. GGSM sẽ gửi các GCID qua điểm tham chiếu Go để tới P-CSCF. P-CSCF sẽ tính cước các luồng media đã được truyền trên các media PDP context đã thiết lập, P-CSCF sẽ tạo IMS Charing ID (ICID) dựa vào GCID (có thể hình dung rằng GCID tính cước lưu lượng còn ICID tính cước tổng
dựa vào từng loại lưu lượng cho audio hay video thì cước sẽ khác nhau). Sau đó P-CSCF gửi
ICID về CCF mạng thường trú của user (P-CSCF tải về địa chỉ của CCF từ S-CSCF nhờ mào đầu P-Charing-Address, S-CSCF có được địa chỉ của CCF từ HSS nhờ thông tin của gói Diameter SAA khi user thực hiện đăng ký).
Chú ý đối với yêu cầu INVITE, khi S-CSCF nhận được nó, S-CSCF sẽ truy vấn chuẩn bộ lọc để tìm được AS phục vụ user và gửi yêu cầu INVITE đến AS đó như đã đề cập. Sở dĩ phải truy vấn AS vì AS chứa cơ sở dữ liệu phục vụ dịch vụ - tiếng chuông chẳng hạn. Nếu yêu cầu INVITE này được thiết lập khi Resource Reservation đã đạt được – vì yêu cầu này được thiết lập ở giao dịch thứ hai chẳng hạn – khi user muốn thêm một dịch vụ nữa vào phiên. Nếu vậy thì các thủ tục đối với thông tin cước đều được thực hiện như trên.
2.4.9 Ví dụ một số trƣờng hợp Đối với tính cƣớc offline Khi UE nằm ở mạng tạm trú:
Khi UE nằm ở mạng thƣờng trú:
Hình 2.22. UE nằm ở mạng thƣờng trú thiết lập phiên. [7] 2.4.10 Giải phóng phiên
Giả sử Theresa là người muốn kết thúc phiên, cô ấy thực hiện bấm nút kết thúc cuộc gọi, UE Theresa sẽ gửi yêu cầu BYE. L úc n ày, UE Tobias cũng sẽ bỏ PDP context của nó ngay khi nhận được yêu cầu BYE. Nó sẽ phản hồi bằng 200 (OK). Các S-CSCF và AS cũng xóa bỏ các thông tin liên quan đến phiên và dialog.
Trường hợp P-CSCF thực hiện giải phóng phiên đã khởi tạo - khi nó nhận ra UE đã bị mất sóng và không thể kết nối với mạng được, khi đó P-CSCF cần gửi yêu cầu BYE đến phía UE ở xa (UE không bị mất sóng).
Trường hợp user dùng hình thức tính cước online – thuê bảo trả trước, đang thực hiện phiên dịch vụ thì tài khoản bị hết tiền thì S-CSCF sẽ thực hiện giải phóng phiên đã khởi tạo. Khi đó S-CSCF sẽ gửi yêu cầu BYE tới UE của user đó.
Mục 2.4.10 với trình tự giải phóng phiên và các thông tin liên quan đến tính cước offline trong IMS đã kết thúc chương II của Luận văn.
Chương III; là chương quan trọng mà Luận văn tập trung nghiên cứu với các dịch vụ trên nền IMS đã, đang và sẽ được các nhà khai thác mạng trên thế giới áp dụng. Lượng kiến thức được trình bày ở chương này được rút ra từ các nghiên cứu, triển khai các dịch vụ IMS trên nền NGN tại Việt Nam.
Chƣơng 3: CÁC DỊCH VỤ TRIỂN KHAI TRÊN NỀN IMS
3.1 CHẤT LƢỢNG DỊCH VỤ TRONG IMS
IMS hỗ trợ các chế độ QoS end-to-end (được mô tả ở 3 GPP TS 23.207-End-to-end QoS concept and architecture- [11]: Các đầu cuối có thể trực tiếp dùng các giao thức dành riêng cho tài nguyên lớp liên kết, RSVP (Resource ReSerVation Protocol), hoặc cấu trúc Diffserv.
3.1.1 Giới thiệu
Các đầu cuối cần ánh xạ các luồng truyền thông của một phiên vào các luồng dành cho tài nguyên (Resource Reservation). Một đầu cuối thiết lập một luồng audio và một luồng video có thể yêu cầu một luồng Reservation đơn (cho cả audio và video) hoặc yêu cầu hai