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ẽ tuân 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, luôn đượ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 (adsbygoogle = window.adsbygoogle || []).push({});
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 thị;
Presence Server - Quản lý thông tin hiển đã được các PUA tải lên và xử lý các yêu cầu thuê bao hiển thị, và cung cấp thông tin hiển thị đến server;
Presentity Presence Proxy - Nhận dạng Presence Server;
3.2.2 Sự đăng ký Watcher
User Alice có thể đảm nhận làm một watcher. Khi Alice bắt đầu dùng ứng dụng hiển thị, cô sẽ đăng ký các thông tin hiển thị về các thực trạng hiện tại của cô.
Mặc dù IMS cho phép Alice đăng ký các hiển thị mà cô dùng riêng, nhưng trong hầu hết các trường hợp, watcher luôn đăng ký toàn bộ danh sách hiển thị của họ từ RLS của mạng thường trú.
Hình 3.8 là một quá trình đăng ký dịch vụ hiển thị. Ứng dụng Watcher trong UE của Alice sẽ gửi một yêu cầu SUBSCRIBE đến danh sách của cô (có địa chỉ: sip:alice- list<9home.net). Yêu cầu SUBSCRIBE (1) chứa trường mào đầu Event có giá trịdanh sách sự kiện (eventlist) để chỉ ra rằng đăng ký được địa chỉ đến một danh sách chứ không phải là địa chỉ đến một sự hiển thị riêng nào. S-CSCF nhận được yêu cầu (2), nó sẽ đánh giá với tiêu chuẩn bộ lọc khởi tạo. Một trong những tiêu chuẩn này chỉ ra rằng yêu cầu (3) nên được gửi
tiếp đến một Application Server thực hiện RLS. Sau khi RLS thẩm tra nhận dạng của thuê bao và trao quyền thuê bao thì RLS gửi phản hồi 200 (OK) (4). RLS cũng gửi một yêu cầu NOTIFY (7) (các phản hồi và yêu cầu này chưa chứa bất cứ thông tin hiển thị nào tại thời điểm hiện tại). RLS thuê dùng tất cả các hiển thị đã được lên danh sách trong resource list. Khi có đủ thông tin cần thiết, RLS sẽ tạo ra một yêu cầu NOTIFY khác (13) chứa một tài liệu hiển thị có toàn bộ thông tin hiển thị mà RLS đã nhận được từ PUA.
Hình 3.8. Đăng ký Watcher cho danh sách hiển thị [17]
Hình 3.9 chỉ ra RLS thuê dùng một sự hiển thị chứa trong resource list. RLS gửi một yêu cầu SUBSCRIBE (1) đến địa chỉ của sự hiển thị trong danh sách. Yêu cầu chứa một mào đầu Event có giá trị presence. Yêu cầu được gửi forward tới I-CSCF trong mạng có PA (qua S-CSCF trong mạng thường trú RLS). I-CSCF sẽ truy vấn HSS để tìm ra S-CSCF đã cấp cho sự hiển thị, rồi forward yêu cầu SUBSCRIBE (5) đến S-CSCF đó. S-CSCF đó sẽ đánh giá tiêu chuẩn lọc ban đầu để tìm ra PA, rồi S-CSCF cần forward yêu cầu này đến PA đó (6). Sau khi gửi phản hồi 200 (OK) (7), PA sẽ gửi yêu cầu NOTIFY (11) chứa thông tin hiển thị.
Hình 3.9. RLS đăng ký hiển thị [15] 3.2.3 Sự công bố hiển thị [18]
Khi ứng dụng hiển thị IMS bắt đầu, nó sẽ công bố thông tin hiển thị của thực thể hiển thị hiện tại. Đầu cuối IMS gửi yêu cầu PUBLISH (1) chứa mào đầu Event có giá trị presence. S-CSCF nhận được yêu cầu (2) và đánh giá sự hiển thị với tiêu chuẩn lọc khởi tạo. Tiêu chuẩn lọc khởi tạo sẽ chỉ ra yêu cầu này nên được forward đến PA lưu trữ thông tin hiển thị của thực thể hiển thị. PA sẽ trao quyền publication và gửi một phản hồi 200 (OK) (4).
3.3 DỊCH VỤ NHẮN TIN
Có hai chế độ vận hành của dịch vụ nhắn tin tức thời (pager-mode và session-base) phụ thuộc vào đó là các tin nhắn tức thời đơn hay nó là một phần của phiên.
Tin nhắn tức thời pager-mode được gửi dưới dạng các bản tin riêng biệt, không liên quan đến những bản tin trước và sau nó. Tin nhắn tức thời loại này tương tự với SMS (Short Message Service) trong mạng Cellular.
Tin nhắn tức thời session-base được gửi trong một phiên đang tồn tại, được thiết lập cùng với một yêu cầu INVITE (chế độ này giống như dịch vụ chat mà ta đã biết đối với mạng Internet).
3.3.1 Nhắn tin tức thời Pager-mode trong IMS
Dịch vụ nhắn tin tức thời page-mode được giới thiệu lần đầu ở Release 5 của 3GPP. 3GPP TS 23.228 [11] đã chứa các yêu cầu cho các dịnh vụ ứng dụng và các S-CSCF có thể gửi thông tin dạng văn bản tới đầu cuối IMS. Các giới thiệu của 3GPP TS 23.218 [16] có hỗ trợ cho sự mỏ rộng phương thức MESSAGE. Các đầu cuối IMS được uỷ quyền để triển khai phương thức MESSAGE (RFC 3428 ) và để cho phép sự triển khai đó được là một đặc tính tuỳ chọn đối với các S-CSCF và các AS. Tất nhiên các tin nhắn tức thời pager-mode sẽ bị ràng buộc (ví dụ về kích thước bản tin).
Mục đích chính của tin nhắn tức thời pager-mode là cho phép S-CSCF hoặc AS gửi các bản tin khẩn ngắn đến đầu cuối IMS. Khi phương thức MESSAGE được triển khai trên các đầu cuối IMS, các user có thể gửi được những tin nhắn tức thời pager-mode đến những user khác. Hình 3.11 sau là một ví dụ cho tin nhắn tức thời pager-mode.
IMS Terminal#1 P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF IMS Terminal#2 Originating Visited Network Originating
Home Network Terminating Home Network
Terminating Visited Network (1) MESSAGE (2) MESSAGE (3) MESSAGE (6) MESSAGE (7) MESSAGE (8) MESSAGE Evaluation of initial filter criteria (4) Diameter LIR (5) Diameter LIA Evaluation of initial filter criteria (9) 200 OK Alert user (10) 200 OK (11) 200 OK (12) 200 OK (13) 200 OK (14) 200 OK
Hình 3.11. Nhắn tin tức thời pager-mode trong IMS [18]
Hình 3.12 làm một ví dụ cho dịch vụ cung cấp bằng phương thức MESSAGE. Trong đó AS đảm nhận vai trò người điều khiển của hệ thống voicemail. AS sẽ chú ý để biết được khi nào user đăng nhập thành công vào IMS, vì thế AS có thể báo cho user biết rằng mạng có
các voicemail chờ được đem về. Dịch vụ được triển khai: user đăng ký với IMS như thường lệ, (1)-(20) trong hình 5.6; Khi sự đăng ký hoàn thành, S-CSCF sẽ đánh gia tiêu chuẩn lọc khởi tạo; Một trong các tiêu chuẩn lọc khởi tao sẽ chỉ cho S-CSCF nên thực hiện đăng ký bên thứ 3 (third-party registration)với một AS riêng; Sau đó S-CSCF gửi yêu cầu third-party REGISTER (21) đến AS đã được chỉ định. Mục đích của yêu cầu REGISTER third-party này không phải để đăng ký user với AS, mà là để chỉ cho AS rằng user vừa mới đăng kí đến S- CSCF; Nhận được yêu cầu REGISTER này (21), AS sẽ tạo ra một yêu cầu MESSAGE (23) chứa vài thông tin văn bản, cũng có thể là link đến một địa chỉ website nắm giữ bản sao của những tin nắm đang chờ được lấy về (ví dụ những tin nhắn offline) hay các thông tin thích hợp khác mà dịch vụ hộ trợ; Yêu cầu MESSAGE được gửi forward qua S-CSCF và P-CSCF như bất kỳ bản tin SIP nào khác. (adsbygoogle = window.adsbygoogle || []).push({});
Hình 3.12. Ví dụ của một dịch vụ cung cấp các tin nhắn tức thời pager-mode[18] 3.3.2 Nhắn tin tức thời Session-base trong IMS
Dịch vụ nhắn tin tức thời session-base được giới thiệu trọng Release 6 của 3GPP. Chỉ tiêu kỹ thuật của giao thức đã được chi tiết hoá mô tả trong 3GPP TS 24.247 [10] (Messaging
service using the IP Multimedia Core network subsystem Stage 3-Internet). Nhắn tin tức thời
session-base
Giao thức MSRP (Message Session Relay Protocol) được dùng để truyền tải các bản tin khẩn Session-base (*). Trong IMS, MSRP được triển khai trên các đầu cuối IMS. MRFP
cũng có thể triển khai MSRP. Có hai sơ đồ khác nhau cho việc thiết lập một phiên của các tin nhắn tức thời. Sơ đồ đầu tiên chúng ta mô tả ở hình 3.13:
IMS Terminal#1 P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF IMS Terminal#2 Originating Visited Network Originating
Home Network Terminating Home Network
Terminating Visited Network (1) INVITE (3) INVITE (5) MESSAGE (9) INVITE (11) INVITE (13) INVITE Evaluation of initial filter criteria (7) Diameter LIR (8) Diameter LIA Evaluation of initial filter criteria Alert user (2) 100 Trying (4) 100 Trying (6) 100 Trying (10) 100 Trying (12) 100 Trying (14) 100 Trying (15) MSRP: VISIT (16) MSRP: 200 OK (17) 180 Ringing (18) 180 Ringing (19) 180 Ringing (20) 180 Ringing (21) 180 Ringing (22) 180 Ringing (29) ACK (30) ACK (31) ACK Accept Session (23) 200 OK (24) 200 OK (25) 200 OK (26) 200 OK (27) 200 OK (28) 200 OK (32) ACK (33) ACK (34) MSRP: SEND (35) MSRP: 200 OK (36) MSRP: SEND (37) MSRP: 200 OK
Hình 3.13. Các tin nhắn tức thời Session-base: phiên MSRP end-to-end [18]
Trong hình 3.14, một đầu cuối IMS thiết lập một phiên đến điểm cuối khác. Các bản tin SIP sẽ đi qua các nút IMS (các P-CSCF, các S-CSCF, hoặc có thể qua các AS,…). Sau đó MSRP được gửi end-to-end. Khác với sự thiết lập phiên cơ bản là ở đây không có các phản hồi 183, yêu cầu PRACK hoặc yêu cầu UPDATE vì REGISTER ở MSRP chỉ chứa một luồng truyền thông được công khai trong SDP.
Hình 3.14. Chat Server - hội nghi session-base multi-part [13]
Trong sơ đồ thứ hai, MRFC và MRFP là những trung gian trong mạng, sẽ tạo điều kiện cho việc tạo các sự kiện tính cước theo kích thước của bản tin hoặc theo bất kỳ nội dung thêm nào trong các bản tin MSRP SEND. Lý do khác là MRF đang đảm nhận làm một đơn vị hội nghị nhiều bên cho các tin nhắn tức thời (ví dụ chat room). Hình 3.14 chỉ ra ví dụ của một hội nghị đa bên đó. Ở đây chúng ta cho rằng các user tham gia vào hội nghị đều thuộc cùng một mạng, mặc dù họ có thể được cấp các S-CSCF và P-CSCF khác nhau. Trong hình đó, đầu tiên user gửi một yêu cầu INVITE (1), yêu cầu đó sẽ đi qua P-CSCF và S-CSCF đã cấp cho user đó. S-CSCF sẽ gửi forward yêu cầu INVITE (5) đến MRFC. MRFC điều khiển MRFP nhờ giao thức H.248, sẽ tạo một sự kết thúc mới cho user. MRFC sẽ khởi tạo một kết nối TCP đến đầu cuối IMS và gửi một yêu cầu MSRP VISIT (8) đến đó. Đầu cuối IMS nhận được yêu cầu MSRP VISTIT sẽ phản hồi bằng một bản tin MSRP 200 (OK) (9). H.248 thực