Phân hệ IMS trong kiến trúc NGN

Agent (UA) và các thành phần trung gian (là các servers). Một UA là một điểm cuối của một cuộc gọi, nó gửi và nhận các yêu cầu và đáp ứng SIP, nó là điểm kết thúc của các dòng đang phương tiện nên thường nó còn được gọi là UE. UA bao gồm 2 phần: - User Agent Client (UAC): còn được gọi là Calling Agent User là một ứng dụng có chức năng khởi tạo yêu cầu SIP. - User Agent Server (UAS): còn gọi là Called Agent User tiếp nhận, gửi trả lại, từ chối yêu cầu và gửi đáp ứng về cho user gửi yêu cầu. Hình2.9: Các thành phần SIP. Các thành phần trung gian là các thực thể chuyển các bản tin SIP đến đích, chúng được sử dụng để định tuyến và gửi lại các yêu cầu. Những server này bao gồm: Proxy server: nhận và chuyển tiếp các yêu cầu. Nó có thể biên dịch và viết lại bản tin mà không ảnh hướng đến trạng thái yêu cầu. Một proxy server có thể gửi một yêu cầu đến một số địa điểm tại cùng một thời điểm – đặc điểm này gọi là “forking proxy”. Có 3 loại proxy server: - dialog-statefull proxy: một proxy là dialog-statefull nếu nó duy trì trạng thái cuộc gọi từ yêu cầu khởi tạo (INVITE) đến yêu cầu kết thúc (BYE) - transaction-statefull proxy: là một proxy nếu nó có cơ cấu chuyển dịch trạng thái client và server trong quá trình yêu cầu - stateless proxy: là một proxy mà chuyển tiếp mọi yêu cầu và đáp ứng mà nó nhận được. Redirect server: ánh xạ địa chỉ yêu cầu thành đại chỉ mới và trả lại địa chỉ này về client. Nó không khởi tạo một yêu cầu SIP và không chuyển các yêu cầu tới các server khác, không giống như proxy server. Location server: là server giữ vị trí của user. Registrar server: là server chấp nhận các yêu cầu REGISTER. Nó được sử dụng để tiếp nhận các đăng ký từ UA để cập nhật thông tin về vị trí của chúng. Ngoài ra, còn có thêm 2 server được sử dụng để cung cấp dịch vụ cho các SIP user: Application server và Back-to-back-user-agent (B2BUA) 2.3.2. Giao thức hỗ trợ chứng thực, cấp quyền, tính cước (AAA). Diameter dựa trên RFC 3588 được chọn là giao thức AAA trong mạng IMS. Diameter là một giao thức cho việc nhận thực, cấp phép, và tính cước (AAA), được xây dựng dựa trên giao thức RADIUS - ban đầu được sử dụng cung cấp AAA, cho môi trường dial-up và truy nhập server đầu cuối. Và khi các mạng mới ra đời, AAA Working Group đưa ra thêm một số yêu cầu cho AAA để có thể áp dụng và mạng truy nhập của nhìêu nhóm khác nhau: - IP Routing for Wireless/Mobile Hosts WG (MPBILEIP) [RFC2977] - Network Access Server Requirements WG (NASREG) [RFC3169] - Roaming Operations WG (ROAMOPS) [RFC2477] - Telecommunications Industry Association (TIA) Giao thức Diameter thực ra được chia làm 2 phần: giao thức cơ sở Diameter và các ứng dụng Diameter. Giao thức cơ sở cung cấp các yêu cầu tối thiểu của một giao thức AAA, phát các đơn vị dữ liệu Diameter, khả năng thương thảo, xử lý lỗi, … Ứng dụng Diameter dựa trên giao thức cơ sở, định nghĩa các chức năng ứng dụng riêng. Hiện nay, một số ứng dụng Diameter đã được đưa ra: Mobile IP, NASREQ, Extexsible Authentication Protocol (EAP) , Diameter credit control và Diameter SIP application. Giao thức cơ sở Diameter sử dụng cả hai giao thức truyền tải TCP và SCTP. Tuy nhiên STCP. Tuy nhiên SCTP được chọn nhiều hơn, nó thể chia nhiều luồng độc lập vào trong một kết nối SCTP, thay vì giữ tất cả các luồng đó riêng như trong TCP. Cả IPsec và TLS đều được sử dụng cho bảo mật kết nối. IMS sử dụng Diameter trong nhiều giao diện, mặc dù vậy các giao diện này có thể sử dụng các ứng dụng Diameter khác nhau. Ví dụ IMS sử dụng một Diameter ứng dụng trong quá trình thiết lập cuộc gọi nhưng lại sử dụng một Diameter ứng dụng khác trong tính cước. 2.3.3. Các giao thức khác. Bên cạnh SIP và Diameter, IMS còn sử dụng nhiều giao thức khác như: Giao thức dịch vụ chính sách mở thông thường COPS (Common Open Policy Service) được dùng để truyền tải chính sách giữa các điểm quyết định dịch vụ PDPs (Policy Decision Points) và các điểm thực hiện chính sách ( Policy Enforcement Points). H.248 (ITU-T khuyến nghị H.248) được sử dụng bởi các nút báo hiệu để điều khiển các nút trong mặt phẳng media. RTP (Real-Time Transport Protocol, RFC 3550) và RCTP (RTP Control Protocol, RFC 3550) dùng để truyền tải media như video và audio… CHƯƠNG 3: CÁC DỊCH VỤ ỨNG DỤNG TRONG IMS. Với các mạng hiện nay, rất nhiều dịch vụ có thể được cung cấp tốt ở ngoài IMS. Hai user có thể thiết lập một video conference trên miền chuyển mạch kênh và gửi các tin nhắn đa phương tiện sử dụng MMS. Vào cùng một thời điểm họ có thể lướt web và kiểm tra email trên miền chuyển mạch gói (như GPRS). Họ thậm chí có thể truy nhập một server hiện hành trên Internet để kiểm tra xem có nhiều người sẵn sàng muốn tham gia một video conference hay không. Cho rằng tất cả các dịch vụ được mô tả được cung cấp với một chất lượng dịch vụ tốt mà không có IMS. Vậy thì IMS thực sự cung cấp cái gì? Trước tiên, IMS cung cấp tất cả các dịch vụ sử dụng công nghệ chuyển mạch gói, nhìn chung nó hiệu quả hơn công nghệ chuyển mạch kênh. Tuy nhiên sức mạnh thực sự của IMS khi so sánh với các trường hợp nêu trên là IMS tạo ra môi trường mà ở đó dịch vụ nào cũng có thể truy nhập bất kỳ một khía cạnh nào của phiên. Điều này cho phép các nhà cung cấp dịch vụ tạo ra nhiều dịch vụ hơn trong một môi trường mà tất cả các dịch vụ đều độc lập với nhau. Ví dụ, một dịch vụ có thể chèn một thông báo vào một conference dựa trên một sự kiện xảy ra trên Internet, giống như thay đổi trạng thái hiện tại của một người đồng sự từ busy sang available. Một dịch vụ khác có thể hiển thị trên màn hình của user trang web của một người đang gọi mỗi khi cuộc gọi được nhận. Hơn nữa, các dịch vụ thực hiện cùng một lúc có thể tự động thiết lập trạng thái hiện thời của user sang bận và chuyển hướng các cuộc gọi vào đến một địa chỉ email thay vì đến một voicemail cho trước. Khi các dịch vụ trên mạng có thể truy nhập đến tất cả các mặt của một phiên, chúng có thể thực hiện rất nhiều hoạt động mà không gửi bất kỳ dữ liệu nào đến thiết bị đầu cuối. Nguồn sóng dư thừa có thể được sử dụng để cung cấp chất lượng dịch vụ cao hơn đến các user đang hoạt động hay để cung cấp cho nhiều user hơn với cùng một chất lượng dịch vụ. Một tiện ích quan trọng khác của IMS là nó không phụ thuộc vào miền chuyển mạch kênh Chương này giới thiệu về một số dịch vụ cơ sở trong IMS, chúng là các khối được xây dựng chung và tái sử dụng được cho việc xây dựng dịch vụ. 3.1. Presence 3.1.1. Giới thiệu Sự hiện diện (presence) và thông điệp tức thời đã và đang thay đổi viễn cảnh của thế giới truyền thông. Presence sẽ là trái tim của mọi liên lạc và là một chức năng mới không thể thiếu cho chiếc điện thoại. Presence cũng sẽ là một cơ hội kinh doanh cho các nhà điều hành và cung cấp dịch vụ. Presence là một hồ sơ động của user, có thể thấy bởi user khác và được sử dụng để giới thiệu, chia sẻ thông tin và điều khiển các dịch vụ. Presence có thể coi như là trạng thái của user được nhận thấy bởi các user khác, và cũng có thể quan sát trạng thái của các user khác. Trạng thái có thể chứa các thông tin cá nhân như: trạng thái thiết bị, vị trí, cũng như các dịch vụ mà user sử dụng để liên lạc với người khác: voice, video, instant message … Ai sử dụng dịch vụ presence? Sẽ có nhiều nhóm user khác nhau có thể sử dụng dịch vụ presence cho nhiều mục đích khác nhau. Những nhóm này trải rộng từ các doanh nhân đến thanh niên và trẻ em. Trong khi Presence được sử dụng nhiều cho việc tăng khả năng quản lý cho công việc, giới trẻ thì lại tìm kiếm một cách mới để khẳng định chính mình. Dịch vụ Presence nâng cao (Presence-enhanced) Đối với các dịch vụ Presence cơ bản, nhà điều hành có thể đem lại nhiều thuộc tính dịch vụ khác nhau: vị trí, khả năng đầu cuối. Dịch vụ Presence-enhanced sử dụng các thông tin presence trong các vùng dịch vụ riêng. Đây là một cơ hội lớn cho các công ty muốn mở rộng sự kinh doanh của họ. Ví dụ như định tuyến cuộc gọi cũng như các dịch vụ game qua mạng, Presence tạo ra các phương pháp quảng cáo linh động và các kênh thông tin chia sẻ. Với presence, làm việc theo nhóm hiệu quả hơn, mang đến khả năng chia sẻ thông tin cho mỗi một thành viên trong nhóm: vị trí cuộc họp, các kế hoạch … Presence đóng góp cho việc kinh doanh Presence có thể đóng góp cho những việc kinh doanh, các dịch vụ Presence và Presence-enhanced đều sẽ được sử dụng. Các nhà điều hành và cung cấp dịch vụ đóng vai trò chính trong việc duy trì các dịch vụ này. Dịch vụ Presence di động là một phần trong danh mục dịch vụ của nhà điều hành. Thuê bao di động ngày nay đạt đến con số hàng tỉ trên thế giới, là một kho lợi nhuận cho các dịch vụ mới. Presence tạo ra nhiều dịch vụ mới như instant message. Presence cũng làm giảm đáng kể các cuộc gọi không thành công hay bị từ chối, điều này có được do biết được trạng thái của user hiện thời (busy hay available, online hay offline…) Các nhà điều hành cũng cần tính toán cẩn thận giá thành của dịch vụ, để cho phép user có thể dễ dàng lựa chọn mà không cần suy nghĩ quá nhiều về giá cước. Vậy Presence là gì? Bản chất của Presence gồm 2 thứ đó là: trạng thái của user có thể thấy được (available) bởi các user khác, và ngược lại trạng thái của các user khác cũng có thể thấy được bởi user này. Các thông tin về sự hiện diện có thể gồm: - tính sẵn sàng của user và thiết bị đầu cuối - truyền thông - khả năng của thiết bị đầu cuối - hoạt động hiện tại - vị trí Có thể hình dung rằng Presence sẽ làm thuận tiện cho tất cả truyền thông di động, không chỉ là IM. Instant message là một phần tương tác chính, là dịch vụ truyền thông thời gian thực trên Internet và Presence ở trong IM thể hiện ở chỗ bạn có thể biết được một người bạn của bạn có online hay không trước khi bắt đầu chat với người đó. Tuy nhiên, trong môi trường di động, nó không chỉ hỗ trợ IM, nó còn được sử dụng như một người chỉ ra khả năng bắt đầu của bất kỳ phiên nào, bao gồm cả: cuộc gọi, video, gaming … Các dịch vụ và ứng dụng Presence sẽ được áp dụng trong tương lai gần. Một ví dụ điển hình của ứng dụng này đó là danh bạ được nhúng thông tin Presence (như hình 3.1). Hình 3.1. Giới thiệu dịch vụ presence. 3.1.2. SIP cho Presence. SIP được mở rộng cho Presence bằng sự tạo ra một gói Event gọi là “presence”. Gói tin Event là một gói tin tập hợp các thông tin về trạng thái được thông báo bởi một notifier cho một subscriber. Khi thuê bao muốn tham gia dịch vụ Presence, thì đặt “presence” vào trong Event header [RFC3265]. Một số khái niệm để mô tả subscriber và notifier: + Presentity: là một thực thể Presence, người cung cấp thông tin presence cho dịch vụ Presence (Như hình vẽ Alice đóng vai trò là Presentity) Hình 3.2. SIP Presence. + Presence User Agent (PUA): một Presentity có nhiều thiết bị được gọi là các PUA, điều khiển thông tin Presence cho một presentity và xuất ra các thông tin Presence. Hình 3.2 chỉ ra 3 PUA: một đầu cuối IMS, laptop và desktop. Mỗi một cái mang một thông tin về Alice (presentity). Chúng có thể có nhiều thông tin về Presence như giờ nào Alice sẽ trở lại sau bữa trước, Alice có sẵn sàng cho một phiên truyền hình hội nghị hay chỉ muốn nhận cuộc gọi. + Presence Agent (PA): là một SIP UA có khả năng nhận các yêu cầu, đáp ứng chúng và sinh ra các khai báo. Tất cả các PUA đều gửi thông tin về PA. PA kết hợp chúng lại và đưa ra một cái nhìn hoàn chỉnh về sự hiện diện của Alice. + Watcher: là một thực thể yêu cầu thông tin Presence (từ PA) của một presentity. Hình 3.2 có 2 Watcher là Bob và Cynthia. Yêu cầu NOTIFY mang thông tin trạng thái, trong trường hợp này, thông tin trạng thái là trạng thái Presence của một Presentity, và Presentity upload các thông tin Presence bằng PUBLISH. Các khai báo sự kiện không chỉ rõ làm thế nào để biết trạng thái của một sự kiện và lấy thông báo về những thay đổi trạng thái của sự kiện đó. Tuy nhiên, một nhánh của SIP cho phép một client lấy được trạng thái sự kiện của nó, sử dụng phương pháp PUBLISH [RFC 3903]. Các yêu cầu PUBLISH là các trạng thái mềm (trạng thái thì thay đổi thường xuyên tuỳ vào hoạt động của user) nên cần phải được refresh liên tục. Event header được sử dụng để chỉ định trạng thái của sự kiện được xuất ra. Yêu cầu URI được sử dụng để xác định nguồn tài nguyên trạng thái, một nhãn được sử dụng bởi client và cung cấp bởi server cho phép client cập nhận trạng thái sử dụng PUBLISH. 3.1.3. Kiến trúc dịch vụ Presence trong IMS. Một số định nghĩa: + Resource List Server: phân phối các yêu cầu SUBSCRIBE cho Watcher khi nó muỗn biết thông tin Presence của nhiều Presentity. + Presence Server: trong IMS Presence Server còn được gán cho PA (Presence Agent) Hình 3.3. Kiến trúc dịch vụ Presence trong IMS. Hình 3.3 môt tả kiến trúc IMS. Đầu cuối IMS đóng vai trò của một watcher hay một PUA. Một RLS còn được thực hiện như một AS. Và bất kỳ một AS nào cung cấp dịch vụ này đều có thể đóng vai trò như một watcher của thông tin Presence của Presentity. Hầu như mọi giao diện đều có tên bắt đầu bằng “P” như Pw, Pi, Px, nhưng hầu hết chúng đều đã tồn tại trong IMS và được chuyển sang chức năng Presence. Chỉ có điểm tham chiếu Pen, nó cho phép AS đóng vai trò như một PUA để xuất thông tin presence cho PA của presentity. PUA có được thông tin presence từ nhiều nguồn khác nhau như HLR, MSC/VLR (Mobile Switching Center/Visited Lôcatin Register) trong mạng CS, SGSN, GGSN, GPRS …. Điểm tham chiếu Ut là giao diện giữa đầu cuối IMS và AS (như PA hoặc RLS). Ut cho phép user lấy thông tin liên quan đến cấu hình và điều khiển dữ liệu (ví dụ: các danh sách presence, cấp phép watcher …). Giao thức tại điểm này là XCAP (XML Configuration Access Protocol). 3.1.4. Presentity list. Giả sử rằng các user (watcher) muốn biết thông tin Presence của nhiều presentity (friend). Sẽ là không tinh tế nếu user gửi vô số các yêu cầu SUBSCRIBE, một yêu cầu cho một Presentity. Ví dụ như trong hình 3.4: Alice muốn biết trạng thái Presence của Bob, David và Peter. Alice đóng vai trò là một watcher gửi yêu cầu SUBCRIBE đến mỗi Presence Agent (1), (3), (5). Sau đó, cô ấy nhận được NOTIFY từ họ (7), (9), (11). Nếu watcher muốn nhận thông tin presence cho 100 presentity, quá trình cần phải có ít nhất 400 bản tin SIP Hình 3.4. Presence không có RLS. Để giải quyết vấn đề này thì IEFT đã đưa ra một khái niệm gọi là Resource List. Một Resource List là một danh sách các SIP URI chứa trong một thực thể chức năng gọi là Resource List Server (RLS), còn được gọi là URI-list cho các yêu cầu SUBCRIBE. Và khi khái niệm Resource list được áp dụng cho dịch vụ Presence, nó còn được gọi là Presence List. Một URI-list nhận yêu cầu từ UA và chuyển tiếp chúng đến nhiều user khác, nó còn tổng hợp nhiều thông tin Presence nhận được trong NOTIFY. Ví dụ như ở hình 3.5, thay vì gửi yêu cầu SUBSCRIBE đến mỗi user, Alice gửi một yêu cầu SUBSCRIBE (1) đến Presenlist. Yêu cầu này được nhận bởi URI-list (hay RLS). Alice trước đó đã cung cấp URI-list với danh sách các URI của Presentity. URI- list gửi yêu cầu SUBSCRIBE đến mỗi URI trong danh sách (3), (5), (7). Sau đó khi URI-list nhận được NOTIFY (9), (11), (13), nó tập hợp lại thông tin Presence và gửi một NOTIFY (15) đến Alice. Cơ cấu này tiết kiệm một lượng lớn băng thông cho mạng truy nhập của Alice, và hơn nữa nó yêu cầu chỉ một lượng nhỏ công suất của PUA. Hình 3.5. Presence với RLS. Điểm tham chiếu Ut trong kiến trúc IMS được sử dụng để điều khiển các resource list. 3.1.5. Các thủ tục báo hiệu trong điều hành dịch vụ Presence. 3.1.5.1. Lấy thông tin Presence. Hình 3.6 thể hiện watcher đã thực hiện thành công quá trình lấy thông tin Presence của một Presentity cư trú trong một mạng khác, trong khi watcher cư trú ở một mạng nhà. Sau quá trình này, user (watcher) sẽ biết được trạng thái của người mà mình muốn liên lạc (presentity) như thế nào: đang ở đâu, có bận hay rảnh… Hình 3.6. Đăng kí Presence thành công. Ở đây UA đóng vai trò là một PUA và quá trình này thực hiện thành công trong miền chuyển mạch gói PS. 3.1.5.2. Xuất thông tin Presence. Hình 3.7 thể hiện quá trình xuất thông tin Presence của user đến một presentity thành công. Sau quá trình này Presentity có thể biết được trạng thái hiện thời của user. Hình 3.7: Xuất thông tin Presence thành công. 3.1.5.3. Lấy thông tin từ RLS. Hình 3.8. Quá trình lấy thông tin từ RLS. Hình 3.8 cho thấy một ví dụ về một watcher lấy thông tin Presence từ một RLS. Danh sách của các presentity (resource) được chuyển đến sử dụng SIP URI. Bản tin NOTIFY được chuyển ngay sau khi nhận được yêu cầu SUBSCRIBE. Nếu RLS không chứa thông tin Presence thì NOTIFY không chứa gì. 3.2. Truyền thông điệp – Messaging. 3.2.1. Giới thiệu. Có rất nhiều dạng của dịch vụ Messaging, nhìn chung messaging là chuyển một thông điệp từ một thực thể đến một thực thể khác. Các thông điệp có thể dưới nhiều hình thức, bao gồm nhiều loại dữ liệu, và có thể được phân phát bằng nhiều cách khác nhau. Thông thường nhất là các thông điệp đa phương tiện cũng như text được truyền đi bằng near-real time bằng các hệ thống thông điệp tức thời (IM) hoặc là một email trong mailbox. Phần này chỉ đề cập đến một số nội dung của messaging trong IMS. IMS messaging có 3 dạng - thông điệp trực tiếp (immediate messaging) - thông điệp dựa trên phiên (session-based messaging) - thông điệp phân phát trì hoãn (deferred delivery messaging) Mỗi một dạng messaging có những đặc điểm riêng của nó; vì thế messaging được nghĩ dưới dạng đơn giản nhất của nó là một dịch vụ truyền thông điệp từ A đến B. Thật ra, một trong những yêu cầu của IMS messaging là dễ dàng liên mạng giữa các loại messaging khác nhau. 3.2.2. Kiến trúc IMS messaging. Trong ba loại messaging, immediate messaging và session-based messaging sử dụng trực tiếp kiến trúc IMS. Deferred delivery messaging sử dụng miền chuyển mạch kênh PS, mặc dù nó có một hạ tầng riêng đến IMS. 3.2.2.1. Immediate messaging. Immediate messaging tương tự như kiểu thông điệp tức thời IM. Nó sử dụng SIP MESSAGE để gửi bản tin giữa các peer trong thời gian gần thực (near-real time). Hình 3.9. Dòng Immediate messaging. Trong Immediate messaging, UE tạo ra một yêu cầu MESSAGE, điền các nội dung vào - bao gồm text và cả hình ảnh hoặc âm thanh –với địa chỉ của người nhận (được chuyển đổi thành URI). Yêu cầu sau đó được định tuyến qua các thành phần của IMS tương tự như với bản tin INVITE, cho đến khi tìm được đường đến UE của người nhận. Không có một giao thức phiên nào liên quan đến quá trình này, mỗi Immediate message là một quá trình độc lập và không có quan hệ với bất kỳ yêu cầu nào trước đó. Nếu một Immediate message được nhận trong khi thuê bao IMS đang offline, hay ở trạng thái không đăng kí, bản tin MESSAGE sẽ được định tuyến đến AS, AS sẽ lưu trữ nội dung này lại và khi user đăng nhập vào, AS sẽ phát bản tin này cho user. Thông thường thì Immediate message được gửi cho một user nào đó. Tuy nhiên, cũng có thể gửi một tin nhắn cho một số người bằng cách sử dụng List server trong IMS. Về cơ bản thì một IMS user có thể tạo ra một tên riêng, sử dụng địa chỉ SIP dưới dạng PSI (Public Service Identifier), và chỉ phổ biến tên này trong một nhóm các thành viên nào đó. Khi một MESSAGE được gửi đến PSI tương ứng trong danh sách, yêu cầu này sẽ được định tuyến đến List server. List server với một AS của nó, sẽ giữ tin nhắn lại và tạo ra một yêu cầu mới cho mỗi thành viên trong danh sách. 3.2.2.2 Session-based messaging. Session-base messaging có mối quan hệ giống như thông điệp đã sử dụng trên Internet: IRC (Internet Relay Chat) Hình 3.10. Dòng Session-base messaging. Trong chế độ này, user thường tham gia vào một phiên mà trong đó dòng phương tiện chính là các tin nhắn dạng text ngắn (ngôn ngữ chat). Cũng giống như bất kì một phiên nào khác: session-base messaging bắt đầu khi các bên tham gia bắt đầu phiên và kết thúc khi đóng phiên đó lại. Sau khi một phiên được thiết lập sử dụng SIP và SDP giữa các phiên – dòng phương tiện sau đó được chuyển trực tiếp giữa các đầu cuối. Hình 3.10 minh hoạ một phiên messaging. Session-base messaging có thể là peer-to-peer, trong trường hợp này nó bắt chước giống như một cuộc gọi voice thông thường, chỉ có một điều khác biệt là dòng phương tiện chính của phiên này là dạng text. Tuy nhiên, session-base messaging không chỉ hạn chế truyền thông điệp dưới dạng text, nó còn có khả năng kết hợp các phiên phương tiện khác với phiên tin nhắn. Và nhiều ứng dụng hữu ích cũng có thể áp dụng cùng với chức năng này, ví dụ, kết hợp video với chat dưới dạng text có thể là một ứng dụng phù hợp đối với những người bị yếu chức năng nghe (khiếm thính). Giao thức chuyên chở các thông điệp trong phiên này gọi là Message Session Relay Protocol (MSRP). MSRP ở trên TCP, và có thể mang bất kì dữ liệu MIME nào được đóng gói. Các thông điệp có thể có kích thước bất kỳ, bởi vì một trong những đặc điểm của giao thức là có thể hỗ trợ gửi một thông điệp hoàn chỉnh với từng khúc nhỏ và tự động tái hợp ở phía nhận. Session-based messaging cũng áp dụng tốt cho chức năng hội nghị, có thể tạo một phiên chat với nhiều bên tham gia. 3.3. Push to talk over cellular. 3.3.1. Giới thiệu. Push to talk over cellular (PoC) cung cấp dịch vụ truyền thoại điểm-điểm và điểm- đa điểm. Ý tưởng là user chọn một vài cá nhân hoặc một nhóm người mà user muốn liên lạc, và sau đó nhấn nút để bắt đầu nói chuyện. Hình 3.11. Push to talk over Cellular Phiên kết nối trong thời gian thực, là một chiều, khi một người nói thì người khác chỉ việc nghe. Việc chuyển sang nói được yêu cầu bằng cách nhấn nút nói và được công nhận trên cơ sở “first come first served” – yêu cầu nào đến trước sẽ được đáp ứng trước. Kết nối không cần các bên nhận chấp nhận và được nghe thông qua loa ngoài của điện thoại. User cũng có thể chọn để nhận một phiên đàm thoại sau khi đã chấp nhận một lời mời. Nếu cần thiết có sự riêng tư, user có thể nghe bằng tai nghe. Dịch vụ này dựa trên multi-unicasting. Mỗi client gửi các gói dữ liệu đến một PoC server và trong trường hợp liên lạc theo nhóm, server sẽ gửi các gói này đến tất cả các máy thu (hình 3.11). Không một quá trình multicast nào được thực hiện trong mạng truy nhập cũng như mạng lõi, sự quản lý tính di động được thực hiện bởi mạng vô tuyến. Điều này giải thích tính trong suốt của dịch vụ PoC đối với mạng tế bào và mạng cố định. Điều khiển phiên PoC dựa trên giao thức SIP và lưu lượng thoại được mang bởi giao thức RTP/RTCP. 3.3.2 Kiến trúc PoC Chuẩn PoC phiên bản đầu tiên (Release 1) của OMA bao gồm PoC client, PoC application server và PoC XML Document Management Server (PoC XDMS). XDMS được coi như là một phương tiện quản lý thiết lập cấu hình ứng dụng cũng như lưu trữ các thiết lập. Một XDMS server mà lưu trữ các dữ liệu riêng cho PoC gọi là “PoC XDMS”. Sử dụng điểm tham chiếu POC-8, PoC server có thể lấy các tài liệu liên quan đến PoC (ví dụ như danh sách truy nhập) và sử dụng điểm tham chiếu PoC- 5, PoC server có thể lấy được danh sách chung từ Shared XDMS. Các PoC server xử lý các ứng dụng riêng như điều khiển talk burst (nhóm gọi), điều khiển phiên PoC. Chúng cũng cung cấp các giao diện cho sự giám sát và hệ thống quản lý mạng, tạo Charging Detail Record (CDR). Hình 3.12. Kiến trúc PoC. PoC server kết nối với IMS thông qua điểm tham chiếu ISC. IMS nắm giữ các chức năng chung như nhận thực user cho PoC, định tuyến phiên và tính cước dựa trên SIP. PoC client thông thường là một phần mềm trong UE nhưng nó cũng có thể là một ứng dụng (trong PC). Thông thường, dịch vụ Presence kết hợp với PoC, khi Presence có thêm các dữ liệu PoC (ví dụ, user có thể biết được sự sẵn sàng liên lạc PoC của user khác). 3.3.3. Các đặc điểm của PoC. 3.3.3.1. Liên lạc PoC. PoC hỗ trợ nhiều chế độ liên lạc để phục vụ cho nhu cầu của các nhóm khác nhau. Sự khác nhau chính giữa những chế độ này liên quan đến chính sách nhóm và sự thiết lập phiên. Nói theo cách khác đó là, làm thế nào để user tạo một nhóm và thêm/xoá các thành viên trong nhóm. Làm thế nào để kích hoạt một phiên và điều khiển truy nhập như thế nào? Trong liên lạc nhóm quay số ra (dial-out group), một user mời một nhóm user tham gia một phiên nhóm. User được lời mời và họ có thể tham gia sử dụng chức năng trả lời tự động hay bằng tay. Nhóm được mời có thể là nhóm PoC chỉ định trước (pre-arrange PoC group) hoặc một danh sách được chọn từ danh bạ của user (ad hoc PoC group). Khả năng xem được sự sẵn sàng của user khác (sử dụng Presence) mang đến sự tiện ích hơn cho user. Có một vài quy luật đặc biệt cho nhóm người gọi có chỉ định trước. Đầu tiên, phiên PoC giữa các thành viên trong nhóm được thiết lập khi bất kì một thành viên nào gửi lời mời đến các thành viên khác tham gia. Thứ hai, sự liên lạc bắt đầu sau khi thành viên đầu tiên đầu tiên trong nhóm chấp nhận lời mời. Thứ ba, sự tham gia một phiên chỉ được cho phép đối với những thành viên đã xác định trước (thành viên trong nhóm chỉ định). Tương tự như vậy, cũng có một số luật cho ad hoc PoC group. Một nhóm ad hoc PoC được tạo ra khi một PoC user mời một hay nhìêu user vào một phiên PoC. Chỉ cho phép những người được mời, tức là một user muốn tham gia và phiên thì phải nhận được lời mời tham gia (ví dụ như SIP INVITE hay SIP REFER từ PoC serv