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 ]
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. Q 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.
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ó chng 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 chng 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, q trình tiếp theo hồn tồ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 chng.
(*) 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 gủi các gói IP tiếp theo nhưng với QoS khác.
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
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 – th 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 luồng Reservation (một cho audio, một cho video). Việc yêu cầu đó có thể gồm việc tạo ra một context PDP thứ cấp hoặc việc gửi những gói PATH RSVP.
P-CSCF hướng dẫn đầu cuối thực hiện Resource Reservation bằng cách dùng các SRF (Single Reservation Flow) của SDP Grouping Framwork.
SDP Grouping Framework (RFC 3388) cho phép nhóm các luồng truyền thơng và mơ tả ngữ nghĩa của nhóm. Ví dụ, LS (Lip Synchronization) chỉ ra rằng play-out của các luồng truyền thông cần phải được đồng bộ. LS được dùng để nhóm một luồng audio và một luồng video (hình 3.1). (2) INVITE (token) (3) PDP Conte nt A ctivatio n (token) (1) INVITE P-CSCF/PDF GGSN
(2) INVITE (token) (5) PDP Conte nt A ctivatio n (token) (2) INVITE P-CSCF/PDF GGSN (4) 183 Session Progress
(token) (3) 183 Session Progress
Hình 3.2. P-CSCF thêm SRF vào phản hồi 183 [3]
3.1.2 Reservation của các đầu cuối
Các đầu cuối dùng thông tin SRF trong các mô tả phiên để xác định số luồng Resource Reservation (tài nguyên mặc định) cần được thiết lập. Khi mạng truy nhập là GPRS, mỗi luồng Resource Reservation là một PDP Context (ngữ cảnh PDP, hoặc dạng PDP).
Một đầu cuối thiết lập một PDP để trao đổi báo hiệu SIP sau khi thực hiện liên kết GPRS (hình 3.3). Thơng tin được mạng lưu về việc PDP này chứa địa chỉ IP của đầu cuối và các đặc tính QoS của PDP chứa loại lưu lượng. Có bốn loại lưu lượng: Best Effort,
Interactive, Streaming, và Conversational. PDP dùng cho báo hiệu SIP luôn thuộc loại Conversation.
Hình 3.3. Sự kích hoạt PDP Context [15]
Các đầu cuối IMS thiết lập thêm các PDP Context để gủi và nhận phương tiện truyền thơng (hình 3.4). Số PDP Context được thêm (các PDP Context thứ cấp) tùy thuộc vào các giới thiệu nhận được từ P-CSCF ở các dòng SRF a=group. Các PDP Context thứ cấp dùng
cùng địa chỉ IP như chức năng quyết định chính sách (PDP Context sơ cấp), nhưng chúng có thể sẽ chứa những đặc tính QoS khác nhau.
Hình 3.4. Kích hoạt PDP context thứ cấp [15]
3.1.3 Sự trao quyền bởi Mạng
Các đầu cuối có thẻ trao quyền nhận được từ PDF trong các gói tin Activate Secondary
PDP Context Request – yêu cầu PDP Context thứ cấp kích hoạt. SGSN nhận được gói tin này
và dùng MAP kiểm tra thông tin thuê bao của User trong HSS. Nếu đầu cuối yêu cầu nhiều băng thông hơn so với thuê bao của User cho phép (thuê bao mà nhà cung cấp cho phép người dùng sử dụng dịch vụ), SGSN sẽ gửi một yêu cầu tạo PDP Context đến GGSN. Gói tin này chứa thẻ trao quyền nhận được ở gói tin (1). GGSN nhận được thẻ này ở ở gói tin (2) của hình 3.5 và gửi nó đến PDF trong bản tin COPS REQ (3). PDF phản hồi bằng bản tin DEC (4) có chứa các đặc tính QoS và các nhận dạng những luồng gói dùng PDP Context.
Hình 3.5. Mạng trao quyền QoS [16]
GGSN dùng các bộ lọc gói để đảm bảo rằng chỉ các luồng gói đã trao quyền là được gửi. Các nhận dạng các luồng gói gồm năm mức chứa các địa chỉ nguồn đích, các cổng nguồn và đích. Ví dụ, một PDP Context có thể chỉ mang lưu lượng gửi đến địa chỉ IP của UE ở xa. Nếu GGSN không triển khai loại bộ lọc này thì user có thể dùng một PDP Context đã trao quyền bởi PDF cho một mục đích khác.
GGSN sau khi nhận được bản tin DEC (4), nó trả lại một bản tin RTP (5) đến PDF chỉ ra rằng nó sẽ tn theo chính sách của PDF. Sau đó, nó sẽ nhận thực PDP Context đã yêu cầu (6).
3.1.4 QoS trong mạng [16]
GGSN nhận được lưu lượng từ một đầu cuối trên PDP Context, sẽ phân cơng nó một DSCP hợp lý và gửi DSCP đó vào mạng theo cấu trúc DiffServ (hình 3.6). DSCP tương ứng với một PDP Context riêng biệt được phân cơng dựa trên các luật cấu hình tĩnh trong GGSN. Khi RSVP được dùng, GGSN có thể dùng thơng tin mang trong báo hiệu RSVP để quyết định DSCP nào sẽ được dùng.
DiffServ Network
GGSN PDP Context
Hình 3.6. Cấu trúc DiffServ thơng qua các DSCP nhờ GGSN [3]
3.2 DỊCH VỤ HIỂN THỊ
Hiển thị là dịch vụ thể hiện hồ sơ động của một user tại các thực thể hiển thị, trình bày thơng tin về chính user đó hoặc cả thơng tin chia sẻ khác. Hiển thị có thể được xem như trạng thái của user A đối với các user khác hoặc trạng thái của các user khác đối với user A. Trạng thái có thể chứa các thông tin như thông tin cá nhân và thông tin về trạng thái thiết bị, khả năng của thiết bị đầu cuối, phương thức liên lạc tương thích đối với dịch vụ mà user A muốn dùng để thông tin với các user khác (voice, video, message, game…)
Thông tin hiển thị mang tính cá nhân, ln được liên kết riêng với từng user. Nó chỉ cho người đang khởi tạo cuộc gọi biết được trạng thái của các user khác, cho phép có một sự lựa chọn hình thức thơng tin với các user đó, điều đó khiến cho việc điều khiển cuộc gọi được linh hoạt, thuận tiện và hiệu quả.
3.2.1 Cấu trúc hệ thống liên quan đến dịch vụ hiển thị trong IMS
Hình 3.7 mơ tả sơ đồ cấu trúc hệ các thực thể liên quan đến vấn đề dịch vụ hiển thị trong IMS. Trong đó đầu cuối IMS thực hiện vai trị là thực thể giám sát và là thực thể thực hiện hiển thị (PUA – Presence User Agent). Presence Agent (PA) là server ứng dụng nằm ở mạng thường trú. Trong IMS, PA cũng đóng vai trị làm Presence Server. Resource List Server (RLS) cũng được triển khai trên Server ứng dụng (AS). AS cung cấp nhiều dịch vụ và nó có thể đảm nhận làm một thực thể giám sát Watcher các thông tin hiển thị.
` Access Network Access Network PUA Watcher PUA Watcher Peu=Pw=Gm HSS SLF P-CSCF P-CSCF Watcher (AS)
PA (AS) PUA (AS) RLS (AS)
I-CSCF S-CSCF Pen ISC Pi=ISC Pi=ISC Pw=ISC Px=Cx Px=Cx Px=Cx Px=Cx P w =M w Ut
Hình 3.7. Cấu trúc hệ thống hiển thị của IMS [3]
Giao diện Pen đáng chú ý vì nó cho phép AS hoạt động như PUA thực hiện công bố thông tin hiển thị đến PA. PUA đạt được thông tin hiển thị từ HLR, MSC/VLR, SGSN, GGSN, hoặc S-CSCF.
Giao diện Ut kết nối giữa đầu cuối IMS và bất kỳ Application Server nào, như PA hoặc RLS. Ut cho phép user lấy được cấu hình của danh sách hiển thị, hoặc trao quyền giám sát…Giao diện này dùng giao thức XCAP (XML Configuration Access Protocol).
Presentity - Thực thể hiển thị, cung cấp thông tin hiển thị cho một dịch vụ hiển thị; Watcher – Các thực thể yêu cầu thông tin hiển thị
Presence Agent – Có khả năng lưu trữ dữ liệu thuê bao và tạo các thông báo;
Presence User Agent – Dùng thông tin hiển thị dành cho Presentity và công bố thông tin hiển