Cấu trúc hệ thống IMS thực hiện dịch vụ hội nghị luôn có một điểm trung tâm báo hiệu, thực hiện kết nối tất cả những thành viên tham gia hội nghị lại với nhau. Điểm trung tâm này cung cấp một loạt các dịch vụ hội nghị bao gồm trộn phương tiện (Media Mixing), chuyển đổi mã (transcoding) và các thông báo danh sách người tham gia.
Có nhiều cách để tạo một hội nghi: dùng SIP tạo các hội nghi ad hoc; các hội nghị đã được lập danh mục (dùng CPCP – Conference Policy Control Protocol, là giao thức client- server được các user dùng để vận dụng các luật áp dụng trong hội nghị);
Hình 3.36 là cấu trúc hệ thống dịch vụ hội nghị. Nó nhận dạng các giao diện giữa các thực thể và các giao thức sử dụng giữa chúng. UA trong hình đại diện cho người tham gia hội
nghị, là thực thể tạo một hội nghi ad hoc hoặc tham gia hội nghị dùng CPCP đã tạo bằng cách gửi yêu cầu SIP INVITE.
Hình 3.36. Cấu trúc IMS thực hiện dịch vụ hội nghị 3.6.2 Trạng thái hội nghị
Trình bày sự kiện trạng thái hội nghị (conference state) được dùng để biết các thay đổi của các thành viên tham gia hội nghị: nhờ các thông báo user có thể biết ai đã tham gia hay rời khỏi hội nghị. Gói sự kiện (Event package) này cũng cho phép các thành viên biết được trạng thái các thành viên của user trong hội nghị.
Các user có thể đăng ký trạng thái hội nghị bằng cách gửi một yêu cầu SUBSCRIBE đến URI conference đại diện cho máy chủ hội nghị (conference server). Conference Server sẽ đảm nhận làm bộ thông báo về các event package này.
Tên của event package này là ―conference‖. Thẻ này xuất hiện trong mào đầu Event của yêu cầu SUBSCRIBE. Thân của mỗi thông báo sẽ mang thông tin trạng thái hội nghị.
Hai phần thông tin về trạng thái user là: trạng thái hiện tại của user (activity-status) và phương thức mà người tham gia vào hoặc ra khỏi hội nghị (history-status). Activity-status mang một trong các trạng thái sau: dialled-in, dialled-out, departed, booted hoặc failed.
3.6.3 Ví dụ
Khi tạo hội nghi bằng URI conference factory, người tham gia hội nghị sẽ tạo yêu cầu INVITE có URI chứa URI conference factory. Conference server tạo một tiêu điểm (focus) cho hội nghị đã tạo, phân công cho nó một URI conference và trả về mào đầu Contact chứa URI này ở phản hồi 200 OK. URI chứa một tham số ―isfocus‖ chỉ ra URI là của focus này. Khi nhận được phản hồi 200 OK cho yêu cầu INVITE, người tham dự hội nghị sẽ lưu lại nội dung của mào đầu Contact chứa URI conference. URI này có thể được dùng để chỉ cho user đến hội nghị (hình 3.37).
Hình 3.37. Tạo một hội nghị dùng URI conference factory [3]
Khi tạo một yêu cầu REFER (đã dự định cho một user) để mời user đó tham gia hội nghị, mào đầu Refer-To của yêu cầu REFER được đặt địa chỉ đến URI conference, có tham số ―isfocus‖. (hình 3.38).
Hình 3.39. Sự đăng ký trạng thái hội nghị [3]
Hình 3.40 là ví dụ về việc user dùng giao giao diện Ut, gửi bản tin CPCP tới conference server để thiết đặt hội nghị.
Trong đó user C thuộc diện đã được vào dang sách (Dial-in list), user B thì ngược lại (Dial-out list), user A đảm nhận làm điều phối (Moderator).
Lúc 7:00 GMT 28/11/2003 server conference tạo một focus. Focus đọc danh sách dial- out và tìm thấy user B trong đó. Focus sẽ gửi cho user B một lời mời tham gia vào hội nghị. User A sẽ đăng ký conference-state event package và thông báo rằng user B đã tham gia hội nghị. Một thời gian sau, user A thấy user C tham gia vào hội nghị. Lúc 15:00 GMT, focus gửi bản tin kết thúc hội nghị.
3.7 DỊCH VỤ QUẢN LÝ NHÓM
Với sự bùng nổ nhu cầu dịch vụ, một User có thể dùng nhiều thiết bị đầu cuối khác nhau như PDA, Mobile phone, PC,.. để tiện truy cập thì các dữ liệu dịch vụ cần được xây dựng một lần cho toàn bộ thiết bị đầu cuối của một User.
Một vấn đề đặt ra khi user dùng web, các user không muốn thực hiện quá nhiều hiệu chỉnh phức tạp cho trình duyệt, mặt khác web không cho phép dữ liệu dịch vụ tích hợp cùng với các ứng dụng dịch vụ chạy trên một mobile phone hay bất cứ thiết bị nào.
Xét một ví dụ, khi một user muốn tạo một dịch vụ dạnh sách hiển thị người thân (buddy list) trên máy PC và mobile phone. Khi không áp dụng quản lý nhóm, user sẽ phải tạo buddy list hai lần: một trên PC và một trên mobile. User sẽ không thể dùng dịch vụ web messenger tại quán café internet vì buddy list của họ được lưu trữ tại PC và mobile. Nếu dữ liệu buddy list được lưu trữ trên mạng thì vấn đề này sẽ được giải quyết. User chỉ cần xây dựng buddy list một lần trên bất kỳ thiết bị nào, sau đó dữ liệu buddy list sẽ được tải lên và lưu trữ trong mạng dưới dạng một danh sách. Khi user thay đổi danh sách đo, các thiết bị khác của họ cũng sẽ được thông báo để thay đổi buddy list.
Một ví dụ nữa đối với dịch vụ quản lý nhóm là sự tạo ra danh sách điều khiển truy nhập ACL (Access Control List). Alice có thể tạo một ACL cho phép Bob và John gọi cô ấy hoặc khởi tạo phiên PoC với Alice ngoại trừ Sarah. Mạng sẽ tự động từ chối bất kỳ thông tin nào từ Sarah đến Alice.
3.7.1 Khái niệm Dịch vụ Quản lý nhóm
Quản lý nhóm là dịch vụ cho phép các user lưu trữ dữ liệu dịch vụ trên mạng nhà cung cấp dịch vụ. Dữ liệu này có thể được user tạo ra, thay đổi hoặc xoá đi. Dữ liệu ở đây là bất cứ dữ liệu nào cần cho user hoàn thành dịch vụ. Ví dụ như buddy list và các danh sách trao quyền hiện tại.
Các dịch vụ như hiển thị, PoC, nhắn tin, … cần hỗ trợ quản lý nhóm để truy nhập tới nó. Một số ví dụ:
Conference Access List: danh sách các thành viên tham gia hội nghị ở dịch vụ PoC,
hay chính là nhóm PoC.
Resource List: danh sách của user sẽ nhận thông báo, danh sách này có thể được dùng để đăng ký trạng thái của mỗi tài nguyên trong đó, ví dụ như danh sách thực thể hiển thị.
Subscription Authorization Policy: ví dụ như ACP ở trên.
OMA (Open Mobile Alliance) dùng thuật ngữ quản lý nhóm đồng nghĩa với quản lý tài liệu XML (XDM – XML Document Management). Giao thức truy nhập cấu hình XML - XCAP (XML Configuration Access Protocol) được dùng cho việc truyền tải, truy nhập, đọc và vận dụng các tài liệu XML chứa dữ liệu dịch vụ quản lý nhóm.
Ví dụ Alice tạo một buddy list rồi thêm Bob và Sarah vào danh sách bạn thân. Một yêu cầu XCAP được tạo ra, chứa danh sách resource (ở đây là buddy, danh sách bạn thân) sẽ được gửi lên RLS và lưu trữ tại đó. Yêu cầu XCAP có dạng: (adsbygoogle = window.adsbygoogle || []).push({});
PUT http://xcap.example.com/services/resoure- lists/users/sip:alice@example.com/friends.xml HTTP/1.1 Content-Type:application/resource-lists+xml Host: xcap.example.com <?xml version=‖1.0‖ encoding=‖UTF-8‖?> <resource-lists xmls=‖uri:ietf:params:xml:ns:resource-lists‖> <list name=‖friends‖> <entry uri=‖sip:bob@example.com‖> <display-name>Bob</display-name> </entry> </list> </resource-lists>
3.7.2 Resource List (Danh sách tài nguyên)
SIP có cơ chế thông báo cho phép user gửi yêu cầu thông báo các thay đổi của một trạng thái resource (ở đây chính là trạng thái các thuê bao khác trong nhóm).
Khi không dùng RLS (resource list server), một user thông báo cho các user còn lại trong nhóm. Như vậy thì user đó phải gửi nhiều yêu cầu SUBSCRIBE đến các user khác và nhận các NOTIFY từ các user đó, băng thông và điều khiển luồng tránh tắc nghẽn thì có hạn chế do vậy hiệu quả không cao (hình 3.41). Khi dùng RLS, user sẽ gửi SUBSCIBE và NOTIFY đến RLS. Khi đó SUBSCRIBE chứa mào đầu Supported với tham số nhãn tuỳ chọn có giá trị ―eventlist‖ (hình 3.38). RLS sẽ tạo ra các yêu cầu NOTIFY chứa thông tin trạng thái của danh sách, NOTIFY này chứa mào đầu Require với tham số nhãn có giá trị ―eventlist‖. RLS sẽ đóng vai trò xử lý các yêu cầu và phản hồi, vì thế user thực hiện cập nhật thay đổi sẽ tiết kiệm được băng thông và khả năng xử lý.
SUBS CRIBE SUBSCR IBE SUBSCRIBE SUBSCRIBE NOTIF Y NOTIFY NOTIFY NOTIFY Alice Bob Tim John Harry
Hình 3.41. Cập nhật thay đổi trạng thái, không dùng RLS [3]
SUBS CRIB E SUBSCR IBE SUBSCRIBE SUBSCRIBE NOTIF Y NOTIFY NOTIFY NOTIFY Alice Bob Tim John Harry List Server SUBSCRIBE.friends@listserver Presence Session NOTIFY
Hình 3.42. Cập nhật thay đổi trạng thái, có dùng RLS [3] 3.7.3 Quản lý tài liệu XML PoC
Nhóm PoC
Nhóm PoC là danh sách các thành viên tham gia phiên PoC. Ứng dụng nhóm PoC chứa các thông tin:
URI nhận dạng nhóm PoC;
Tên hiển thị cho nhóm;
Một hay nhiều danh sách các thành viên trong nhóm (các URI);
Một dấu hiệu chỉ ra các thành viên trong nhóm sẽ được PoC Server mời vào phiên PoC hay không;
Số thành viên tối đa trong phiên PoC;
Cấu trúc của chính sách trao quyền phải hợp với chính sách chung. Các điều kiện cho một chính sách trao quyền bao gồm nhận dạng thành viên tham gia, nhận dạng của thành viên từ danh sách mở rộng, các nhận dạng khác chưa theo luật nào và điều kiện kiểm tra user có là thành viên của danh sách hay không.
Nếu điều kiện trên trả lại ―true‖ sẽ cho phép user đăng ký (thuê sử dụng) trạng thái phiên PoC, cho phép user mời các thành viên khác tham gia phiên một cách linh động, cho phép user được ẩn danh.
Ví dụ, Alice muốn tạo một phiên PoC với Bob, Sarah và John (nhóm bạn của cô) (giống việc tạo conference chat). Số thành viên tối đa tham gia vào phiên không được vượt quá 4. Điều đó cho phép Alice thêm nhiều bạn vào danh sách nhưng giới hạn thành viên tham gia hiện tại chỉ là 4 (do Alice đặt, giống như room chat chỉ có tối đa 50 người cùng tham gia cùng một lúc nhưng có thể có rất nhiều người tham gia, khác room chat ở chỗ admin là Alice chứ không phải là room chat server).
Chính sách truy nhập user PoC
Cấu trúc của chính sách truy nhập phải thích nghi với chính sách chung. Các điều kiện mà một chính sách trao quyền bao gồm là nhận dạng các thành viên tham gia từ đó user có thể chấp nhận hay từ chối phiên PoC, nhận dạng của một thành viên trong danh sách mở rộng và các nhận dạng hiện không trong luật nào.
Chỉ có một hoạt động định nghĩa cho một điều kiện đã được thoả mãn là sẽ xử trí thế nào đối với một lời mời. Một trong ba giá trị có thể xuất hiện: pass, reject, và accept. ―Pass‖ chỉ dẫn PoC Server xử lý lời mời tham gia phiên PoC bằng cách dùng thủ tục trả lời thủ công (do người dùng phải thao tác chọn). ―Accept‖ chỉ cho PoC Server chấp nhận lời mời theo chế độ trả lời của user đã đặt sẵn. ―Reject‖ chỉ cho PoC Server từ chối lời mời.
Với 6 nội dung trình bày: 1. Hiển thị. 2. Nhắn tin. 3. Push to Talk 4. POC 5. Dịch vụ Hội nghị. 6. Quản lý nhóm.
Chương III đã khép lại với những dịch vụ chủ yếu mà các nhà khai thác IMS trên thế giới và trong nước đang hướng tới.
Chương IV của Luận văn được trình bầy với các thông tin về thiết bị và các giải pháp IMS của các Hãng và các nhà khai thác; đồng thời nêu một số khuyến nghị về IMS đối với nhà Khai thác VNPT Việt Nam.
Chƣơng 4: SẢN PHẨM, THIẾT BỊ VÀ GIẢI PHÁP IMS DI ĐỘNG CỦA MỘT SỐ HÃNG TRÊN THẾ GIỚI.
4.1 HÃNG HUAWEI4.1.1 Giải pháp 4.1.1 Giải pháp
Chuyển đổi softswitch - IMS 4.1.1.1 Chuyển đổi mạng
Lộ trình phát triển IMS của Huawei được thực hiện tuần tự: TDM Softswitch
IMS (xem Hình ).
Hình 4.1. Lộ trình phát triển lên hệ thống IMS – Huawei (adsbygoogle = window.adsbygoogle || []).push({});
Đối với hệ thống NGN trên nền IP sử dụng chuyển mạch mềm, để nâng cấp lên IMS, Huawei đề xuất nâng cấp các phần cứng cũng như phần mềm cần bổ xung vào hệ thống mạng. Phần cứng cần nâng cấp thêm các thành phần CSCF, HSS và Application Servers. Các thành phần trong mạng NGN đã có như NMS, MRS, RACF chỉ cần nâng cấp thêm phần mềm. Riêng thành phần softswitch có thể nâng cấp phần mềm theo 2 hướng thành AGCF hoặc MGCF tùy theo cấu hình kết nối hiện tại của softswitch. Cấu trúc và các thành phần nâng cấp lên IMS được thể hiện trong hình 4.2.
Hình 4.2. Nâng cấp từ NGN softswitch lên IMS - Huawei
Hình 4.3. Chi tiết các thành phần nâng cấp từ PSTN->NGN->IMS 4.1.1.1Chuyển đổi dịch vụ
Lộ trình chuyển đổi dịch vụ của Huawei có những điểm cơ bản cần lưu ý như sau:
Theo Huawei, các dịch vụ trước đây VNPT cung cấp là những dịch vụ đơn giản và chủ yếu dựa trên thoại. Những dịch vụ như PPS, PPT, UPT trên nền INAP.
Khi VNPT nâng cấp mạng NGN, Softx3000 của Huawei hỗ trợ nhiều loại dịch vụ số liệu và rút ngắn thời gian triển khai dịch vụ. Các dịch vu PPS, PPT và UPT có thể tiếp tục thực hiện trên nền SIP. Ngoài ra, cấu trúc này đảm bảo cung cấp nhiều loại dịch vụ khác như: RBT, UC, WEB 800 …
Khi mạng VNPT ở giai đoạn phát triển IMS (chuyển đổi sang IMS ở pha 3), giải pháp IMS của Huawei cho phép cung cấp nhiều loại dịch vụ đa phương tiện và các dịch vụ hội tụ FMC. Huawei cung cấp: dịch vụ VCC, CSI, IP Centrex, Multimedia
Conference, Poc, Presence, Group, MRBT/MCID (chi tiết về các dịch vụ này sẽ được phân tích trong mục 4.1.3)...
Huawei đề xuất cung cấp các dịch vụ đa phương tiện và các dịch vụ hội tụ FMC ở các khu vực có nhu cầu cao như Hà Nội và Tp Hồ Chí Minh.
4.1.2 Thiết bị
Dưới đây là mô hình mạng IMS đầy đủ các thành phần do Huawei triển khai.
Hình 4.4. Mô hình mạng IMS đầy đủ của Huawei
a. CSC3300
CSC3300 (Call Session Control Function) cung cấp đầy đủ các chức năng liên quan đến nhận thực người dùng, quản lý phiên, quản lý roaming, là thành phần chính trong giải pháp của hệ thống mạng IMS và mạng kết hợp cố định, di động của Huawei. Nó hỗ trợ cho các mạng cố định và di động sử dụng chuẩn 3GPP, 3GPP2, ETSI và ITU-T.
Ngoài các chức năng cơ bản P-CSCF, I-CSCF, S-CSCF của một CSCF nó còn có thêm các chức năng lựa chọn đường truyền từ IMS tới mạng chuyển mạch kênh (BGCF) và nhận diện chức năng thanh toán trực tiếp (OCG).
CSC3000 cũng hỗ trợ rất nhiều chế độ nhận thực khác nhau như IMS AKA (3GPP), Early AKA (GSM/UMTS), Early IMS (PS subscribers), HTTP Digest, NBA (Fixed network terminals). CSC3300 S-CSCF AGC3000 AGCF CSC3300 P-CSCF CSC3300 I-CSCF UTRAN EVDO WIMAX LAN/FTTX xDSL CABLE TDM Access POTS Phone IP Phone WIFI 3G Phone 3G Phone Dual mode Phone CSC3300 BGCF SE2300 A-BGF AIM6000 NACF RM9000 RACF InfoX AAA UAAF & PDBF AIM6000 CLF RM9000 SPDF RM9000 PCRF HSS9820 HSS MRS6600 MRFC & MRFP iManager N2000
EMS ENUM Server
ENUM Server ISMP Web portal OCS9810 OCS ICF9815 CCF GTAS9900 Telephony AS ETAS9960 IP Centrex AS CSI9620 CSI AS SoftX3000 MGCF SG7000 SGW PSTN PLMN IP Network SoftX3000 I-BCF ENIP AS Platform IMAS series IP multimedia AS HOAS9600 VCC AS UMG8900 IM-MGW
b. HSS9820
HSS9820 (Hom Subscriber Server) là máy chủ lưu trữ các thông tin người dùng, được tích hợp cả chức năng HSS và SLF của mạng IMS với số lượng thuê bao lưu trữ lên đến 10 triệu người. HSS9820 cũng có đầy đủ các chức năng nhận thực các người dùng khác nhau với các cơ chế nhận thực như CSC3300 ở trên. Ngoài ra do là nơi lưu giữ cơ sở dữ liệu nên HSS9820 cung cấp khả năng lưu trữ và đồng bộ dữ liệu thời gian thực với việc sử dụng song song 2 server: một active và một standby.
c. MRS6600 (MRC6600/MRP6600)
MRS6600 gồm 2 thành phần MRC6600 (Media Resource Controller) và MRP6600 (Media Resources Processor). MRFC kết hợp với MRFP để nhận biết cơ chế phân biệt điều khiển tài nguyên phương tiện từ sóng mang như audio conference, video conference, voice mailbox, video mailbox, nhạc chuông đa âm, hình màu, Push-to-Talk. MRC6600 hỗ trợ audio conference lên đến 2048 thuê bao và video conference lên 128 thuê bao cùng tham gia, có dung lượng lên đến 18 triệu thuê bao liên lạc trong giờ bận.
d. AIM6300
AIM6300 là thành phần thuộc lớp truy cập liên mạng, có chức năng quản lý vị trí, cấu hình mạng truy cập và lưu trữ thông tin người dùng của mạng cố định, phân bố các tham số