BỘ GIÁO DỤC VÀ ĐÀO TẠO CỘNG HÒA XÃ HÔI CHỦ NGHĨA VIỆT NAMTRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
--------------------------------------------------Độc lập - Tự do - Hạnh phúc---------------------------------
NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
Họ và tên sinh viên: .…………….………….…….. Số hiệu sinh viên: ………………
Khoá:…………………….Khoa: Điện tử - Viễn thông Ngành: ……………….........
1. Đầu đề đồ án:
………………………………………………..………………………………………………………………………
……………………………………………………………………………………………………………..………...
2. Các số liệu và dữ liệu ban đầu:
……………………………………..……………………………………………..……..……………………………
……………………………………………………………………………………………………………………………….
…..………………………..…………………………………………………………………………………….
3. Nội dung các phần thuyết minh và tính toán:
………………………………………………………………………………………………………………..….
………………………………………………………………………………………………………………………………
……..….
………………………………………………………………………………………………………………………………
………..….……………………………………………………………………………………………
4. Các bản vẽ, đồ thị ( ghi rõ các loại và kích thước bản vẽ ):
………………………………………………………………………………………………………………………..….
…………………………………………………………………………………………………………………………..
……….………………………………………………………………………………………………………….
5. Họ tên giảng viên hướng dẫn: ………………………………………………………..……………………
6. Ngày giao nhiệm vụ đồ án: ………………………………………………….……………
7. Ngày hoàn thành đồ án: ………………………………………………………………………..………
Ngày tháng năm
Chủ nhiệm Bộ môn Giảng viên hướng dẫn
Sinh viên đã hoàn thành và nộp đồ án tốt nghiệp ngày tháng năm
Cán bộ phản biện
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI---------------------------------------------------
BẢN NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP
Họ và tên sinh viên: ....................................................................... Số hiệu sinh viên: ...........................
Ngành: .................................................................................................. Khoá: ....................................................
Giảng viên hướng dẫn:..............................................................................................................................................
Cán bộ phản biện: .......................................................................................................................................
1. Nội dung thiết kế tốt nghiệp:
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
......................................................................................................................
2. Nhận xét của cán bộ phản biện:
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
...................................................................................................................................................................................................
..........................................................................
Ngày tháng năm
Cán bộ phản biện
( Ký, ghi rõ họ và tên )
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
LỜI NÓI ĐẦU
Trong những năm qua xu hướng hội tụ mạng Internet, mạng di động và mạng
PSTN đang là xu hướng được quan tâm hàng đầu trong lĩnh vực thông tin liên lạc.
Nhiều kiến trúc mới đã ra đời trong quá trình phát triển hợp nhất các mạng với mục
đích tạo ra một mạng toàn IP duy nhất. Phân hệ IP Multimedia Subsystem (IMS) là
một trong những kiến trúc đã ra đời trong xu thế phát triển đó. Với IMS người dùng
có thể liên lạc khắp mọi nơi nhờ tính di động của mạng di động và đồng thời có thể
sử dụng những dịch vụ hấp dẫn từ mạng Internet. IMS đã thực sự trở thành chìa
khóa để hợp nhất mạng di động và mạng Internet. IMS đồng thời cũng trở thành
một phân hệ trong mô hình mạng thế hệ mới (NGN) của tất cả các hang sản xuất
các thiết bị viễn thông và các tổ chức chuẩn hóa trên thế giới.
IMS được chuẩn hóa bởi 3GPP và 3GPP2 dựa trên giao thức báo hiệu SIP và
các giao thức mở khác do IETF chuẩn hóa nên rất dễ dàng tích hợp với các dịch vụ
mới. IMS đồng thời cũng hỗ trợ nhiều loại hình truy cập khác nhau do đó nó hứa
hẹn sẽ mang lại một số lượng lớn khách hàng sử dụng các dịch vụ xây dựng trên đó.
Trong thời gian thực tập tại phòng lab 618 thư viện điện tử của bộ môn kỹ
thuật thông tin để tìm hiểu về kiến trúc IMS và triển khai các dịch vụ mới trên IMS,
được sự gợi ý của tiến sĩ Nguyễn Tài Hưng em đã lựa chọn đề tài “Thiết kế và
triển khai dịch vụ IPTV trên kiến trúc mạng IMS”.
Em xin chân thành cám ơn TS. Nguyễn Tài Hưng và TS. Nguyễn Hữu Thanh đã
giúp đỡ tận tình cho em trong thời gian làm đồ án vừa qua.
Em xin chân thành cám ơn
Hà Nội, ngày 20 tháng 05 năm 2010
Sinh viên
Giang Kỳ Nam
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
TÓM TẮT ĐỒ ÁN
Trong những năm gần đây, dịch vụ IPTV đang là chủ đề nóng thu hút sự
quan tâm của nhiều nhà cung cấp dịch vụ mạng viễn thong di động trên thế giới.
Bên cạnh đó kiến trúc mạng IMS nổi lên như 1 xu hướng trong kiến trúc mạng thế
hệ tiếp theo. Như vậy triển khai dịch vụ IPTV trên nền IMS sẽ mang lại cho người
dùng những trải nghiệm dịch vụ như thế nào và tính thực tế của nó ra sao?
Trong đề tài này, tôi chỉ ra giải pháp thiết kế triển khai dịch vụ trên nền tảng
IMS, so sánh nó với những kiến trúc truyền thống để thấy được ưu điểm của nó về
tốc độ và chi phí cho phát triển dịch vụ trong mạng viễn thông nói chung. Theo đó
tôi đưa ra mô hình của dịch vụ IPTV trên kiến trúc IMS, sử dụng các siao thức SIP,
Diameter, công nghệ Sip Servlet để triển khai nó và chứng minh tính mềm dẻo và
đa tính năng, dễ dàng mở rộng của IMS.
ABSTRACTION
Today, IPTV is presently a hot topic that is attracting the attention of many
telecom network operators. Beside, IMS emerges to be the trend in developing the
architecture of the next generation network. So what will IMS based IPTV bring to
the end users in terms of service experience and how does it become reality?
In this project, I present a solution in designing and developing services in
IMS architecture, put it in comparison to traditional architecture to realize its
advantages regarding speed and cost of service development in telecom network in
general. After that, I bring out IMS based IPTV architecture that implements SIP,
Diameter protocol, Sip servlet technology and develop it to demonstrate the
flexibility, multi function and scalability of IMS.
5
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
MỤC LỤC
1 CHƯƠNG I : MỞ ĐẦU ....................................................................................... 15 1.1 Tầm quan trọng của đề tài .............................................................................. 15 1.2 Nội dung nghiên cứu ...................................................................................... 16
2 CHƯƠNG II : VỀ KIẾN TRÚC IMS ................................................................... 17 2.1 Kiến trúc tổng quát IMS ................................................................................. 17
2.1.1 Mạng truy nhập ....................................................................................... 18 2.1.2 Mạng lõi .................................................................................................. 19 2.1.3 Tầng dịch vụ ............................................................................................ 29
2.2 Định danh trong IMS ..................................................................................... 30 2.2.1 Định danh người dùng công cộng ............................................................ 30 2.2.2 Định danh người dùng riêng .................................................................... 32 2.2.3 Mối quan hệ giữa định danh công cộng và định danh riêng .................... 32 2.2.4 Định danh dịch vụ công cộng .................................................................. 34
2.3 SIM, USIM và ISIM trong 3GPP ................................................................... 35 2.3.1 SIM .......................................................................................................... 36 2.3.2 USIM ....................................................................................................... 36 2.3.3 ISIM ........................................................................................................ 36
2.4 Tiêu chuẩn lọc ................................................................................................ 37 2.5 Triển khai kiến trúc IMS ................................................................................ 43
3 CHƯƠNG III : CÁC GIAO THỨC QUAN TRỌNG ........................................... 46 3.1 Giao thức SDP ............................................................................................... 46
3.1.1 Mô tả phiên .............................................................................................. 46 3.1.2 Mô hình Offer/Answer ............................................................................ 48 3.1.3 SIP và SIPS URIs .................................................................................... 49 3.1.4 Định vị người dùng .................................................................................. 50
3.2 Giao thức Diameter ........................................................................................ 51 3.2.1 Gói tin Diameter ...................................................................................... 52 3.2.2 Phiên giao dịch ........................................................................................ 53 3.2.3 Triển khai giao thức trong đề tài .............................................................. 55
3.3 Giao thức SIP ................................................................................................. 59 3.3.1 SIP liên hệ với HTTP như thế nào ........................................................... 60 3.3.2 Bản tin SIP .............................................................................................. 62 3.3.3 Phiên giao dịch (Transaction) .................................................................. 63 3.3.4 Hội thoại (dialog) .................................................................................... 65 3.3.5 Trường điều khiển Record-Route, Route và Contact ............................... 67
4 CHƯƠNG IV : MÁY CHỦ ỨNG DỤNG ............................................................ 69 4.1 Tổng quan về máy chủ ứng dụng ................................................................... 69
6
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
4.2 Chức năng của máy chủ ứng dụng trong mô hình IMS .................................. 69 4.3 Các chế độ hoạt động của máy chủ ứng dụng ................................................ 71
4.3.1 AS hoạt động như SIP User Agent .......................................................... 71 4.3.2 AS hoạt động như back-to-back user agent ............................................. 72 4.3.3 AS đóng vai trò như là SIP Proxy Server ................................................ 73 4.3.4 AS đóng vai trò như là SIP Redirect Server ............................................ 74
4.4 Giao diện AS với các thành phần khác trong mạng ........................................ 75 4.4.1 Giao diện với IMS Core – ISC ................................................................ 75 4.4.2 Giao diện với HSS – Sh ........................................................................... 76
4.5 Quá trình cung cấp dịch vụ ............................................................................ 81 4.5.1 Giới thiệu ................................................................................................. 81 4.5.2 Sự hình thành tiêu chuẩn lọc khởi tạo ...................................................... 81 4.5.3 Lựa chọn máy chủ ứng dụng ................................................................... 84 4.5.4 Hành vi của máy chủ ứng dụng ............................................................... 86 4.5.5 Máy chủ ứng dụng tương tác với HSS ..................................................... 86 4.5.6 Máy chủ ứng dụng gửi yêu cầu về S-CSCF ............................................. 87
5 CHƯƠNG V : DỊCH VỤ IPTV TRÊN NỀN IMS ............................................... 88 5.1 Giới thiệu dịch vụ IPTV trên nền IMS ........................................................... 88 5.2 Các luồng xử lý cuộc gọi trong IPTV nền IMS .............................................. 90
5.2.1 Đăng ký vào mạng IMS ........................................................................... 90 5.2.2 Call flows của các chức năng chính trong dịch vụ IPTV ......................... 93 5.2.3 Các tình huống khi đăng nhập và sử dụng dịch vụ IPTv ....................... 101
6 CHƯƠNG VI : THIẾT KẾ DỊCH VỤ IPTV ...................................................... 103 6.1 Tổng quan về công nghệ SIP Servlet ........................................................... 103
6.1.1 Mô hình SIP Servlet .............................................................................. 103 6.1.2 Các khái niệm chính của SIP Servlet API ............................................. 104
6.2 Thiết kế dịch vụ ........................................................................................... 112 6.2.1 Yêu cầu .................................................................................................. 112 6.2.2 Kiến trúc hệ thống ................................................................................. 112 6.2.3 Thiết kế các lớp cho dịch vụ .................................................................. 115 6.2.4 Kịch bản thực thi ứng dụng ................................................................... 126
6.3 Cài đặt và sử dụng dịch vụ ........................................................................... 126 6.3.1 Yêu cầu hệ thống ................................................................................... 126 6.3.2 Hướng dẫn cài đặt .................................................................................. 126 6.3.3 Kết quả thu được ................................................................................... 126
1. Poster paper gửi tại hội nghị TridentCom – Berlin ............................................ 128 2. Cài đặt Open IMS Core lên Ubuntu ................................................................... 136 3. Cài đặt máy chủ ứng dụng sailfin ...................................................................... 138 4. Cài đặt dịch vụ IPTV lên máy chủ Sailfin ......................................................... 139
Provisioning FHoSS .......................................................................................... 139 Povisioning content database ............................................................................ 139 Povisioning Diameter Peer ................................................................................ 139
7
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Povisioning User Repository ............................................................................. 139 Cấu hình máy chủ IPTV .................................................................................... 139
Tạo JDBC Resources cho MySQL(để kết nối tới máy chủ MySql) .............. 140 JDBC Connection Pool ................................................................................. 140
5. Chạy thử với HUT - Communicator .................................................................. 147 Ngữ cảnh: .......................................................................................................... 147 Thiết lập dịch vụ Iptv và Parental control: ........................................................ 147 Hoạt động .......................................................................................................... 152
8
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
DANH SÁCH HÌNH VẼ
Hình 2-1 : Kiến trúc IMS.........................................................................................18Hình 2-2 : Giao tiếp giữa PSTN/CS gateway và mạng CS......................................25Hình 2-3 : P-CSCF đặt tại mạng khách....................................................................28Hình 2-4 : P-CSCF đặt tại mạng chủ ......................................................................28Hình 2-5 : Quan hệ giữa định danh người dùng riêng và định danh người dùng công cộng theo 3GPP R5.................................................................................................33Hình 2-6 : Quan hệ giữa định danh người dùng riêng và định danh người dùng công cộng theo 3GPP R6.................................................................................................34Hình 2-7 : Cấu trúc của User Profile.......................................................................39Hình 2-8 : Cấu trúc tiêu chuẩn lọc khởi tạo.............................................................40Hình 2-9 : Sơ đồ các khối chức năng trong kiến trúc IMS.......................................43Hình 3-10 : Một ví dụ về mô tả phiên SDP..............................................................47Hình 3-11 : Các kiểu trong SDP..............................................................................48Hình 3-12 : Mô tả phiên SDP của Bob....................................................................49Hình 3-13 : Alice đăng ký vị trí người dùng với tên miền domain.com registrar... .51HÌnh 3-14: Cấu trúc gói tin Diameter......................................................................52HÌnh 3-15: Cấu trúc AVP trong gói tin Diameter....................................................53HÌnh 3-16: Diameter transaction.............................................................................54HÌnh 3-17: IFC của người dùng tải về từ HSS.........................................................57HÌnh 3-18: Repository data của 1 người dùng IPTV...............................................58Hình 3-19 : Các bước thiết lập một cuộc gọi...........................................................60Hình 3-20 : Cấu trúc bản tin SIP..............................................................................63Hình 3-21 : Transaction...........................................................................................65Hình 3-22 : Luồng cuộc gọi trong một hội thoại SIP...............................................66Hình 3-23 : Cách sử dụng Record-Route, Route và Contact....................................68Hình 4-24 : Hướng tiếp cận dịch vụ trong kiến trúc IMS........................................70Hình 4-25 : AS hoạt động như một SIP UA............................................................72Hình 4-26 : Kiến trúc logic của SIP B2BUA...........................................................73Hình 4-27 : AS ứng dụng đóng vai trò SIP B2BUA................................................73Hình 4-28 : AS đóng vai trò SIP Proxy AS.............................................................74Hình 4-29 : AS đóng vai trò SIP Redirect Server....................................................74Hình 4-30 : Sh data uml diagram.............................................................................79Hình 4-31 : Thành phần của Service Point Trigger.................................................82Hình 4-32 : Ví dụ về User Profile............................................................................84HÌnh 5-33:Quá trình đăng ký của user vào mạng IMS (tiếp)...................................90HÌnh 5-34: Quá trình đăng ký của user vào mạng IMS (tiếp)..................................91HÌnh 5-35: Quá trình đăng ký của user vào mạng IMS (tiếp)..................................92HÌnh 5-36: Người dùng thông thường ....................................................................94HÌnh 5-37: Đăng nhập với dịch vụ IPTV trường hợp có Access control.................95
9
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 5-38: Dịch vụ truyền hình cơ bản...................................................................96HÌnh 5-39: Dịch vụ VoD tiêu chuẩn........................................................................99HÌnh 5-40: Dịch vụ VoD nâng cao........................................................................100Hình 6-41 : Vòng đời của Servlet..........................................................................106Hình 6-42 : Minh họa cấu trúc phân cấp của đối tượng SipServletRequest và SipServletResponse...............................................................................................110HÌnh 6-43: Mô hình tổng quát dịch vụ IMS based IPTV.......................................113HÌnh 6-44: sơ đồ lớp cho gói user profile..............................................................116HÌnh 6-45: Sơ đồ lớp gói servlets..........................................................................117HÌnh 6-46: Các lớp trong gói tools........................................................................118HÌnh 6-47: Sơ đồ lớp gói diameter........................................................................119HÌnh 6-48: Lưu đồ thuật toán khởi tạo dịch vụ.....................................................122HÌnh 6-49: Lưu đồ thuật toán đăng nhập vào dịch vụ............................................123HÌnh 6-50: Lưu đồ thuật toán xử lý yêu cầu kênh.................................................125
DANH SÁCH BẢNG BIỂU
Bảng 3-1: Diameter commands...............................................................................52Bảng 3-2: Diameter AVPs.......................................................................................53
10
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
DANH SÁCH CÁC TỪ VIẾT TẮT
STT Từ viết
tắt
Tên đầy đủ
01 3GPP Third Generation Partnership Project
02 3GPP2 Third Generation Partnership Project 2
03 ACK Acknowledgment
04 ADSL Asymmetric Digital Subscriber Line
05 AS Application Server
06 ATM Asynchoronous Transfer Mode
07 B2BUA Back-to-back User Agent
08 BGCF Breakout Gateway Control Function
09 BICC Bearer Independent Call Control
10 COPS Common Open Policy Service
11 CSCF Call Session Control Function
12 DHCP Dynamic Host Configuration Protocol
13 DNS Domain Name System
14 ENUM Telephone Number Mapping
15 GGSN Gateway GPRS Support Node
16 GPRS General Packet Radio Service
17 GSM Global System for Mobile Communications
18 HLR Home Location Register
19 HSS Home Subscriber Serverhttp://www.acronymfinder.com/Global-
System-for-Mobile-Communications-%28cellular-phone-20 HTTP Hypertext Transfer Protocol
21 I-CSCF Interrogating-CSCF
22 IETF Internet Engineering Task Force
23 IFC Initial Filter Criteria
24 IM-SSF IP Multimedia Service Switching Function
25 IMS IP Multimedia Subsystem
11
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
26 IMSI International Mobile Subscriber Identifier
27 IP Internet Protocol
28 IP-CAN IP Connectivity Access Network
29 ISC IMS Service Control
30 ISIM IP multimedia Services Identity Module
31 ISUP ISDN User Part
32 ITU-T International Telecommunication Union-Telecommunications
33 MAP Mobile Application Part
34 MEGACO Media Gateway Control
35 MGCF Media Gateway Control Function
36 MGW Media Gateway
37 MIME Multipurpose Internet Mail Extensions
38 MRF Media Resource Function
39 MRFC Media Resource Function Controllers
40 MRFP Media Resource Function Processors
41 MSISDN Mobile Subscriber ISDN Number
42 NAI Network Access Identifier
43 OSA-SCS Open Service Access–Service Capability Server
44 P-CSCF Proxy-CSCF
45 PA Presence Agent
46 PDF Policy Decision Function
47 PEP Policy Enforcement Point
48 PIDF Presence Information Data Format
49 PS Presence Agent
50 PSI Public Service Identity
51 PSTN Public Switched Telephone Network
52 PUA Presence User Agent
53 QoS Quality of Service
12
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
54 RTP Real-Time Transport Protocol
55 RTCP RTP Control Protocol
56 S-CSCF Serving-CSCF
57 SCTP Stream Control Transmission Protocol
58 SDP Session Description Protocol
59 SFC Subsequent Filter Criteria
60 SGSN Serving GPRS Support Node
61 SGW Signalling Gateway
62 SIM Subscriber Indetity Module
63 SIP Session Initiation Protocol
64 SLF Subscriber Location Function
65 SPT Service Point Trigger
66 SS7 Sinaling System No. 7
67 TCP Transmission Control Protocol
68 THIG Topology Hiding Inter-network Gateway
69 UA User Agent
70 UAC User Agent Client
71 UAS User Agent Server
72 UDA User Data Answer
73 UDP User Datagram Protocol
74 UDR User Data Request
75 UE User Equipment
76 UICC Universal Integrated Circuit Card
77 UMTS Universal Mobile Telecommunication System
78 URI Uniform Resource Identifier
79 URL Uniform Resource Locator
80 USIM Universal Subscriber Identity Module
81 VoIP Voice over IP
13
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
82 VoD Video on Demand
83 WAP Wireless Application Protocol
84 WLAN Wireless Local Access Network
85 WLSS WebLogic SIP Server
86 XML Extensible Markup Language
14
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
1 CHƯƠNG I : MỞ ĐẦU
1.1 Tầm quan trọng của đề tàiIMS là 1 công nghệ trong đó hội tụ và triển khai thoại và dữ liệu trên 1
platform duy nhất, và là 1 kiến trúc mở sử dụng giao thức Internet. Với IMS,
rất nhiều dịch vụ đa phương tiện có thể được cung cấp bởi chỉ 1 nhà mạng hay
với chỉ 1 thiết bị mọi lúc mọi nơi. Trong quá khứ, truyền thông không dây và
có dây và hệ thống cáp được triển khai tách biệt, nhưng giờ đây, những hệ
thống như thế có thể hội tụ lại thành 1 mạng truy cập thông qua nền tảng IMS
và qua 1 nền tảng duy nhất đó, các nhà cung cấp dịch vụ có thể giảm chi phí
quản lý và tăng hiệu suất hoạt động của mình.
Thêm vào đó, với vai trò là 1 kiến trúc tiêu chuẩn, IMS làm tăng tính tương
thích giữa các nhà cung cấp thiết bị cũng như dịch vụ, do đó làm tăng tốc độ
phát triển ứng dụng 1 cách đáng kể. Có nghĩa là càng ngày càng có nhiều dịch
vụ thân thiện, tiện lợi hướng tới người dùng hơn dẫn đến làm tăng sự thoải
mái của khách hàng.
IPTV là một trong những dịch vụ mà IMS có thể cung cấp tới người dùng. Ý
tưởng của dịch vụ này cũng không ngoài mục đích đem lại sự tiện lợi cho
người dùng:
“Hàng ngày đi làm về Nam hay xem TV trên xe bus. Chương trinh ưa thích
của anh ý là kênh thông tinh quốc gia VTV1. Sau khi quay số đến 1 địa chỉ
dạng email ([email protected]), kênh truyền hình này lập tức được trả về
và hiển thị trên màn hình điện thoại, dễ dàng và đơn giản như là thực hiện 1
cuộc gọi tới bạn bè. Tất cả những kênh ưa thích đều được lưu giữ trên máy
chủ của nhà cung cấp và được chia sẻ với chiếc Setopbox ở nhà anh ý.”
15
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
“Nam rất háo hức về bộ phim Iron man2. 1 ngày anh nhận được tin nhắn từ
dịch vụ IPTv mà anh đã đăng ký là Iron man2 đã có trên kho phim theo yêu
cầu. Tối hôm đó Nam quay số tới [email protected] bằng chiếc STB ở
nhà, sau đó chọn bộ phim ưa thích của mình trong danh sách kênh trả về của
nhà mạng.”
“Nam rất hài lòng với chất lượng cũng như giá của bộ phim và trên màn hình
ti vi anh mở danh sách bạn bè ra và gửi 1 tin nhắn ngắn tới người bạn của
mình là Hùng([email protected])”
…
Tất nhiên ngữ cảnh trên chưa thực tế ở thời điểm hiện tại, tuy nhiên trong 1
tương lai rất gần, câu chuyện này sẽ trở nên phổ biến. Những giao tiếp tương
tác dịch vụ như thê sẽ trở nên rất dễ dàng khi được hỗ trợ bởi kiến trúc IMS
1.2 Nội dung nghiên cứuVới mực đích nghiên cứu là phát triển ứng dụng theo kiến trúc IMS nên trong
đề tài này em sẽ tập trung tìm hiểu tổng quan về IMS, máy chủ ứng dụng và
về dịch vụ IPTV:
• Tổng quan về IMS: tìm hiểu về kiến trúc IMS, các thành phần, chức
năng của từng thành phần, kiến trúc triển khai và một số các khái niệm
quan trọng sử dụng trong IMS.
• Các giao thức liên quan: giới thiệu về 1 số giao thức quan trọng chủ
yếu dùng trong mạng IMS, phục vụ cho đề tài.
• Giới thiệu dịch vụ IPTV: tổng quát về dịch vụ IPTV, các call flow
quan trọng trong dịch vụ, các tình huống trong sử dụng dịch vụ.
• Thiết kế dịch vụ IPTV: thiết kế dịch vụ từ các yêu cầu thực tế, sơ đồ
lớp.
16
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Triển khai dịch vụ: các bước sử dụng dịch vụ đối với người dùng
cuối.
2 CHƯƠNG II : VỀ KIẾN TRÚC IMS
Trong chương này sẽ nói về kiến trúc IMS, chi tiết các thành phần của nó và 1
số khái niệm cơ bản liên quan đến mạng IMS và kết nối giữa nó và các kiến
trúc mạng khác
2.1 Kiến trúc tổng quát IMSTrước khi tìm hiểu kiến trúc tổng quát IMS, chúng ta nên nhớ rằng 3GPP
không chuẩn hóa theo nút mà theo chức năng. Điều đó có nghĩa là kiến trúc
IMS là một tập hợp các chức năng được kết nối với nhau bởi các giao diện đã
được chuẩn hóa. Các nhà triển khai có thể kết hợp hai chức năng vào một nút.
Tương tự, các nhà triển khai có thể tách một chức năng thành hai hay nhiều
nút.
Nhìn chung thì hầu hết những dịch vụ cung cấp đều tuân theo kiến trúc IMS
một cách chặt chẽ và triển khai mỗi chức năng trong một nút riêng. Tuy nhiên,
việc tìm kiếm các nút triển khai nhiều hơn một chức năng và các chức năng
được phân phối qua nhiều hơn một nút là hoàn toàn có thể.
17
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 2-1 : Kiến trúc IMS
Trong hình 2-1 minh họa một cái nhìn tổng quan về kiến trúc IMS như chuẩn
hóa của 3GPP. Trong hình chỉ ra hầu hết các giao diện báo hiệu trong hệ
thống IMS, nó thường được đề cập đến bởi hai hay ba ký tự mã hóa. Chúng ta
không thể vẽ tất cả các giao diện được định nghĩa trong IMS mà chỉ có thể liệt
kê hầu hết những nút giao diện có liên quan. Trong IMS được phân chia thành
3 phần: mạng truy nhập, mạng lõi và tầng dịch vụ.
2.1.1 Mạng truy nhập
Ở phía bên trái hình 2-1, chúng ta có thể nhìn thấy các đầu cuối IMS di động
thường được nhắc đến như là các thiết bị người dùng (User Endpoint). Đầu
cuối IMS được nối vào mạng chuyển mạch gói như là GPRS thông qua
đường truyền vô tuyến.
Chú ý rằng, mặc dù hình trên chỉ chỉ ra một thiết bị đầu cuối IMS nối vào
mạng sử dụng đường truyền vô tuyến nhưng IMS cũng hỗ trợ các loại thiết
bị và các cách truy nhập khác. Thiết bị hỗ trợ cá nhân PDAs và máy tính là
18
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
các ví dụ về các thiết bị có thể kết nối tới IMS. Một ví dụ khác về phương
pháp truy cập là WLAN và ADSL.
2.1.2 Mạng lõi
Phần còn lại của hình chỉ ra các nút bao gồm trong mạng lõi IMS. Các nút
này là:
• Một hay vài cơ sở dữ liệu người dùng, còn gọi là HSS và SLF.
• Một hay vài máy chủ ứng SIP gọi là CSCF (Call Session Control
Function).
• Một hay vài MRF mỗi cái được chia nhỏ thành MRFC và MRFP.
• Một hay vài BGCF (Breakout Gateway Control Functions).
• Một hoặc vài PSTN gateways, được chia nhỏ hơn thành SGW và
MGCF.
2.1.2.1 Cơ sở dữ liệu HSS và SLF
HSS (Home Subscriber Server) là trung tâm lưu trữ dữ liệu các thông tin
liên quan đến người dùng. Về kỹ thuật thì HSS giống như HLR (Home
Location Register), HLR là một nút trong mạng GSM. HSS bao gồm các
thông tin thuê bao liên quan đến người dùng được yêu cầu để điều khiển
các phiên đa phương tiện. Những dữ liệu này bao gồm, thông tin vị trí,
thông tin bảo mật (bao gồm các thông tin nhận thực và phân quyền), các
thông tin về tiểu sử người dùng (bao gồm các dịch vụ mà người dùng đăng
ký thuê bao), và S-CSCF cấp phát tới người dùng.
Một mạng có thể chứa một hoặc một vài HSS, trong trường hợp số lượng
thuê bao quá nhiều so với sự quản lý của một HSS. Trong tất cả trường
hợp, tất cả các dữ liệu liên quan đến một người dùng cụ thể được chứa
trong một HSS. Các mạng với một HSS sẽ không cần SLF (Subscriber
19
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Location Function). Mặt khác, mạng với nhiều hơn một HSS yêu cầu có
SLF.
SLF là một cơ sở dữ liệu đơn giản ánh xạ địa chỉ người dùng tới HSS quản
lý tương ứng. Một nút yêu cầu truy vấn SLF, với một địa chỉ người dùng là
đầu vào, sẽ thu được ở đầu ra là HSS có chứa thông tin liên quan đến người
dùng đó.
Cả HSS và SLF đều thực thi giao thức Diameter với các đặc trưng ứng
dụng diameter cho IMS.
2.1.2.2 Chức năng điều khiển cuộc gọi phiên
Điều khiển cuộc gọi phiên (CSCF) là một máy chủ SIP, là một nút cần thiết
trong IMS. Các CSCF xử lý các bản tin báo hiệu SIP trong IMS. Có ba loại
CSCF phụ thuộc vào các chức năng mà chúng cung cấp:
• Proxy-CSCF (P-CSCF) : là một máy chủ SIP, là điểm đầu tiên liên
lạc giữa đầu cuối IMS và mạng IMS. Nó có thể được đặt ở mạng
khách (trong toàn bộ mạng IMS) hoặc mạng chủ. Một vài mạng có
thể sử dụng thiết bị kiểm soát biên giới phiên SBC (Session Border
Controller) để thực hiện chức năng này. Để kết nối với hệ thống
IMS, người dùng trước tiên phải gửi đăng ký tới P-CSCF trong
mạng mà nó đang kết nối. Địa chỉ của P-CSCF được truy cập thông
qua giao thức DHCP (Dynamic Host Configuration Protocol) hoặc
sẽ được cung cấp khi người dùng tiến hành thiết lập kết nối PDP
(Packet Data Protocol) trong mạng thông tin di động tế bào. Chức
năng của P-CSCF bao gồm:
o P-CSCF có nhiệm vụ đảm bảo chuyển tải các yêu cầu từ UE
đến máy chủ SIP (ở đây là S-CSCF) cũng như bản tin phản
hồi từ máy chủ SIP về UE.
20
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
o P-CSCF được gán cho đầu cuối IMS trong suốt quá trình
đăng ký, và không thay đổi trong suốt quá trình đăng ký.
o P-CSCF nằm trên đường đi của tất cả các bản tin báo hiệu và
có thể được gán vào mỗi bản tin.
o P-CSCF xác thực người dùng và thiết lập kết nối bảo mật
IPSec với thiết bị đầu cuối IMS của người dùng. P-CSCF còn
có vai trò ngăn cản các tấn công như spoofing, replay để đảm
bảo sự bảo mật và an toàn cho người dùng.
o P-CSCF có thể nén và giải nén các bản tin SIP dùng sigcomp,
để giảm thiểu khối lượng thông tin báo hiệu truyền trên
những đường truyền tốc độ thấp (hay giảm độ trễ khi truyền
trên các kênh có băng thông hẹp).
o P-CSCF có thể tích hợp chức năng quyết định chính sách
PDF (Policy Decision Function) nhằm quản lý và đảm bảo
QoS cho các dịch vụ đa phương tiện.
o P-CSCF cũng tham gia vào quá trình tính cước dịch vụ.
• Interrogating-CSCF (I-CSCF) : là một máy chủ SIP khác được
đặt ở biên của miền quản trị. Địa chỉ IP của I-CSCF được công bố
trong DNS (Domain Name System) của miền, vì thế các máy chủ
ứng dụng ở xa có thể tìm thấy I-CSCF và sử dụng I-CSCF như một
điểm chuyển tiếp cho các gói tin SIP tới miền này. Các chức năng
của I-CSCF bao gồm:
o Định tuyến bản tin yêu cầu SIP nhận được từ một mạng khác
đến S-CSCF tương ứng. Để làm được điều này, I-CSCF sẽ
truy vấn HSS thông qua giao diện Diameter Cx để cập nhật
địa chỉ S-CSCF tương ứng của người dùng (giao diện Dx
21
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
được dùng để từ I-CSCF tới SLF để định vị HSS cần thiết).
Nếu như chưa có S-CSCF nào được gán cho UE, I-CSCF sẽ
tiến hành gán một S-CSCF cho người dùng để nó xử lý yêu
cầu SIP.
o Ngược lại, I-CSCF sẽ định tuyến bản tin yêu cầu SIP hoặc
bản tin trả lời SIP đến một S-CSCF/I-CSCF nằm trong mạng
của một nhà cung cấp dịch vụ khác.
I-CSCF luôn luôn được đặt tại mạng chủ, trong một số trường hợp
như THIG (Topology Hiding Inter-network Gateway), I-CSCF được
đặt tại mạng khách là tốt nhất.
• Serving-CSCF (S-CSCF) : là một nút trung tâm của hệ thống báo
hiệu IMS. S-CSCF vận hành giống như một máy chủ SIP nhưng nó
cũng bao hàm cả chức năng quản lý phiên dịch vụ. Thêm vào việc
thực hiện chức năng là một máy chủ SIP thì nó cũng đóng vai trò
như một trung tâm đăng ký SIP (SIP registrar). Điều này có nghĩa là
nó duy trì mối liên hệ giữa vị trí của người dùng (nói cách khác là
địa chỉ IP của thiết bị đầu cuối mà người dùng đăng nhập) với địa
chỉ SIP của người dùng đó (cũng được biết đến như là định danh
chung của người dùng – Public User Identity).
Cũng giống như I-CSCF, S-CSCF cũng thực thi một giao diện
diameter với HSS. Lý do chính của việc sử dụng giao diện với HSS
là:
o Để tải các vector nhận thực của người dùng đang cố gắng truy
cập mạng từ HSS. S-CSCF sử dụng vector này để nhận thực
người dùng.
22
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
o Để tải hồ sơ người dùng từ HSS. Hồ sơ người dùng bao gồm
các triggers có thể làm cho bản tin SIP được định tuyến qua
một hoặc vài máy chủ ứng dụng.
o Để khai báo với HSS về S-CSCF được cấp cho người dùng
trong suốt quá trình đăng ký.
Tất cả các bản tin báo hiệu SIP mà đầu cuối IMS gửi và nhận đều đi
quá S-CSCF. S-CSCF sẽ kiểm tra mỗi bản tin SIP và quyết định xem
liệu bản tin báo hiệu này nên đi qua một hay nhiều máy chủ ứng
dụng trên đường đi tới đích cuối cùng của nó. Các máy chủ ứng
dụng này sẽ cung cấp các khả năng về một dịch vụ tới người dùng.
Một chức năng chính của S-CSCF là cung cấp dịch vụ định tuyến
bản tin SIP. Nếu người dùng quay số điện thoại thay vì sử dụng SIP
URI (Uniform Resource Identifier) thì S-CSCF cung cấp một dịch
vụ chuyển đổi, thường dựa trên chuẩn DNS E.164 Number
Translation (DNS/ENUM) (được mô tả trong RFC-2916 [100]).
S-CSCF cũng tác động vào chính sách mạng của nhà cung cấp. Ví
dụ, một người dùng có thể không có quyền thiết lập một phiên cụ thể
nào cả. S-CSCF tránh cho người dùng thực hiện các chức năng
không được cho phép.
Một mạng thường bao gồm một số các S-CSCF cho mục đích mở
rộng và dự phòng. Mỗi S-CSCF phục vụ một số lượng đầu cuối tùy
thuộc vào dung lượng của nó.
S-CSCF luôn luôn được đặt tại mạng chủ.
2.1.2.3 Máy chủ xử lý media
Máy chủ xử lý media (MRF) cung cấp tài nguyên media trong mạng chủ.
MRF (Media Resource Function) cung cấp cho mạng chủ khả năng đưa ra
23
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
các thông báo trong luồng media (ví dụ trong cầu hội thảo tập trung),
chuyển đổi giữa các loại mã hóa, thu nhận số liệu thống kê và thực hiện bất
cứ loại phân tích media nào.
MRF còn được chia thành một nút nhỏ hơn trong miền báo hiệu gọi là
MRFC (Media Resource Function Controller) và một nút trong miền media
là MRFP (Media Resource Function Processor). MRFC hoạt động như là
một SIP User Agent và chứa các giao diện SIP với S-SCSF. MRFC điều
khiển tài nguyên trong MRFP thông qua giao diện H.248.
MRFP triển khai tất cả các hàm liên quan đến media như là chơi và trộn
media.
MRF luôn đặt ở mạng chủ.
2.1.2.4 Chức năng điều khiển cổng chuyển mạng
Chức năng điều khiển cổng chuyển mạng (BGCF) thực hiện chủ yếu là
chức năng của máy chủ SIP bao gồm chức năng định tuyến dựa trên số điện
thoại. BGCF (Breakout Gateway Control Function) chỉ dùng trong các
phiên được khởi tạo bởi đầu cuối IMS và hướng tới một người dùng trong
mạng chuyển mạch kênh như là PSTN hay PLMN. Chức năng chính của
BGCF là:
• Lựa chọn mạng thích hợp nơi mà tương tác với miền chuyển mạch
kênh xảy ra.
• Hoặc lựa chọn cổng PSTN/CS phù hợp, nếu tương tác xảy ra trong
cùng một mạng mà BGCF được đặt.
2.1.2.5 PSTN/CS Gateway
24
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
PSTN gateway cung cấp một giao diện hướng tới một mạng chuyển mạch
kênh, cho phép các thiết bị đầu cuối IMS gọi và nhận cuộc gọi tới PSTN và
từ PSTN.
Hình 2-2 : Giao tiếp giữa PSTN/CS gateway và mạng CS
Hình 2-2 mô tả một BGCF và một PSTN gateway riêng biệt có giao tiếp
mạng với PSTN. PSTN gateway được phân tích thành các chức năng sau:
• SGW (Signalling Gateway) : Signalling gateway giao tiếp với mặt
phẳng báo hiệu của mạng chuyển mạch kênh. SGW thực hiện biến
đổi giao thức ở lớp thấp hơn. Ví dụ: SGW có nhiệm vụ thay thế các
giao thức MTP (ITU-T khuyến nghị Q.701 [133]) ở mức thấp hơn
vận chuyển cùng với SCTP (Stream Control Transmission Protocol,
được định nghĩa tại RFC 2960 [230]) trên địa chỉ IP. Vì thế, SGW
chuyển đổi ISUP (ITU-T khuyến nghị Q.761 [139]) hoặc BICC
25
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
[ITU-T khuyến nghị tại Q.1901 [140]) trên MTP thành ISUP hoặc
BICC trên SCTP/IP.
• MGCF (Media Gateway Control Function) : MGCF là nút trung tâm
của PSTN/CS gateway. MGCF triển khai một cơ chế thực hiện
chuyển đổi giao thức và ánh xạ SIP sang hoặc là ISUP trên IP hoặc
là BICC trên IP (cả BICC và ISUP đều là các giao thức điều khiển
cuộc gọi trong mạng chuyển mạch kênh). Hơn nữa, để biến đổi giao
thức điều khiển cuộc gọi thì MGCF điều khiển nguồn tài nguyên
trong MGW (Media Gateway). Giao thức được sử dụng giữa MGCF
và MGW là H.248 (ITU-T khuyến nghị H.248 [143]).
• MGW (Media Gateway) : Media Gateway giao tiếp với mặt phẳng
media của mạng PSTN hoặc mạng CS. Một mặt MGW có thể gửi
hoặc nhận media của IMS thông qua giao thức RTP (RFC 3550
[225]). Mặt khác, MGW sử dụng một hoặc nhiều khe thời gian PCM
(Pulse Code Modulation) để kết nối tới mạng CS. Thêm vào đó,
MGW thực hiện chuyển đổi mã khi đầu cuối IMS không hỗ trợ
codec được sử dụng bởi mạng chuyển mạch kênh. Một tình huống
phổ biến thường xảy là khi thiết bị đầu cuối IMS sử dụng bộ giải mã
AMR trong khi đó thiết bị đầu cuối của mạng PSTN lại sử dụng bộ
giải mã G.711 (ITU-T khuyến nghị G.711 [131]).
2.1.2.6 Mạng chủ và mạng khách
IMS mượn một vài khái niệm từ GSM và GPRS như mạng chủ và mạng
khách. Trong mô hình tế bào, khi chúng ta sử dụng điện thoại di động trong
khu vực nơi chúng ta cư trú, khi đó là chúng ta đang sử dụng cơ sở hạ tầng
do các nhà điều hành mạng cung cấp. Cở sở hạ tầng này hình thành mạng
chủ (home network). Mặt khác, khi chúng ta chuyển ra ngoài khu vực che
26
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
phủ của mạng chủ, chúng ta sử dụng cơ sở hạ tầng được cung cấp bởi một
nhà điều hành mạng khác. Cơ sở hạ tầng này được gọi là mạng khách
(visited network).
Để sử dụng mạng khách thì các nhà điều hành mạng khách và mạng chủ
phải có một thỏa thuận với nhau. Các thỏa thuận này có thể là giá cước
cuộc gọi, chất lượng dịch vụ hoặc là phương thức quy đổi bảng tính cước.
Hầu hết các nút IMS được đặt tại mạng chủ nhưng có nút cũng được đặt
trong mạng khách hoặc mạng chủ, nút đó là P-CSCF. Kiến trúc IMS cho
phép hai cấu hình khác nhau cho P-CSCF, tùy thuộc vào vị trí của P-CSCF
ở mạng khách hay mạng chủ.
Thêm vào đó, khi IP-CAN (IP Connectivity Access Network) là GPRS thì
vị trí của P-CSCF phụ thuộc vào vị trí của GGSN. Trong tình huống
chuyển vùng, GPRS cho phép vị trí của GGSN hoặc ở trong mạng chủ
hoặc ở trong mạng khách (bình thường SGSN luôn được đặt ở mạng
khách).
Trong IMS cả GGSN và P-CSCF phải nằm trong cùng một mạng. Điều này
cho phép P-CSCF điều khiển GGSN qua giao diện Go. Vì cả P-CSCF và
GGSN đều nằm trong cùng một mạng nên giao diện Go luôn luôn là giao
diện hoạt động bên trong và làm cho việc hoạt động của mạng đơn giản
hơn.
Hình 2-3, cho chúng ta thấy cấu hình P-CSCF (và GGSN) đặt tại mạng
khách. Cấu hình này thể hiện tầm nhìn lâu dài về IMS vì nó yêu cầu IMS
hỗ trợ thực hiện từ mạng khách.
27
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 2-3 : P-CSCF đặt tại mạng khách
Không thể mong đợi tất cả các mạng trên thế giới đều triển khai IMS đồng
thời. Do đó cũng không thể mong chờ tất cả các mạng thành phần sẽ cập
nhật các GGSN theo cùng một chuẩn tại cùng một thời điểm và cùng bắt
đầu cung cấp dịch vụ IMS. Vì vậy chúng ta chỉ có thể mong chờ việc sớm
có sự triển khai IMS mà P-CSCF ở trong mạng chủ như hình 2-4 dưới đây.
Hình 2-4 : P-CSCF đặt tại mạng chủ
Hình 2-4 chỉ ra cấu hình hiện tại khi cả P-CSCF và GGSN đều đặt tại mạng
chủ. Cấu hình này không yêu cầu sự hỗ trợ IMS từ mạng khách. Mạng
khách không cần phải có GGSN tuân theo phiên bản 3GPP Release 5.
Mạng khách chỉ cần cung cấp liên lạc vô tuyến và SGSN. Vì thế, cấu hình
28
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
này được triển khai từ những ngày đầu của IMS. Như một hệ quả, người ta
mong muốn rằng nó sẽ là cấu hình phổ biến trong những năm đầu triển khai
IMS.
2.1.3 Tầng dịch vụ
Phần này bao gồm các máy chủ ứng dụng có nhiệm vụ cung cấp các dịch vụ
tới người dùng cuối. Các máy chủ ứng dụng là các thực thể SIP thực hiện
dịch vụ và giao tiếp với S-CSCF sử dụng SIP. Phụ thuộc vào các dịch vụ
thực tế mà máy chủ ứng dụng có thể hoạt động ở các chế độ: SIP proxy, chế
độ SIP UA (User Agent) hay chế độ SIP B2BUA (Back-to-Back User
Agent). Máy chủ ứng dụng có thể nằm trong mạng chủ hoặc trong một mạng
thứ ba bên ngoài. Nếu nằm trong mạng chủ, nó có thể truy vấn HSS qua giao
diện diameter Sh (cho máy chủ ứng dụng), hay giao diện MAP (Mobile
Application Part) cho loại máy chủ IM-SSF (IP Multimedia Service
Switching Function).
Như đã nói ở trên, ưu điểm lớn nhất của IMS là khả năng phát triển các dịch
vụ mới một cách dễ dàng. Kiến trúc IMS được thiết kế để cho phép các nhà
điều hành cung cấp dải rộng các dịch vụ dựa trên chuyển mạch gói và thời
gian thực. IMS cũng cho phép lưu lại các thông tin của dịch vụ để có thể tính
cước dựa theo thời gian cũng như dựa trên dịch vụ và băng thông. Từ đặc
điểm thiết kế của mình, IMS kế thừa tất cả các dịch vụ ưu việt nhất của mạng
viễn thông và mạng internet đặc biệt là các dịch vụ đa phương tiện bao gồm
các dịch vụ gọi thông thường và các dịch vụ nâng cao như:
• Nhấn tin đa phương tiện
• Hội thảo đa phương tiện
• IPTV
• Dịch vụ kiểm tra trạng thái người dùng (Presence)
29
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Dịch vụ instant message
Tầng dịch vụ được thiết kế tách rời với mạng lõi và mạng truy nhập đã được
chuẩn hóa.
2.2 Định danh trong IMSTrong bất kỳ một mạng nào cũng đều phải dịnh danh được người dùng một
cách duy nhất. Đây là thuộc tính cho phép một điện thoại nhất định đổ chuông
mà không phải là một điện thoại khác khi chúng ta quay số trong mạng PSTN.
Vấn đề trung tâm của bất kỳ một mạng nào là khả năng của nhà cung cấp định
danh người dùng để cho cuộc gọi có thể đến được đúng người dùng. Trong
mạng điện thoại công cộng, người dùng được định danh bởi số điện thoại (là
một tập hợp các chữ số theo thứ tự định danh thuê bao điện thoại). Số điện
thoại xác định chủ thuê bao có thể được biểu diễn dưới nhiều dạng khác nhau:
dạng số nội hạt, số ngoại hạt hay số dạng quốc tế. Thực chất chúng chỉ là các
cách biểu diễn khác nhau của cùng một thuê bao. Độ dài của chuỗi số phụ
thuộc vào đích đến của cuộc gọi (ví dụ như cùng một khu vực, khác vùng hay
quốc gia khác).
Thêm vào đó, khi một dịch vụ được cung cấp, đôi khi nó cũng yêu cầu định
danh dịch vụ. Trong mạng PSTN, dịch vụ được định danh bởi những số đặc
biệt, thường có phần tiếp đầu đặc biệt, ví dụ như 800. IMS cũng cung cấp cơ
chế để định danh dịch vụ.
2.2.1 Định danh người dùng công cộng
Trong IMS cungc có một cách tiền định để xác định người dùng. Một người
dùng IMS cũng được cấp phát một hay nhiều định danh người dùng công
cộng. Nhà cung cấp dịch vụ nội hạt có trách nhiệm cấp phát các định danh
này cho mỗi thuê bao IMS. Một danh người dùng công cộng có thể là một
SIP URI (như định nghĩa trong RFC 3261 [215]) hay một TEL URI (như
30
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
định nghĩa trong RFC 3966 [220]). Định danh người dùng công cộng được
sử dụng như thông tin liên lạc trong thẻ thương mại. Trong IMS, định danh
người dùng công cộng được sử dụng để định tuyến các bản tin báo hiệu SIP.
Nếu chúng ta so sánh giữa IMS và GSM, một dịnh danh người dùng công
cộng đối với IMS cũng giống như một định danh MSISDN (Mobile
Subscriber ISDN Number) trong mạng GSM.
Khi định danh người dùng công cộng chứa SIP URI, nó thường có dạng là
sip:[email protected], mặc dù nhà cung cấp IMS có thể chuyển đổi
dạng thức này và thỏa mãn theo nhu cầu của họ. Thêm vào đó, cũng có khả
năng bao hàm số điện thoại trong SIP URI sử dụng định dạng sau:
sip:[email protected];user=phone
Định dạng này là cần thiết bởi SIP yêu cầu URI được đăng ký dưới là SIP
URI. Do đó, nó không thể đăng ký TEL URI trong SIP, mặc dù hoàn toàn có
thể đăng ký một SIP URI có chứa một số điện thoại.
TEL URI là một dạng khác mà định danh người dùng công cộng có thể sử
dụng được. Dưới đây là một TEL URI được trình bày dưới dạng số điện
thoại quốc tế:
tel:+1-212-555-0293
TEL URI là cần thiết để thực hiện một cuộc gọi từ đầu cuối IMS sang mạng
điện thoại công cộng PSTN, bởi vì số điện thoại PSTN được biểu diễn dưới
dạng số. Mặt khác, TEL URI cũng cần thiết nếu một thuê bao PSTN muốn
thực hiện một cuộc gọi đến một người dùng IMS, bởi vì người dùng PSTN
chỉ có thể quay số.
Chúng ta hình dung các nhà cung cấp dịch vụ sẽ cấp ít nhất một SIP URI và
một TEL URI cho mỗi một người dùng. Có rất nhiều lý do cho việc cấp
nhiều hơn một định danh người dùng công cộng cho một người dùng, như là
khả năng phân biệt các định danh cá nhân mà bạn bè và người thân đã biết 31
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
với định danh công cộng dùng trong công việc kinh doanh được biết đến bởi
các đồng nghiệp, hoặc là để kích hoạt một nhóm các dịch vụ.
IMS mang đến một khái niệm thú vị: một tập hợp định danh người dùng
công cộng được đăng ký. Trong hoạt động thông thường của SIP, mỗi định
danh cần đăng ký yêu cầu một bản tin SIP REGISTER. Trong IMS, ta có thể
đăng ký một vài định danh người dùng công cộng trong một bản tin, điều này
nhằm tiết kiệm thời gian và băng thông.
2.2.2 Định danh người dùng riêng
Mỗi thuê bao IMS được cấp một định danh người dùng riêng. Không giống
như định danh người dùng công cộng, định danh người dùng riêng không
phải là một SIP URI hay TEL URI, mà thay vào đó chúng thường có định
dạng của định danh người dùng truy nhập NAI (Network Access Identifier,
theo quy ước của RFC 2486 [451]). Định dạng của NAI là:
Không như định danh người dùng công cộng, định danh người dùng riêng
không được sử dụng để định tuyến bản tin yêu cầu SIP, thay vào đó chúng
được dành riêng cho việc định danh thuê bao và cho mục đích nhận thực.
Một định danh người dùng riêng thực hiện chức năng trong IMS tương tự
như IMSI (International Mobile Subscriber Identifier) trong mạng GSM.
Định danh người dùng riêng không cần người dùng biết đến, bởi vì nó có thể
được lưu trong một thẻ thông minh cũng giống như IMSI được lưu trong
SIM (Subscriber Identity Module).
2.2.3 Mối quan hệ giữa định danh công cộng và định danh riêng
Nhà cung cấp dịch vụ cấp một hoặc nhiều định danh người dùng công cộng
cho mỗi một người dùng. Trong trường hợp GSM/UMTS (Universal Mobile
32
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Telecommunication System), thẻ thông minh lưu định danh người dùng riêng
và có ít nhất một định danh người dùng công cộng. HSS là một cơ sở dữ liệu
chung cho mọi dữ liệu liên quan đến thuê bao, chứa định danh người dùng
riêng và một tập hợp các định danh người dùng công cộng được gán cho
người dùng. HSS và S-CSCF cũng có tương quan với định danh người dùng
cộng và định danh người dùng riêng. Mối quan hệ giữa một thuê bao, định
danh người dùng riêng và một số định danh người dùng công cộng được thể
hiện như trong hình 2-5. Đây là trường hợp của IMS như chuẩn hóa trong
3GPP Release 5.
Hình 2-5 : Quan hệ giữa định danh người dùng riêng và định danh
người dùng công cộng theo 3GPP R5
3GPP Release 6 mở rộng mối quan hệ giữa định danh người dùng riêng và
định danh người dùng chung như ở hình 2-6 dưới đây. Một thuê bao IMS
được cấp không chỉ một mà là một số định danh người dùng riêng. Trong
trường hợp UMTS, chỉ một định danh người dùng riêng được lưu trữ trong
thẻ thông minh, nhưng người dùng có thể có nhiều thẻ thông minh khác nhau
mà họ có thể cho vào đầu cuối IMS. Có thể các định danh người dùng công
cộng này được sử dụng kết hợp với nhiều hơn một dịnh danh người dùng
riêng. Đó là trường hợp của định danh người dùng công cộng số 2 trong hình
33
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
2-6, bởi vì nó được gán cho cả định danh người dùng riêng số 1 và số 2. Điều
này cho phép định danh người dùng công cộng số 2 có thể sử dụng đồng thời
từ hai đầu cuối IMS, mỗi một thiết bị được gán một định danh người dùng
riêng khác nhau (ví dụ như các thẻ thông minh khác nhau được gắn vào các
đầu cuối khác nhau).
Hình 2-6 : Quan hệ giữa định danh người dùng riêng và định danh
người dùng công cộng theo 3GPP R6
2.2.4 Định danh dịch vụ công cộng
2.2.4.1 Định nghĩa PSI
Khái niệm của định danh dịch vụ công cộng (PSI – Public Service
Identities) được giới thiệu trong 3GPP Release 6. Không giống như định
danh người dùng công cộng, một PSI là một định danh được cấp phát cho
dịch vụ trên máy chủ ứng dụng (AS – Application Server). Ví dụ, một máy
chủ ứng dụng phục vụ một chatroom được định danh bởi PSI. Giống như
định danh người dùng công cộng, PSI có thể có dạng SIP URI hoặc TEL
URI.
34
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Không giống định danh người dùng công cộng, PSI không liên quan đến
định danh người dùng riêng. Sở dĩ như vậy là do định danh người dùng
riêng chỉ sử dụng dành cho mục đích nhận thực. PSI không được áp dụng
cho người dùng.
2.2.4.2 Phân loại PSI
PSI được chứa trong HSS dưới dạng hoặc là PSI đặc trưng hoặc là
Wildcarded PSI. Một PSI đặc trưng (Distinct PSI) có chứa PSI được sử
dụng trong quá trình định tuyến. Trong khi Wildcarded PSI là một tập hợp
các PSI. Wildcarded PSI cho phép người dùng tối ưu hoạt động và duy trì
các nút. Một Wildcarded PSI có chứa hơn hai dấu chấm than sẽ được xem
như một cặp dấu ngăn cách.
Khi được chứa trong HSS, Wildcarded PSI sẽ bao gồm các ký tự ngăn cách
để xác định phần mở rộng của PSI.
Ví dụ: PSI sau có thể chứa trong HSS “sip:chatlist!.*[email protected]”.
Ví dụ các PSI sau giao tiếp trên giao diện bản tin với HSS sẽ được đổi
thành “sip:chatlist!.*[email protected]”. Khi chứa trong HSS:
2.3 SIM, USIM và ISIM trong 3GPPUICC (Universal Integrated Circuit Card) là trung tâm trong thiết kế thiết bị
đầu cuối 3GPP. UICC là một thẻ thông minh có thể tháo lắp và mang theo
người một cách rất đơn giản, UICC lưu trữ một số dữ liệu như thông tin đăng
35
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
ký thuê bao, mã nhận thực, sổ địa chỉ và các tin nhắn. Nếu không có UICC thì
thiết bị đầu cuối chỉ có thể gọi các số khẩn cấp.
UICC cho phép người dùng di chuyển dễ dàng thông tin thuê bao của họ sang
thiết bị mới bằng cách lắp thẻ thông minh sang thiết bị đó. UICC là một khái
niệm chung định nghĩa các đặc tính của thẻ thông minh.
UICC có thể bao gồm một vài ứng dụng logic như SIM (Subscriber Identity
Module), USIM (Universal Subscriber Identity Module) và ISIM (IP
multimedia Services Identity Module). Thêm vào đó, UICC còn có thể chứa
các ứng dụng khác như danh bạ điện thoại.
2.3.1 SIM
SIM lưu trữ một tập hợp các tham số như thông tin đăng ký người dùng, mã
nhận thực và các tin nhắn. SIM là thành phần cơ bản nhất trong các thiết bị
đầu cuối để người dùng có thể hòa mạng. Mặc dù khái niệm UICC và SIM là
có thể thay đổi cho nhau, UICC được xem như một thẻ vật lý, trong khi đó
SIM được xem như một ứng dụng đơn lẻ nằm trong UICC. SIM được sử
dụng rộng rãi trong các mạng di động thế hệ thứ hai, như mạng GSM.
2.3.2 USIM
USIM là một ứng dụng khác nằm trong UICC. USIM cung cấp một tập hợp
các tham số bao gồm thông tin đăng ký thuê bao, thông tin nhận thực,
phương pháp thanh toán và lưu trữ tin nhắn. USIM được sử dụng để truy
nhập mạng UMTS.
Các thiết bị đầu cuối trong mạng chuyển mạch gói và chuyển mạch kênh cần
phải có USIM để hoạt động được trong mạng di động thế hệ thứ ba. Rõ ràng,
cả SIM và USIM có thể cùng tồn tại đồng thời trong UICC để thiết bị đầu
cuối có thể sử dụng đồng thời mạng GSM và UMTS.
2.3.3 ISIM
36
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Một ứng dụng thứ ba có thể hiện diện trong UICC là ISIM. ISIM có vai trò
đặc biệt quan trọng trong IMS, bởi vì ISIM có chứa một tập hợp các thông số
được sử dụng làm chứng thực người dùng, nhận dạng người dùng, cấu hình
thiết bị đầu cuối hoạt động trong mạng IMS. ISIM có thể tồn tại cùng SIM,
USIM hoặc tất cả các ứng dụng trong cùng UICC.
2.4 Tiêu chuẩn lọcTiêu chuẩn lọc là một trong những thành phần quan trọng nhất của thông tin
người dùng được lưu trữ trên mạng vì chúng xác định loại dịch vụ nào sẽ cung
cấp cho người sử dụng. Tiêu chuẩn lọc bao gồm một tập hợp thông tin liên
quan đến người dùng giúp cho S-CSCF quyết định khi nào gọi máy chủ ứng
dụng cung cấp dịch vụ.
Theo tiêu chuẩn 3GPP TS 23.218 [20] có hai tiêu chuẩn lọc là: tiêu chuẩn lọc
khởi tạo (IFC – Initial Filter Criteria) và tiêu chuẩn lọc kế tiếp (SFC –
Subsequent Filter Criteria). Tuy nhiên chỉ có tiêu chuẩn lọc khởi tạo IFC là
được sử dụng. Tiêu chuẩn lọc kế tiếp SFC vẫn còn nằm trên lý thuyết, do nếu
áp dụng tiêu chuẩn lọc kế tiếp SFC tại S-CSCF có thể sẽ gây ra xung đột với
quy tắc định tuyến bản tin SIP cho các proxy.
Tiêu chuẩn lọc khởi tạo IFC có nhiệm vụ đánh giá các yêu cầu khởi tạo SIP và
tạo ra các yêu cầu đơn. Ví dụ, S-CSCF đánh giá tiêu chuẩn lọc khởi tạo khi
nhạn được yêu cầu SUBSCRIBE đầu tiên, INVITE, OPTIONS, hoặc bất cứ
yêu cầu nào tạo ra cuộc hội thoại hoặc được gửi ngoài các hộp thoại. S-CSCF
không đánh giá tiêu chuẩn lọc khởi tạo khi nhận được yêu cầu PRACK,
NOTIFY, UPDATE, hoặc BYE do chúng luôn luôn được gửi như một phần
của một hội thoại SIP đang tồn tại.
Khái niệm tiêu chuẩn lọc kế tiếp là S-CSCF sẽ đánh giá tiêu chuẩn lọc kế tiếp
khi nó nhận được yêu cầu kế tiếp trong hộp thoại SIP. Tuy nhiên, kết quả của
việc đánh giá tiêu chuẩn lọc kế tiếp có thể dẫn đến việc S-CSCF chuyển tiếp
37
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
yêu cầu SIP kế tiếp đến một máy chủ ứng dụng, điều này trái ngược với thủ
tục định tuyến cho yêu cầu kế tiếp ở trong một SIP proxy. Hơn nữa, trong sự
kiện một máy chủ ứng dụng nhận được yêu cầu kế tiếp này, khi đó máy chủ
ứng dụng vẫn chưa nhận được yêu cầu khởi tạo SIP để tạo hộp thoại SIP. Do
đó, máy chủ ứng dụng sẽ hủy yêu cầu và bỏ qua yêu cầu kế tiếp đó. Từ đó dẫn
đến việc không sử dụng tiêu chuẩn lọc kế tiếp.
Tiêu chuẩn lọc duy nhất được triển khai là tiêu chuẩn lọc khởi tạo. Do tiêu
chuẩn lọc kế tiếp không tồn tại nên thuật ngữ tiêu chuẩn lọc khởi tạo và tiêu
chuẩn lọc là như nhau.
HSS lưu giữ tất cả dữ liệu liên quan tới người dùng trong một cấu trúc dữ liệu
tên là User Profile. Hình 2-7 mô tả cấu trúc đơn giản cấp cao của user profile.
User Profile chứa định danh riêng thuê bao mà user profile đó thuộc về và một
hay nhiều service profile. Mỗi một service profile chứa một hay nhiều định
danh công cộng thuê bao mà service profile đó thuộc về và không có hoặc
nhiều tiêu chuẩn lọc.
38
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 2-7 : Cấu trúc của User Profile
Khi người dùng đăng ký với S-CSCF, S-CSCF liên lạc với HSS và tải user
profile có chứa tiêu chuẩn lọc. Vậy tiêu chuẩn lọc vẫn tồn tại trong S-SCSF tại
thời điểm người dùng đăng ký.
39
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Tiêu chuẩn lọc xác định các dịch vụ mà nó có thể áp dụng được để thu thập
định danh công cộng thuê bao liệt kê trong “Service profile”. Cấu trúc dữ liệu
của tiêu chuẩn lọc được thể hiện ở hình 2-8.
Hình 2-8 : Cấu trúc tiêu chuẩn lọc khởi tạo
40
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Trường đầu tiên trong cấu trúc tiêu chuẩn lọc là Priority. Trường Priority xác
định thứ tự của tiêu chuẩn lọc sẽ được đánh giá so với các tiêu chuẩn lọc còn
lại trong cùng một “service profile”. S-SCSF trước tiên sẽ chọn tiêu chuẩn lọc
có độ ưu tiên cao, ví dụ độ ưu tiên 1 là độ ưu tiên cao nhất. Sau khi thực thi
nó, S-SCSF tiếp tục với tiêu chuẩn lọc tiếp theo có độ ưu tiên nhỏ hơn.
Trường Priority của tiêu chuẩn lọc là số duy nhất đối với các tiêu chuẩn lọc
trong cùng một “service profile”. Trong một số trường hợp, số ưu tiên không
cần thiết phải liền nhau.
Sau trường Priority, có thể không có hoặc có một Trigger Point (điểm kích
hoạt). Một Trigger Point là một biểu thức cần được đánh giá để xác định xem
yêu cầu SIP có được chuyển tiếp đến máy chủ ứng dụng hay không. Một điểm
kích hoạt là tập hợp các bộ lọc riêng biệt được gọi là “Service Point Triggers”.
Ví dụ, một Trigger Point có thể như sau:
(Method = INVITE) AND (Request-URI = sip:[email protected])
Trong ví dụ này có hai Service Point Trigger là Method = INVITE và
Request-URI = sip:[email protected].
Sevice Point Trigger cho phép ta truy nhập thông tin được lưu trữ chứa trong
các trường khác nhau của yêu cầu SIP.
• Giá trị của Request-URI.
• Phương thức của yêu cầu SIP (ví dụ: INVITE, OPTIONS,
SUBSCRIBE,…).
• Sự có mặt hay vắng mặt của bất cứ trường điều khiển SIP (SIP header)
nào.
• Trùng một phần hay toàn bộ nội dung của bất kỳ trường điều khiển SIP
nào.
41
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Trường hợp phiên (ví dụ, yêu cầu SIP có nguồn là một thuê bao được
phục vụ gửi đến thuê bao đã đăng ký, hoặc gửi đến thuê bao chưa đăng
ký).
• Mô tả phiên (ví dụ, trùng một phần hay toàn bộ bất kể một dòng SDP
nào).
Nếu không có Trigger Point thì các yêu cầu SIP được chuyển tiếp đến máy
chủ ứng dụng vô điều kiện.
Sau Trigger Points chứa một hay nhiều Service Point Triggers, tiêu chuẩn lọc
khởi tạo chứa AS SIP URI. Đây là địa chỉ của máy chủ ứng dụng sẽ nhận yêu
cầu SIP nếu các điều kiện được mô tả trong các Trigger Point được thỏa mãn.
Trường Default Handling chỉ hành động sẽ xảy ra nếu S-CSCF với lý do nào
đó không thể liên lạc được với máy chủ ứng dụng. Các hành động có thể tiếp
tục xử lý yêu cầu SIP hoặc ngừng xử lý.
Trường Service Information chứa dữ liệu trong suốt (ví dụ, trong suốt với HSS
và S-CSCF) mà máy chủ ứng dụng có thể cần để xử lý yêu cầu. Cách sử dụng
trường này được giới hạn với các yêu cầu SIP REGISTER hoặc bất kỳ yêu cầu
nào khác khi mà S-CSCF hoạt động như là một SIP User Agent Client.
Nguyên nhân là do các dữ liệu được thêm vào phần thân của yêu cầu SIP.
Hành động này không được chấp nhận trong các SIP Proxy. Vì vậy, trường
hợp duy nhất sử dụng thông tin này là khi S-CSCF, tùy theo tiêu chuẩn lọc
khởi tạo, hoạt động như một “SIP User Agent Client” tạo ra yêu cầu SIP
REGISTER ở bên thứ ba tới máy chủ ứng dụng. Yêu cầu REGISTER đó có
thể chứa Service Information (trong trường hợp máy chủ ứng dụng cần nó),
với mục đích là truyền IMSI tới IM-SSF của thuê bao, vì IMSI có thể được sử
dụng bởi IM-SSF.
Cuối cùng, user profile được mã hóa sử dụng ngôn ngữ đánh dấu mở rộng
XML (Extensible Markup Language). Mẫu XML định nghĩa tiêu chuẩn lọc
42
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
khởi tạo được mô tả trong 3GPP TS 29.228 [21]. Tiêu chuẩn lọc khởi tạo được
truyền từ HSS đến S-SCSF thông qua bản tin Diameter.
2.5 Triển khai kiến trúc IMSKiến trúc IMS được triển khai trong đề tài:
Hình 2-9 : Sơ đồ các khối chức năng trong kiến trúc IMS
Bao gồm các khối chức năng:
• Máy chủ ứng dụng:
o Cung cấp giao diện web cho người dùng thực hiện các dịch vụ
trên nền IMS.
o Giao tiếp với các module AD/DB để xác thực dịch vụ.
43
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
o Phát triển các dịch vụ Iptv, conferencing, presence,… dựa trên
SIP Servlet.
• Media server:
o Thực hiện các chức năng xử lý dữ liệu đa phương tiện (MSF và
MRF tương ứng trong kiến trúc IMS).
o IS-ME sẽ thực hiện những công việc sau:
Playing các file thông báo (audio/video).
Hội thoại đa phương tiện.
Chuyển mã (transcoding) các loại dữ liệu đa phương tiện.
Tương lai sẽ thực hiện Text to Speak.
Thực hiện các dịch vụ điều khiển cuộc gọi (từ IS-CC).
• User client:
o Cung cấp một phương tiện liên lạc đa phương tiện bằng giao
thức SIP trên nền IP.
o Hỗ trợ kiểu dữ liệu đa phương tiện.
o Chạy trên PC, tương lai là trên điện thoại di động và các thiết bị
cầm tay (sử dụng hệ điều hành linux hoặc symbian).
o Cung cấp các dịch vụ chính: gọi điện, xem video (dạng
streaming),…
o Instant messaging,…
• AD/DB:
44
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
o Thực hiện các tác vụ quản lý các thành phần của hệ thống và
quan trọng hơn là thực hiện các chức năng tính cước và xác thực
dịch vụ.
o Thông tin về người dùng được chứa trong cơ sở dữ liệu mySQL
giúp xác thực dịch vụ và xác thực người dùng.
o Giao tiếp với module AS cung cấp các thông tin xử lý dịch vụ.
45
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
3 CHƯƠNG III : CÁC GIAO THỨC QUAN
TRỌNG
Trong chương này, chúng ta sẽ đề cập đến 3 giao thức quan trọng sử dụng
chủ yếu trong đồ án, đó là giao thức mô tả phiên – SDP, giao thức khởi tạo
phiên – SIP và giao thức nhận thực cấp quyền tính toán – Diameter.
3.1 Giao thức SDP
3.1.1 Mô tả phiên
Một mô tả phiên là một mô tả bao gồm những thông tin cần thiết cho các
người dùng ở xa có thể tham gia vào phiên đó. Trong các phiên đa phương
tiện trên internet, những thông tin này bao gồm địa chỉ IP và tên cổng để gửi
đi và các bộ mã hóa – giải mã dùng để mã hóa voice và hình ảnh cần gửi của
người tham gia. Những mô tả về phiên có những định dạng riêng. Định dạng
hay dùng nhất là giao thức mô tả phiên SDP (Session Description Protocol),
được định nghĩa trong RFC 2327 [115]. SDP đơn giản là một định dạng văn
bản miêu tả các phiên multimedia. Hình 3-1 là một ví dụ minh họa mô tả
phiên giữa Alice và Bob. SDP chứa thông tin về địa chỉ IP, số cổng mà Alice
muốn nhận audio (20000) và nhận video (20002), các bộ mã hóa giải mã
audio và video mà Alice hỗ trợ (0 tương ứng với luật mã hóa audio μ G.711
và 31 tương ứng với bộ mã hóa H.261) và thông tin về chủ đề của cuộc hội
thoại.
46
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-10 : Một ví dụ về mô tả phiên SDP
Như ta đã thấy ở hình trên, một mô tả SDP bao gồm hai phần thông tin về
phiên và thông tin về media. Thông tin về phiên trải toàn bộ phiên và xuất
hiện trước dòng “m=”. Năm dòng đầu tiên tương ứng với thông tin về phiên.
Chúng cung cấp những thông tin về nhận dạng người dùng (v= và o=), chủ
đề của phiên (s=), địa chỉ của Alice (c=) và thời gian của phiên (t=).
Thông tin về media là luồng media cụ thể bao gồm dòng “m=” và một số lựa
chọn “a=” cung cấp thông tin về luồng media. Trong ví dụ hình 3-1 có hai
dòng media và vì vậy có hai dòng “m=”. Dòng “a=” chỉ ra luồng media ở
đây là hai chiều (các user gửi và nhận media).
Như minh họa trên hình 3-1, định dạng của tất cả các dòng SDP bao gồm
dạng “kiểu = giá trị”, “kiểu” là một chữ cái. Hình 3-2 chỉ ra các “kiểu” trong
SDP. Mặc dù SDP là một định dạng phổ biến miêu tả các phiên đa phương
tiện nhưng SIP không phụ thuộc vào SDP. SIP là một dạng độc lập với việc
mô tả phiên tức là SIP có thể đưa ra một mô tả phiên dùng SDP hay là bất kỳ
một dạng khác.
47
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-11 : Các kiểu trong SDP
3.1.2 Mô hình Offer/Answer
Trong ví dụ về SDP ở hình 3-1, Alice gửi một mô tả phiên đến Bob có chứa
địa chỉ của Alice (bao gồm địa chỉ IP và số hiệu cổng). Tất nhiên như thế là
chưa đủ để thiết lập một phiên giữa hai người. Alice cũng cần phải biết địa
chỉ tương ứng của Bob. SIP cung cấp phương thức trao đổi mô tả phiên giữa
hai người gọi là mô hình offer/answer (được mô tả trong RFC 3264 [212]).
Một trong hai người dùng (offerer) tạo ra một mô tả phiên (offer) và gửi nó
tới một người dùng khác (answerer) tạo ra một mô tả phiên mới (answer) để
gửi tới offerer. RFC 3264 [212] đưa ra những quy định về phương cách tạo
ra offer và anser. Sau khi trao đổi offer/answer cả hai người sẽ có những
thông tin về phiên được thiết lập. Họ sẽ biết định dạng cần sử dụng và địa chỉ
để truyền tải cho phiên đó. Trao đổi offer/answer cũng có thể cung cấp
những thông tin khác như mã và giải mã…
48
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-3 minh họa việc Bob gửi lại cho Alice sau khi nhận được một offer
của Alice.
Hình 3-12 : Mô tả phiên SDP của Bob
Địa chỉ của Bob là 192.0.0.2, số cổng nơi Bob nhận audio là 30000, số cổng
nơi Bob nhận video là 30002 và Bob cũng dùng bộ mã hóa – giải mã giống
Alice (G.711 μ-law và H.261). Sau khi trao đổi offer/answer cả hai có thể
trao đổi về audio và video cho nhau.
3.1.3 SIP và SIPS URIs
SIP nhận dạng người dùng bằng SIP URI tương tự như địa chỉ của một
email, SIP URI bao gồm tên và một tên miền. Thêm vào đó, SIP URI có thể
chứa một số các thông số được phân cách bởi các dấu chấm phẩy.
Ví dụ về SIP URIs:
sip:[email protected];transport=tcp
Thêm vào đó, người dùng có thể được nhận ra bằng SIP URI. Các thực thể
giao tiếp với SIPS RIs dùng TLS (Transport Layer Security) để bảo mật các
bản tin của người dùng.
Ví dụ về SIPS URIs:
49
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
sips:[email protected]
sips:[email protected]
3.1.4 Định vị người dùng
Mục đính chính của SIP là đưa ra một mô tả phiên tới người dùng ở vị trí
hiện tại của họ, và chúng ta đã thấy định dạng của một mô tả phiên. Bây giờ
chúng ta xem xét SIP nhận ra vị trí của người dùng như thế nào.
SIP cung cấp tính linh động cá nhân tức là một người dùng sẽ có nhận dạng
như nhau bất kể người đó đang ở đâu. Ví dụ, Alice được nhận dạng bởi SIP
URI tại
bất kể Alice đang ở đâu, đây là URI công cộng của Alice hay còn được gọi là
AoR (Address of Record).
Tuy nhiên, khi Alice đăng nhập tại nơi làm việc, địa chỉ SIP URI của cô ấy là
và khi Alice làm việc tại trường đại học thì địa chỉ SIP URI là
Bởi vậy, chúng ta cần phải có phương pháp ánh xạ tới địa chỉ công cộng của
Alice
tới các địa chỉ URI hiện thời của cô ấy (tại nơi làm việc hoặc tại trường đại
học).
Để làm được điều này, SIP đưa ra một thành phần mạng gọi là registrar của
một domain. Registrar quản lý các yêu cầu được gửi tới một domain. Vì vậy
yêu cầu gửi tới sip:[email protected] sẽ được quản lý bởi SIP
registrar tại domain.com.50
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Bất cứ lúc nào Alice đăng nhập tại một khu vực mới, Alice sẽ đăng ký vị trí
mới đó tại domain.com như được chỉ ra trên hình 3-4.
Hình 3-13 : Alice đăng ký vị trí người dùng với tên miền domain.com registrar
Khi tiếp nhận đăng ký registrar tại domain.com sẽ lưu trữ cơ chế ánh xạ giữa
URI công cộng của Alice và vị trí hiện tại của cô ấy theo hai cách: nó có thể
dùng cơ sở dữ liệu hoặc có thể tải lên cơ chế ánh xạ này tới máy chủ vị trí.
Nếu registrar dùng máy chủ vị trí thì nó cần tra cứu khi nó nhận được yêu
cầu của Alice. Chú ý rằng giao diện giữa registrar và máy chủ vị trí không
dùng SIP mà dùng các giao thức khác.
3.2 Giao thức DiameterDiameter là 1 giao thức dùng cho mục đích xác thực người dùng, cấp quyền
và tính toán (AAA). Diameter là giao thức tiếp sau của RADIUS
Giao thức Diameter cơ bản được định nghĩa trong RFC 3588, định nghĩa
những yêu cầu tối thiểu dùng cho mục đích AAA. Các ứng dụng Diameter có
thể mở rộng giao thức diameter cơ bản bằng cách thêm vào nhiều thuộc tính
cũng như các lệnh. Diameter được truyền bảo mật bằng ipsec hoặc tls, tổ
chức IANA gán cho Diameter/TCP hay SCTP cổng 3868.
51
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
3.2.1 Gói tin Diameter
Cấu trúc:
HÌnh 3-14: Cấu trúc gói tin Diameter
Các command được quan tâm trong đề tài:
Bảng 3-1: Diameter commands
Command-Name Abbr. Code Capabilities-Exchange-Request CER 257Capabilities-Exchange-Answer CEA 257Device-Watchdog-Request DWR 280Device-Watchdog-Answer DWA 280Disconnect-Peer-Request DPR 282Disconnect-Peer-Answer DPA 282User-Data-Request UDR 306User-Data-Answer UDA 306Profile-Update-Request PUR 307Profile-Update-Answer PUA 307
Attribute-Value Pairs (AVPs)
52
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 3-15: Cấu trúc AVP trong gói tin Diameter
Bit ‘V’ chỉ định sự có mặt của trường Vendor-ID trong AVP header. Bit ‘M’ chỉ định AVP này là bắt buộc phải có.Bit ‘P’ chỉ ra AVP này có được mã hóa đảm bảo cho bảo mật thông tin giữa các đầu cuối hay ko.
Các AVP được quan tâm đến trong đề tài:
Bảng 3-2: Diameter AVPs
Attribute-Name Code Data TypeDestination-Host 293 DiamIdentDestination-Realm 283 DiamIdentExperimental-Result 297 GroupedExperimental-Result-Code 298 Unsigned32Host-IP-Address 257 AddressOrigin-Host 264 DiamIdentOrigin-Realm 296 DiamIdentHost-IP-Address 257 AddressUser-Name 1 UTF8StringVendor-Id 266 Unsigned32Vendor-Specific-Application-Id 260 GroupedSupported-Vendor-Id 265 Unsigned32
3.2.2 Phiên giao dịchLuồng bản tin:
53
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 3-16: Diameter transaction
Giao tiếp giữa 2 đầu cuối diameter bắt đầu bằng bản tin capabilities-
Exchange-Request (CER) từ 1 peer này sang 1 peer khác, bản tin này được
trả lời bằng 1 bản tin diameter Capabilities-Exchange-Answer (CEA). Mục
đích của 2 bản tin này là để 2 diameter peer biết được các thông số của nhau
thuận tiện cho việc trao đổi thông tin 2 chiều.
Sau khi nhận được CEA, 2 diameter peer đã có thể giao tiếp với nhau.
Nếu không có bản tin nào được chuyển qua lại giữa 2 peer thì chúng sẽ gửi
các bản tin Device-Watchdog-Request (DWR) và peer kia trả lời bằng 1 bản
tin Device-Watchdog-Answer (DWA) để 2 peer biết được sự tồn tại của
nhau.
54
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
1 trong 2 peer có thể kết thúc phiên giao tiếp bởi bản tin Disconnect-Peer-
Request (DPR) và được trả lại bằng 1 bản tin Disconnect-Peer-Answer
(DPA). Sau thủ tục này 2 peers coi như chấm dứt giao dịch và sẽ bắt đầu lại
(nếu cần) bằng bản tin CER
3.2.3 Triển khai giao thức trong đề tài
Application server cung cấp logic dịch vụ sử dụng thư viện JDiameter để xử
lý các bản tin Diameter. Trong đề tài sử dụng 1 implementation của giao
thức Diameter (1 ứng dụng diameter) trên giao diện Sh giữa AS và HSS.
Dịch vụ IPTV – Parental control sử dụng 3 thông tin của user có trong cơ sở
dữ liệu của HSS:
• Thông tin về trạng thái người dùng (Registered, un-registered, not-
registered, authentication pending) – dùng trong trường hợp cần gửi tin
nhắn cho reference user, phải xác định được user đó có đang online hay
không.
• Thông tin về dịch vụ mà 1 user đã đăng ký – để biết được user có đăng
ký dịch vụ IPTv hay không hoặc đăng ký IPTv hay là Parental Control
• Thông tin thêm chi tiết về dịch vụ đó, các ràng buộc, yêu cầu của dịch vụ
- ví dụ như khoảng thời gian 1 user được phép xem 1 phân loại kênh nhất
định.
Các thông tin này được AS download về từ HSS thông qua giao diện Sh
bằng cách gửi bản tin User-Data-Request (UDR) và nhận về bản tin User-
Data-Answer (UDA)với các AVPs: User-Identity, Data-Refenrence, User-
Data, Vendor-Specific-Application-Id, Supported-Vendor-Id.
Để có thể thiết lập logic dịch vụ cho 1 user, AS sử dụng bản tin Profile-
Update-Request (PUR) để update repository data của user trên HSS vd như
55
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
đối với dịch vụ Parental Control thì là thông tin về reference user, về giới
hạn thời gian và loại kênh được phép truy cập.
Bản tin thứ nhất được đề cập đến là bản tin UDR – User Data
Request: hay còn gọi là Sh Pull, là bản tin do Application server gửi
đến HSS để truy vấn thông tin người dùng. Trong bản tin này có các
AVP:
o USER_IDENTITY code = 700 bao gồm
o PUBLIC_IDENTITY code = 601 value = “sip:[email protected]”
o SERVER_NAME code = 602 value =
“sip:IPTV_SERVER_IP:PORT”
o DATA_REFERENCE code = 703 value = 13 IFC hoặc value = 0
REPOSITORY_DATA hoặc value = 11 IMS_USER_STATE
o SERVICE_INDICATION code = 704 value = “iptv” nếu data
reference là repository data.
Bản tin UDR đầu tiên được gửi truy vấn iFC của người dùng, sẽ lấy được các
thông tin cơ bản của người dùng trong mạng IMS.
Bản tin UDR thứ 2 được gửi truy vấn Repository data của người dùng, đây là
dữ liệu lưu trên HSS cho từng dịch vụ riêng biệt, là dữ liệu của máy chủ ứng
dụng áp dụng cho từng người dùng trong mạng IMS.
Ví dụ về 1 IFC của người dùng:
56
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 3-17: IFC của người dùng tải về từ HSS
Ví dụ về Repository data của người dùng:
57
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 3-18: Repository data của 1 người dùng IPTV
Bản tin thứ 2 được đề cập đến là bản tin PUR: Profile Update
Request: hay còn gọi là Sh – push, là bản tin do Application server
gửi đến HSS nhằm cập nhật thông tin người dùng lưu giữ trong HSS.
Trong đề tài sử dụng bản tin PUR để cập nhật Repository data của
dịch vụ IPTV cho từng user. Trong bản tin này có các AVP:
o USER_IDENTITY, PUBLIC_IDENTITY,
DATA_REFERENCE như trên
58
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
o USER_DATA code = 702.
3.3 Giao thức SIPSIP là một giao thức báo hiệu thường được sử dụng để thiết lập, chỉnh sửa,
và kết thúc một phiên giữa hai điểm đầu cuối. SIP có thể được sử dụng để
thiết lập một cuộc gọi giữa hai bên, một cuộc gọi nhiều bên, hoặc một phiên
multicast cho các cuộc gọi Internet, các cuộc gọi đa phương tiện và phân
phối đa phương tiện.
Một cách đơn giản để mô tả SIP là xem xét một mô hình sử dụng. Giả sử một
người dùng có định danh là A muốn thiết lập cuộc gọi với người dùng có
định danh là B. Trong viễn thông, người dùng A và người dùng B có thể giao
tiếp thông qua một thiết bị được gọi là tác nhân người dùng (User Agent).
Một ví dụ về User Agent là một soft phone, một chương trình phần mềm sử
dụng để thiết lập cuộc gọi điện thoại qua Internet. Một ví dụ khác là VoIP
Phone, một loại điện thoại cho phép sử dụng VoIP (Voice over IP). Dưới đây
là các bước cần thiết để thiết lập một cuộc gọi:
• A mời B bắt đầu cuộc hội thoại. Như một phần của lời mời, A sẽ chỉ
ra loại media nào sẽ được hỗ trợ.
• B nhận lời mời, gửi đáp ứng trung gian tới người dùng A, và sau đó
đánh giá lời mời.
• Khi B sẵn sàng chấp nhận lời mời, nó gửi một xác nhận lại cho người
dùng A. Như một phần của xác nhận, B cũng chỉ ra loại media mà nó
hỗ trợ.
• A kiểm tra xác nhận mà nó nhận được từ B và quyết định xem liệu
media hỗ trợ bởi A và B có giống nhau không. Nếu A và B hỗ trợ
cùng một loại media, cuộc gọi sẽ được thiết lập giữa A và B.
59
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-19 : Các bước thiết lập một cuộc gọi
SIP cung cấp một phương thức chuẩn để thực hiện các bước này. Nó thực
hiện việc này bằng cách định nghĩa ra các phương thức yêu cầu (request),
đáp ứng (response), mã đáp ứng (response code) và các trường điều khiển
đặc trưng cho báo hiệu và điều khiển cuộc gọi. Giao thức này được chuẩn
hóa bởi IETF (Internet Engineering Task Force) theo RFC 3261 và hiện nay
nó được chấp nhận rộng rãi như một chuẩn báo hiệu cho 3GPP (3rd
Generation Partnership Project) và như là một thành phần không thể thiếu
trong kiến trúc IMS.
3.3.1 SIP liên hệ với HTTP như thế nào
Như đã nói ở trên, SIP kế thừa các đặc tính quan trọng của HTTP. Nó chia sẻ
nhiều đặc điểm quan trọng với HTTP và cũng chính vì vậy nhiều người
thường thắc mắc liệu SIP có sử dụng HTTP như một giao thức nền? Câu trả
lời là không. SIP là một giao thức hoạt động ở cùng một tầng với HTTP, điều
đó có nghĩa là nó hoạt động ở tầng ứng dụng và sử dụng các giao thức TCP,
60
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
UDP, SCTP như là các giao thức nền của lớp dưới. Tuy nhiên SIP có rất
nhiều điểm giống với HTTP. Ví dụ, tương tự như HTTP, SIP cũng là một
giao thức dựa trên văn bản (text-based) và người dùng có khả năng đọc được.
Cũng giống như HTTP, SIP sử dụng cơ chế yêu cầu – đáp ứng (request –
response mechanism) với các phương thức đặc trưng, mã đáp ứng và các
trường điều khiển. Tuy nhiên, một điểm khác biệt quan trọng giữa HTTP và
SIP là cơ chế yêu cầu – đáp ứng trong SIP là không đồng bộ -- một yêu cầu
không nhất thiết theo sau nó là một đáp ứng tương ứng. Thực tế, yêu cầu SIP
thường có thể gây ra một vài yêu cầu khác được tạo ra.
SIP là một giao thức ngang hàng (peer-to-peer protocol). Điều này có nghĩa
là người dùng cuối (User Agent) có thể hoạt động như một Server cũng như
có thể hoạt động như một Client. Đây là một điểm khác biệt giữa SIP và
HTTP. Trong HTTP, máy client thì sẽ luôn luôn là máy client, máy chủ sẽ
luôn luôn là máy chủ.
SIP hỗ trợ các phương thức yêu cầu và mã đáp ứng sau:
• REGISTER: sử dụng bởi client để đăng ký địa chỉ với máy chủ ứng
dụng.
• INVITE: chỉ ra rằng người dùng hay dịch vụ đang được mời tham gia
vào một phiên. Phần thân của bản tin này bao gồm một mô tả phiên
mà người dùng dịch vụ đang được mời.
• ACK: xác nhận rằng client nhận được đáp ứng cuối cùng của một bản
tin invite. Phương thức này chỉ được sử dụng với yêu cầu invite.
• CANCEL: sử dụng để bỏ qua một yêu cầu đang chờ xử lý.
• BYE: gửi một user client agent để chỉ định với máy chủ là nó muốn
kết thuc cuộc gọi.
• OPTIONS: sử dụng để truy vấn máy chủ về khả năng của nó.
61
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Mã hồi đáp:
• 1xx: thăm dò. Một ACK chỉ định một hành động đã được nhận thành
công, được hiểu và được chấp nhận.
• 3xx: chuyển hướng. Yêu cầu thêm các hành động khác để xử lý yêu
cầu.
• 4xx: lỗi client. Yêu cầu có chứa cú pháp sai và không thể hoàn thành
ở máy chủ.
• 5xx: lỗi máy chủ. Máy chủ thất bại trong việc hoàn thành một yêu cầu
hợp lệ.
• 6xx: lỗi toàn cục. Yêu cầu không thể hoàn thành ở bất cứ máy chủ
nào.
Giao thức mô tả phiên (SDP) là một định dạng cho việc mô tả định dạng
media và loại media được dùng trong một phiên. SIP sử dụng SDP như là
một phần tải trong bản tin của nó để thực hiện chức năng trao đổi khả năng
giữa các người dùng. Ví dụ, nội dung của SDP có thể chỉ ra loại mã hóa hỗ
trợ bởi user agent và giao thức sử dụng trao đổi thời gian thực (RTP).
3.3.2 Bản tin SIP
Cấu trúc của bản tin SIP:
62
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-20 : Cấu trúc bản tin SIP
Hình trên chỉ ra cấu trúc thành phần của một bản tin SIP. Có 3 thành phần
quan trọng:
• Dòng yêu cầu: chỉ ra phương thức yêu cầu, địa chỉ và phiên bản SIP.
• Trường điều khiển: chỉ ra dữ liệu về phiên hay cuộc gọi được thiết lập
hay kết thúc.
• Phần thân bản tin: cung cấp payload, SDP mô tả media của phiên.
3.3.3 Phiên giao dịch (Transaction)
Mặc dù nói các bản tin SIP được gửi đi một cách độc lập qua mạng nhưng
thực tế chúng thường được sắp xếp vào các transaction (giao dịch) bởi các
user agent và một số kiểu proxy server nào đó. Do đó có thể nói giao thức
SIP là một giao thức hỗ trợ transaction.
63
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Một transaction là một luồng các bản tin SIP được truyền đi một cách tuần tự
giữa các phần tử mạng. Một transaction là một luồng bản tin SIP được truyền
đi một cách tuần tự giữa các phần tử mạng. Một transaction chứa thông tin
yêu cầu và tất cả các thông tin phản hồi cho thông tin yêu cầu đó hoặc thậm
chí nhiều hơn các thông tin phản hồi cuối (final response).
Nếu một transaction được khởi tạo bởi bản tin yêu cầu INVITE thì
transaction đó cũng bao gồm cả bản tin ACK nếu như phản hồi cuối không
phải là kiểu 2xx. Nếu như phản hồi cuối là kiểu 2xx thì bản tin ACK sẽ
không được xem là một thành phần trong transaction.
Nếu như vậy chúng ta có thể thấy rằng ở đây có sự cư sử không được công
bằng – ACK được coi là một thành phần trong transaction với một lời từ chối
ở phản hồi cuối, trong khi nó lại không phải là một thành phần transaction
khi được chấp nhận ở phản hồi cuối. Lý do cho sự phân biệt này là sự quan
trọng của tất cả các bản tin 200 OK. Không những nó thiết lập một phiên mà
bản tin 200 OK còn được sinh ra bởi các thực thể khi một proxy server
chuyển hướng yêu cầu và tất cả các proxy server đó phải chuyển bản tin 200
OK về đến user agent. Do đó, trong trường hợp này user agent phải lãnh
trách nhiệm và truyền lại bản tin 200 OK cho đến khi chúng nhận được bản
tin ACK. Một lưu ý khác nữa là chỉ có bản tin INVITE là được truyền lại.
Các thực thể SIP có khái niệm về transaction được gọi là stateful. Các thực
thể này tạo một trạng thái kết nối với một transaction được lưu trong bộ nhớ
trong suốt khoảng thời gian diễn ra transaction. Khi có thông tin yêu cầu hay
phản hồi đến, một thực thể stateful sẽ cố gắng kết nối yêu cầu (hoặc phản
hồi) đó tới một transaction đã tồn tại sẵn. Để có khả năng làm được điều đó,
nó phải lấy thông tin xác định tính duy nhất của transaction (gọi là identifier)
trong bản tin đó và so sánh với tất cả các identifier trong transaction mà nó
lưu trữ. Nếu như một transaction tồn tại thì trạng thái của nó sẽ được cập
nhật từ bản tin đó.
64
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-21 : Transaction
3.3.4 Hội thoại (dialog)
Ở trên chúng ta đã biết đến transaction, đó là một transaction bao gồm bản
tin INVITE và các bản tin phải hồi, một transaction khác bao gồm bản tin
BYE và thông tin phản hồi (200 OK) khi một phiên làm việc kết thúc.
Nhưng chúng ta có thể thấy rằng cả hai transaction này có liên quan đến
nhau và cùng thuộc một hội thoại (dialog). Một dialog đặc trưng cho mối
quan hệ SIP ngang hàng giữa hai user agent. Một dialog tồn tại trong một
khoảng thời gian và nó là một khái niệm rất quan trọng đối với các user
agent. Dialog thích hợp dễ dàng với việc sắp xếp tuần tự và định tuyến cho
các bản tin SIP giữa các thiết bị cuối.
Dialog được xác định bằng call-id, thẻ from và thẻ to. Các bản tin mà có
cùng 3 identifier trên thì thuộc về cùng một dialog. Trường điều khiển Cseq
được dùng để sắp xếp thứ tự các bản tin trong cùng một dialog. Chỉ số Cseq
phải được tăng tuần tự từng đơn vị cho mỗi bản tin trong một dialog, nếu
65
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
không các user agent sẽ xử lý nó như là các yêu cầu không được sắp xếp
hoặc là sẽ gửi lại bản tin đó. Trong thực tế, số Cseq xác định một transaction
bên trong một dialog bởi chúng ta đã nói ở trên là các yêu cầu và các thông
tin được phản hồi của nó được gọi là một transaction. Điều đó có nghĩa là chỉ
có duy nhất một transaction hoạt động tại một thời điểm trong dialog. Do đó
cũng có thể gọi dialog là một tập tuần tự của các transaction. Hình vẽ dưới
đây minh họa các bản tin truyền đi bên trong một dialog.
Hình 3-22 : Luồng cuộc gọi trong một hội thoại SIP
Một vài bản tin dùng để thiết lập ra một dialog. Nó cho phép biểu diễn rõ
ràng, chi tiết mối quan hệ giữa các bản tin và còn dùng để gửi bản tin mà
không liên quan đến các bản tin khác đến các bản tin nằm ngoài một dialog.
Điều đó được thực hiện một cách dễ dàng bởi user agent không lưu trạng thái
của dialog.
66
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Lấy ví dụ, bản tin INVITE thiết lập một dialog, bởi sau đó sẽ có bản tin yêu
cầu BYE dùng để kết thúc dialog tạo ra bởi bản tin INVITE ở trên. Bản tin
BYE này được gửi bên trong dialog được thiết lập bởi bản tin INVITE.
Nhưng nếu user agent gửi một bản tin yêu cầu message, đó là một yêu cầu
không thiết lập bất cứ dialog nào. Khi đó bất cứ các bản tin theo sau bản tin
đó (kể cả bản tin message) cũng được gửi đi một cách độc lập với bản tin
trước đó.
3.3.5 Trường điều khiển Record-Route, Route và Contact
Hình 3-9 mô tả luồng bản tin nơi proxy tại domain.com giữ nguyên đường
dẫn cho tất cả các yêu cầu gửi tới bên trong dialog. Các yêu cầu proxy để giữ
nguyên đường dẫn bằng cách thêm một trường điều khiển Record-Route vào
yêu cầu INVITE (2). Tham số lr xuất hiện ở phần cuối của URI chỉ ra rằng
proxy này là phù hợp với RFC 3261 (các proxy cũ hơn được sử dụng với một
cơ chế định tuyến khác).
Alice nhận được trường điều khiển Record-Route cùng với URI của proxy
trong bản tin yêu cầu INVITE (2), và Bob nhận được nó trong bản tin hồi
đáp 200 OK (4). Từ thời điểm này, cả Bob và Alice sẽ chèn trường điều
khiển Route vào trong các bản tin yêu cầu của họ, để chỉ ra rằng proxy tại
domain.com cần được đi qua. Bản tin hồi đáp ACK (5) và (6) là một ví dụ về
một yêu cầu với trường điều khiển Route được gửi từ Bob tới Alice. Bản tin
BYE (7) và (8) cho thấy các yêu cầu trong các hướng ngược nhau (ví dụ từ
Alice tới Bob) sử dụng cùng cơ chế Route.
67
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 3-23 : Cách sử dụng Record-Route, Route và Contact
68
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
4 CHƯƠNG IV : MÁY CHỦ ỨNG DỤNG
Máy chủ ứng dụng (Application Server) là một dụng cụ (engine) phần mềm
thực hiện các ứng dụng cho các máy tính hoặc các thiết bị client thông qua
Internet và sử dụng HTTP. Máy chủ trong IMS bên cạnh những đặc điểm
chung như vậy còn có những đặc điểm riêng. Trong chương này, chúng ta sẽ
đi vào tìm hiểu kỹ hơn về khái niệm, vai trò, các chế độ hoạt động cũng như
tương tác của máy chủ ứng dụng IMS với các thành phần khác trong hệ thống.
4.1 Tổng quan về máy chủ ứng dụngTrong một mạng, luôn có nhiều hơn một máy chủ ứng dụng. Điển hình, có
một vài máy chủ chuyên mà mỗi loại chuyên cung cấp một dịch vụ riêng biệt.
Một vài máy chủ ứng dụng sẽ triển khai một vài công nghệ, như công nghệ
Java, SIP serlvets, hoặc SIP CGI (Common Gateway Interface). Tất cả các
loại máy chủ ứng dụng này được miêu tả bằng cách triển khai một giao diện
SIP kết nối tới S-CSCF. Giao diện được định nghĩa giữa S-CSCF và máy chủ
được biết đến là giao diện điều khiển dịch vụ IMS (ISC – IMS Service
Control).
Máy chủ có thể được đặt tại mạng nhà hoặc đặt tại mạng của nhà cung cấp
dịch vụ thứ ba. Nhưng S-CSCF có nhiệm vụ phải quyết định có kết nối với
một máy chủ ứng dụng nào trong cài đặt phiên hay không. Một điểm nữa, bất
kể một máy chủ ứng dụng nào có thể triển khai trên các giao thức khác nhau
như HTTP (Hypertext Transfer Protocol, mô tả ở RFC 2616 [101]) hay WAP
(Wireless Application Protocol [233]), mặc dù lựa chọn này không được mô tả
trong các tiêu chuẩn của IMS.
4.2 Chức năng của máy chủ ứng dụng trong mô hình IMSCần luôn nhớ rằng, máy chủ ứng dụng không phải là các thực thể IMS thuần
túy, mà hơn thế nó hoạt động ở lớp trên cùng trong kiến trúc phân tầng IMS.
69
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 4-24 : Hướng tiếp cận dịch vụ trong kiến trúc IMS
Tuy nhiên, máy chủ ứng dụng được mô tả ở đây như là một phần chức năng
của IMS vì máy chủ ứng dụng là các thực thể cung cấp các dịch vụ đa phương
tiện trong kiến trúc IMS, như Presence và Push to talk trong mạng tế bào.
Chức năng của máy chủ ứng dụng là:
• Khả năng xử lý và tác động đến các phiên SIP nhận được từ IMS.
• Khả năng khởi tạo các yêu cầu SIP.
• Khả năng gửi các thông tin thanh toán để thực hiện các chức năng tính
cước.
Giá trị chính của IMS trong lĩnh vực dịch vụ là sự kết hợp tiềm năng của các
dịch vụ trên Internet với các dịch vụ truyền thông truyền thống và dịch vụ
Multimedia mới. IMS cho phép cung cấp sự truy nhập ở mọi nơi vào tất cả các
dịch vụ này nhưng có sự cung cấp các giá trị mới tương ứng, như bảo mật và
chất lượng dịch vụ (QoS) trên các máy chủ ứng dụng. Các máy chủ ứng dụng
này có thể được đưa vào kiến trúc IMS bằng cách định nghĩa các giao diện
tính cước, quản lý và điều khiển chuyên dụng. Một máy chủ ứng dụng có thể
70
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
là phục vụ cho một dịch vụ và một người dùng, cũng có thể có nhiều hơn một
dịch vụ, và như vậy rất có thể sẽ có một hay một vài máy chủ ứng dụng cung
cấp cho một thuê bao. Thêm vào đó, cũng có thể có một hay một vài máy chủ
ứng dụng liên quan tới một phiên. Ví dụ như, một nhà cung cấp có thể có một
máy chủ ứng dụng để điều khiển việc kết thúc lưu lượng tới các người dùng
dựa trên sở thích của người dùng đó (ví dụ như chuyển hướng tất cả các phiên
multimedia tới máy trả lời tự động trong khoảng từ 5 p.m đến 7 a.m) và một
máy chủ ứng dụng khác để làm thích nghi nội dung của tin nhắn tùy theo năng
lực của thiết bị người dùng (kích thước màn hình, độ phân giải…).
SIP AS (SIP Application Server) là phần liên quan đến dịch vụ trong IMS.
Các giao diện lập trình ứng dụng – API (Application Programming Interface)
đã được định nghĩa cho phép các nhà phát triển sử dụng hầu hết các mô hình
lập trình. SIP AS được kích hoạt bởi S-CSCF, S-CSCF sẽ định hướng các
phiên cụ thể đến SIP AS dựa trên các thông tin lọc khởi tạo thu được từ HSS.
Sau đó dựa trên các nguyên tắc lựa chọn của mình, SIP AS sẽ quyết định các
ứng dụng nào sẽ được triển khai trên máy chủ ứng dụng tương ứng, các máy
chủ ứng dụng này được SIP AS lựa chọn để điều khiển phiên. Trong suốt quá
trình thực thi dịch vụ logic, SIP AS cũng có thể giao tiếp với HSS để truy
nhập các thông itn bổ xung liên quan đến thuê bao.
4.3 Các chế độ hoạt động của máy chủ ứng dụngA Từ góc độ của SIP thì một máy chủ ứng dụng có thể đóng vai trò như là
originating(terminating) UA, Sip Proxy AS, Sip Redirect AS hoặc Sip
B2BUA (back-to-back user agent). Một máy chủ ứng dụng có thể hoạt động
với nhiều vai trò khác nhau phụ thuộc vào dịch vụ cung cấp cho người dùng.
4.3.1 AS hoạt động như SIP User Agent
Thiết bị đầu cuối gửi một bản Request INVITE tới Originating P-CSCF và
originating S-CSCF. S-CSCF quyết định chuyển tiếp bản tin tới một AS. AS
71
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
này hoạt động như một SIP User Agent (SIP UA) và trả lời bằng bản tin 200
OK được gửi qua S-CSCF và P-CSCF tới thiết bị đầu cuối. Một ví dụ của
dịch vụ mà sử dụng mô hình này là dịch vụ mà trong đó AS được yêu cầu xử
lý các bản tin SIP thay cho một người dùng. Mô hình này được sử dụng
trong dịch vụ Presence.
1.INVITE 2.INVITE
3.IN
VIT
E
4. 2
00 O
K
5. 200 OK6. 200 OK
IMSHome
Network
AS
P-CSCF S-CSCF
Hình 4-25 : AS hoạt động như một SIP UA
Ví dụ của dịch vụ sử dụng mô hình này là bất kỳ dịch vụ nào yêu cầu máy
chủ điều khiển yêu cầu SIP thay cho người dùng. Mô hình này được sử dụng
trong dịch vụ kiểm tra trạng thái người dùng (khi một watcher đăng ký thông
tin trạng thái người dùng của presentity, hoặc người sử dụng).
4.3.2 AS hoạt động như back-to-back user agent
Một Back-to-Back User Agent (B2BUA) chỉ đơn giản là hai SIP UA kết nối
với nhau. Hình 4-3 chỉ ra cấu trúc logic của một B2BUA.
72
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Service-specific logic
Request A
Response B
Request B
Response B
SIP UserAgent
SIP UserAgent
Hình 4-26 : Kiến trúc logic của SIP B2BUA
Hình 4-27 : AS ứng dụng đóng vai trò SIP B2BUA
Một yêu cầu A được nhận tại một bên của UA, sẽ đi qua phần logic dịch vụ
đặc trưng. Logic dịch vụ đặc trưng chịu trách nhiệm tạo ra đáp ứng A và tạo
ra một yêu cầu B mới. Logic dịch vụ đặc trưng có thể thay đổi các trường mà
Sip Proxy AS không thể thay đổi như to, from, call-id,...thậm chí thay đổi cả
method.
Một ví dụ của cấu hình này là AS đóng vai trò là prepaid AS. Trong một
phiên đang diễn ra nếu tài khoản của người gọi không còn thì nó sẽ gửi yêu
cầu BYE đến các thành viên tham gia phiên để giải phóng phiên.
4.3.3 AS đóng vai trò như là SIP Proxy Server
Trong cấu hình này AS đóng vai trò là Sip Proxy AS để cung cấp dịch vụ.
Cấu hình được chỉ ra như trong hình 4-5 cung cấp dịch vụ cho người gọi.
73
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Thiết bị đầu cuối gửi một bản tin yêu cầu INVITE tới P-CSCF và S-CSCF.
S-CSCF nhận thấy dịch vụ có liên quan đến AS và chuyển tiếp bản tin tới AS
đó. AS có thể thay đổi một số trường header trong bản tin. Ví dụ như AS
đang cung cấp dịch vụ quay số nhanh.
Hình 4-28 : AS đóng vai trò SIP Proxy AS
4.3.4 AS đóng vai trò như là SIP Redirect Server
Hình 4-29 : AS đóng vai trò SIP Redirect Server74
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Theo hình 4-6 một I-CSCF trong mạng chủ nhận bản tin INVITE (1). I-
CSCF chuyển tiếp nó tới S-CSCF (2). S-CSCF liên quan đến một AS và sẽ
chuyển tiếp bản tin INVITE yêu cầu này tới nó (3). AS hoạt động như một
Sip Redirect AS tạo ra một bản tin 302 (tạm thời chuyển moved temporarily)
đáp ứng lại (4). Đáp ứng này chứa trường Contact bao gồm URI mới để liên
lạc. Đáp ứng này được chuyển tiếp lại cho nguồn, (5) & (6). Khi nguồn của
phiên nhận được bản tin đáp ứng 302, nó sẽ tạo ra một yêu cầu INVITE mới
mà Request URI của nó là giá trị trường Contact nhận được trong bản tin
302. Bản tin INVITE mới này có thể không đến trong cùng một miền IMS.
Một ví dụ tiêu biểu về khả năng ứng dụng như Sip Redirect server là
provision của dịch vụ chuyển tiếp cuộc gọi.
4.4 Giao diện AS với các thành phần khác trong mạng
4.4.1 Giao diện với IMS Core – ISC
Giao diện điều khiển dịch vụ IMS (IMS Service Control – ISC) là giao diện
đóng vai trò cầu nối giữa mạng lõi và các máy chủ ứng dụng (cụ thể là giữa
S-CSCF với máy chủ ứng dụng). Giao diện giữa S-CSCF và máy chủ ứng
dụng được sử dụng để cung cấp dịch vụ giá trị gia tăng trong máy chủ ứng
dụng cho thuê bao. Có hai trường hợp được đưa ra ở đây:
• S-CSCF tương tác với máy chủ ứng dụng trong mạng chủ.
• S-CSCF tương tác với máy chủ ứng dụng trong mạng nhà cung cấp
thứ ba hay mạng khách.
Giao diện ISC cần hỗ trợ đăng ký thông báo sự kiện giữa S-CSCF và máy
chủ ứng dụng để cho phép máy chư ứng dụng nhận được các thông tin về các
định danh công cộng thuê bao, trạng thái đăng ký và khả năng thuộc tính của
UE.
Các thủ tục của giao diện ISC có thể chia làm hai phần:
75
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Cho các phiên mới khởi tạo bản tin SIP, S-CSCF phân tích chúng dựa
trên tiêu chí lọc khởi tạo (Initial Filter Criteria) từ hồ sơ người dùng
(user profile) – là một phần của cơ sở dữ liệu thuê bao HSS và định
tuyến chúng tới máy chủ ứng dụng cho quá trình xử lý tiếp theo. Khi
đó máy chủ ứng dụng có thể đóng vai trò UA đích, SIP Proxy hay SIP
Redirect Server.
• Máy chủ ứng dụng SIP cũng có thể khởi tạo bản tin SIP của chính nó
và hoạt động giống một User Agent Client hay B2BUA. Ví dụ như
trong trường hợp dịch vụ Click-to-dial thì máy chủ ứng dụng đóng vai
trò B2BUA làm trung gian giao tiếp giữa bên gọi và bên bị gọi.
Giao diện ISC còn giúp cho các loại máy chủ ứng dụng khác nhau (SIP AS,
OSA-SCS, IM-SSF) đều hoạt động như một SIP AS tương tác với S-CSCF.
4.4.2 Giao diện với HSS – Sh
Giao diện Sh định nghĩa giữa SIP AS hay OSA-SCS với HSS. Nó cung cấp
một dữ liệu dự trữ và các loại chức năng phục hồi như là máy chủ ứng dụng
tải dữ liệu về từ HSS hay máy chủ ứng dụng tải dữ liệu lên HSS. Những dữ
liệu này có thể phục vụ thực thi các Script hay các tham số cấu hình mà
người dùng và một dịch vụ cụ thể có thể sử dụng được. Giao diện Sh cung
cấp dịch vụ đăng ký và thông báo, để máy chủ ứng dụng có thể đăng ký nhận
thông báo khi có sự thay đổi về dữ liệu chứa trong HSS. Khi những dữ liệu
này thay đổi thì HSS sẽ thông báo tới máy chủ ứng dụng.
Việc thực hiện giao diện Sh là tùy chọn của máy chủ ứng dụng và phụ thuộc
vào bản chất của dịch vụ mà mày chủ ứng dụng cung cấp: một vài dịch vụ
yêu cầu tương tác với HSS trong khi một số dịch vụ khác thì không.
Mỗi máy chủ ứng dụng có thể tùy chọn giao tiếp với HSS sử dụng giao thức
Diameter thông qua giao diện Sh. Giao thức Diameter cơ sở thực hiện chức
năng nhận thực, cấp quyền và tính cước trong IMS và trong mạng thế hệ sau. 76
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Nó cung cấp khả năng thương lượng giữa các thực thể trong mạng liên quan
tới truyền thông, cảnh báo lỗi, truyền nhận AVP và một khả năng mở rộng
cho phép bạn có thể thêm những lệnh cụ thể và AVP mới.
Máy chủ ứng dụng, trong trường hợp này là Web Logic. Máy chủ ứng dụng
SIP có thể sử dụng lệnh UDR (User Data Request) để yêu cầu dữ liệu. HSS
sẽ trả lời về bằng bản tin UDA (User Data Answer) có chứa dữ liệu được yêu
cầu và mã kết quả. Mã này chỉ ra là bản tin có thành công hay không. Ví dụ
một thao tác thành công sẽ được trả về với mã 2001 diameter_success.
Dưới đây là danh sách các đầu cuối có thể liên quan trong trao đổi thông tin
diameter (WLSS thường thực hiện tất cả các chức năng trừ chức năng
Diameter).
• Diameter agent: một nút diameter cung cấp hoặc là các dịch vụ
chuyển tiếp, tái định hướng hay chuyển đổi.
• Diameter client: là một thiết bị ở sườn của mạng thực hiện các chức
năng truy nhập.
• Nút diameter: là một máy chủ tiến trình thực thi giao thức diameter,
và hoạt động giống như client hoặc server.
• Diameter peer: một nút diameter mà đến nó một nút diameter có thể
kết nối và vận chuyển trực tiếp.
• Relay agent: một thực thể thực hiện chức năng chuyển tiếp yêu cầu và
đáp ứng mà không cần sửa đổi bản tin.
Giao diện này cho phép một máy chủ ứng dụng giao tiếp với HSS để lấy các
dữ liệu cần thiết để cấp phát các dịch vụ logic. Các loại dữ liệu này là duy
nhất đối với một người dùng. Thường là một hồ sơ người dùng chứa một tới
một vài hồ sơ dịch vụ, mỗi hồ sơ dịch vụ này định nghĩa dịch vụ sẽ được
thực hiện như thế nào.
77
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Dữ liệu người dùng trên giao diện Sh: User Data là một khái niệm đề cập đến
các loại dữ liệu khác nhau, có thể là bất cứ thông tin nào trong số:
• Respository data: máy chủ ứng dụng sử dụng HSS để chứa các dữ liệu
trong suốt. Các dữ liệu này chỉ được hiểu bởi các máy chủ ứng dụng
có triển khai dịch vụ đó. Dữ liệu này khác nhau tùy từng người dùng
và tùy từng dịch vụ.
• Public Identifiers: tập trung định danh của người dùng.
• IMS User State: chứa các thông tin về trạng thái người dùng IMS của
một định danh công cộng của người dùng: REGISTERED,
NOT_REGISTERED, AUTHENTICATION, PENDING và
REGISTERED_UNREG_SERVICES.
• S-CSCF name: chứa tên và địa chỉ của S-CSCF phục vụ người dùng.
• Initial filter criteria: chứa các thông tin kích hoạt cho một dịch vụ.
Một máy chủ ứng dụng có thể chỉ cần lấy các tiêu chí lọc khởi tạo để
định tuyến bản tin SIP tới máy chủ ứng dụng yêu cầu.
• Location information: chứa vị trí của người dùng trong mạng chuyển
mạch gói hay mạng chuyển mạch kênh.
• User state: chứa trạng thái của người dùng trong mạng chuyển mạch
gói hay mạng chuyển mạch kênh.
• Charging information: chứa địa chỉ các chức năng tính cước.
78
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 4-30 : Sh data uml diagram
Việc thực thi giao diện Sh trong một máy chủ ứng dụng có thể hoạt động ở
hai chế độ: data handling và subscription/notification.
• Data handling (Pull/Update) : Data Handling thường được chứa trong
Sh Pull (để lấy dữ liệu từ HSS) và Sh Update để chứa dữ liệu vào
trong HSS. Khi ta truy nhập dữ liệu từ HSS, ta đang tạo ra một yêu
cầu Sh Pull Request, và khi ta chứa dữ liệu vào trong HSS thì ta đang
thực hiện một yêu cầu Sh Update.
• Subscription/notification : chế độ này chi phép WLSS lấy các thông
tin thông báo khi một dữ liệu cụ thể của một người dùng cụ thể được
HSS cập nhật bởi một vài thực thể mạng khác. Trong trường hợp cụ
79
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
thể của dịch vụ này, giao diện Sh hầu như chỉ hoạt động ở mức điều
khiển dữ liệu (data handling). Dưới đây là các thành phần thông tin có
liên quan trong thủ tục Sh Pull (để lấy dữ liệu người dùng từ HSS).
Tên thành phần thông tin Ánh xạ tới AVP Mô tả
User identity User-identity Định danh người dùng của dữ
liệu được yêu cầu
Requested-data Data-reference Chỉ ra danh sách các thông tin
yêu cầu
Requested-domain Requested-
domain
Chỉ ra miền mà thao tác này có
hiệu lực
Current-location Current-location Chỉ ra vị trí truy nhập đã được
khởi tạo hay chưa
Service-indication Service-indication Sử dụng cùng với User
Identity và Data Reference đưa
ra một tập hợp các dịch vụ liên
quan tới dữ liệu đang được yêu
cầu
Application-máy chủ ứng
dụng-identity
Origin-host Chỉ ra định danh của máy chủ
ứng dụng, sử dụng cho HSS
kiểm tra lại trong danh sách
cho phép của nó (AS
permision list)
Application-name Máy chủ ứng
dụng-name
Sử dụng cùng với User
Identity và Data Reference như
là khóa để xác định tiêu chí lọc
khởi tạo
80
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
4.5 Quá trình cung cấp dịch vụ
4.5.1 Giới thiệu
Quá trình cung cấp dịch vụ của kiến trúc IMS bao gồm ba bước cơ bản:
• Định nghĩa các dịch vụ hoặc tập dịch vụ có thể.
• Tạo ra các dữ liệu dịch vụ của người dùng dưới dạng tiêu chuẩn lọc
khởi tạo để người dùng có thể sắp xếp hay thay đổi các đăng ký.
• Chuyển tiếp các yêu cầu khởi tạo đến máy chủ ứng dụng.
4.5.2 Sự hình thành tiêu chuẩn lọc khởi tạo
Trong trường hợp thuê bao đăng ký sử dụng IMS, bản tin đăng ký của họ có
thể có các nội dung liên quan đến dịch vụ gia tăng cũng như trường hợp nhà
cung cấp muốn có máy chủ ứng dụng ở trong kiến trúc IMS của mình, thì họ
cần tạo ra các dữ liệu về dịch vụ của thuê bao. Cụ thể hơn là dữ liệu tiêu
chuẩn lọc khởi tạo đã được đề cập đến ở mục 2.6. Khi xây dựng tiêu chuẩn
lọc khởi tạo nhà cung cấp cần phải trả lời các câu hỏi:
• Điểm kích hoạt là gì?
• Máy chủ ứng dụng được chọn khi gặp điểm kích hoạt là?
• Thứ tự ưu tiên của các tiêu chuẩn lọc khởi tạo?
• Phải xử lý như thế nào nếu máy chủ ứng dụng không trả lời?
Điểm kích hoạt là lúc máy chủ ứng dụng được gọi. Điểm kích hoạt có thể
chứa nhiều các thực thể “service point trigger”. Service point trigger (SPT)
bao gồm các thành phần như sau:
81
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
SIP Header
Header: string Content: string
Service Point Trigger
ConditionNegated: boolean Group: list of integer RegistrationType: list of enumerated
SIP Method
Method: string
Session Description
Line: string Content: string
Session Case
SessionCase: enumerated
Request-URI
RequestURI: string
Hình 4-31 : Thành phần của Service Point Trigger
Như trên hình 4-8, các thành phần SPT có chức năng cụ thể như sau:
• Request-URI: xác định tài nguyên mà yêu cầu được hướng đến (ví dụ:
[email protected]). Request-URI chứa thuộc tính RequestURI của
bản tin SIP cần xác nhận.
• SIP Method: dùng để kiểm tra phương thức yêu cầu nào của bản tin
SIP (có thể là REGISTER, INVITE, PUBLISH, SUBSCRIBE,
MESSAGE,…).
• SIP Header: chứa thông tin liên quan đến yêu cầu. SPT có thể dựa
trên sự có mặt hay vắng mặt của một SIP Header nào đó với giá trị
Header là tên của Header cần xét và giá trị Content là nội dung của
header đó. Giá trị của Content được sử dụng như một mẫu để kiểm
tra.
• Session Case: dùng để xác định chiều của bản tin là khởi tạo
(originating) hay kết thúc (terminating) trong trường hợp người dùng
có đăng ký (registered) hoặc chưa đăng ký (unregistered). Nói cách
khác, trường này được sử dụng bởi S-CSCF để xử lý dịch vụ cho phía 82
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
nguồn, dịch vụ cho phía đích hay dịch vụ cho phía đích chưa đăng ký.
Trường hợp nguồn là khi S-CSCF phục vụ cho phía khởi tạo phiên
(người gọi), trường hợp đích là khi S-CSCF phục vụ cho phía cuối
của phiên (người bị gọi).
• Session Description: xác định SPT cho nội dung của trường SDP
trong phần thân (body) của phương thức SIP. Mẫu kiểm tra có thể sử
dụng ở đây.
Về mặt dữ liệu thì cấu trúc của tiêu chuẩn lọc khởi tạo được mã hóa dựa trên
xml. Dưới đây là một ví dụ tiêu chuẩn lọc khởi tạo cho dịch vụ hộp thư thoại
tại máy chủ ứng dụng (sip:[email protected]) dành cho thuê bao
chưa đăng ký. Để làm được điều này thì nhà cung cấp phải làm cho SIP
Method có giá trị là INVITE và Session Case có giá trị là terminating –
unregistered. Nếu như không kết nối đến được máy chủ ứng dụng thì xử lý
mặc định là dừng phiên lại.
83
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 4-32 : Ví dụ về User Profile
4.5.3 Lựa chọn máy chủ ứng dụng
Tiêu chuẩn lọc khởi tạo được tải về S-CSCF trong quá trình đăng ký của thuê
bao hoặc khi nhận được yêu cầu khởi tạo đích cho thuê bao chưa đăng ký.
Sau khi tải hồ sơ thuê bao từ HSS, S-CSCF sẽ quyết định tiêu chuẩn lọc cho
từng yêu cầu khởi tạo theo các bước sau:
84
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Kiểm tra xem dịnh danh người dùng công cộng có bị chặn hay không?
Nếu không thì tiếp tục.
• Kiểm tra xem yêu cầu là yêu cầu đích (terminating) hay yêu cầu
nguồn (originating).
• Chọn tiêu chuẩn lọc khởi tạo cho các trường hợp phiên cụ thể (nguồn,
đích, đích cho người dùng chưa đăng ký).
• Kiểm tra xem yêu cầu có khớp với tiêu chuẩn lọc khởi tạo có độ ưu
tiên cao nhất bằng cách so sánh hồ sơ dịch vụ với định danh người
dùng công cộng trong yêu cầu:
o Nếu yêu cầu khớp với tiêu chuẩn lọc khởi tạo, S-CSCF sẽ
chuyển tiếp yêu cầu này đến máy chủ ứng dụng, sau đó kiểm
tra xem nó có khớp với tiêu chuẩn lọc khởi tạo có độ ưu tiên
thấp hơn hay không? Nếu có áp dụng vào SIP Method nhận
được từ liên lạc trước đó đến máy chủ ứng dụng.
o Nếu yêu cầu không khớp với tiêu chuẩn lọc khởi tạo có độ ưu
tiên cao nhất thì tiếp tục kiểm tra cho đến khi nó khớp.
o Nếu không còn (hoặc không có) tiêu chuẩn lọc khởi tạo nào
khớp, thì S-CSCF sẽ chuyển yêu cầu theo các quyết định định
tuyến.
Ở đây tồn tại sự khác biệt rõ ràng giữa cách xử lý của S-CSCF với tiêu chuẩn
lọc khởi tạo cho yêu cầu nguồn và đích. Khi S-CSCF nhận ra rằng máy chủ
ứng dụng đã thay đổi Request-URI trong trường hợp tiêu chuẩn lọc khởi tạo
đích, nó sẽ dừng kiểm tra và định tuyến yêu cầu theo giá trị của Request-
URI. Trong trường hợp nguồn, S-CSCF sẽ tiếp tục đánh giá các tiêu chuẩn
lọc khởi tạo cho đến khi hết.
85
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Nếu máy chủ ứng dụng được liên lạc không phản hồi, S-CSCF sẽ gọi hành
động mặc định được nêu ra trong tiêu chuẩn lọc khởi tạo: hoặc là dừng phiên
hoặc là cho tiếp tục dựa trên các thông tin được cung cấp ở tiêu chuẩn lọc
khởi tạo. Nếu trong tiêu chuẩn lọc khởi tạo không đề cập đến hành động mặc
định, nếu không liên lạc được với máy chủ ứng dụng thì S-CSCF sẽ cho cuộc
gọi tiếp tục.
4.5.4 Hành vi của máy chủ ứng dụng
Sau khi nhận được yêu cầu, máy chủ ứng dụng sẽ bắt đầu khởi tạo các dịch
vụ cụ thể. Để đáp ứng dịch vụ máy chủ ứng dụng có thể hoạt động như một
trong các dịch vụ sau:
• Terminating User Agent.
• Redirect Server.
• SIP Proxy Server.
• Back-to-back User Agent
Ngoài các chế độ trên, máy chủ ứng dụng còn có thể hoạt động như một
Originating User Agent, nó có thể gửi yêu cầu đến thuê bao: ví dụ như máy
chủ ứng dụng tin tức có thể gửi trả kết quả bong đá cho thuê bao đăng ký
dịch vụ.
4.5.5 Máy chủ ứng dụng tương tác với HSS
Khi nhận được một yêu cầu từ phía người sử dụng, máy chủ ứng dụng sử
dụng giao diện Sh bằng giao thức diameter để truy vấn cơ sở dữ liệu HSS các
thông tin cần thiết để thực hiện dịch vụ:
• Khi nhận được yêu cầu sử dụng dịch vụ từ phía người dùng cuối
thông qua giao diện Web, máy chủ ứng dụng sử dụng giao thức Sh để
tải về hồ sơ người dùng. Sau đó, máy chủ ứng dụng sẽ tiến hành kiểm
86
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
tra tiêu chuẩn lọc khởi tạo trong hồ sơ người dùng: nếu người dùng
chưa đăng ký sử dụng dịch vụ thì máy chủ sẽ gửi trả lại thông báo cho
người dùng, ngược lại nếu người dùng đã đăng ký thì máy chủ ứng
dụng sẽ xử lý thông tin trong yêu cầu đó do người dùng đầu cuối gửi
lên để thực hiện dịch vụ.
• Thông tin về S-CSCF liên quan tới người gọi và người bị gọi, để máy
chủ ứng dụng có thể chuyển tiếp bản tin và thực hiện dịch vụ.
Chi tiết về giao diện Sh xem tại mục 4.4.2.
4.5.6 Máy chủ ứng dụng gửi yêu cầu về S-CSCF
Trong ứng dụng này, máy chủ đóng vai trò như một B2BUA, vì vậy khi nhận
được bản tin HTTP POST từ phía người dùng đầu cuối, nó kiểm tra trong
tiêu chuẩn lọc. Nếu thỏa mãn các điều kiện, máy chủ sẽ thực hiện dịch vụ
bằng cách tạo ra một bản tin INVITE dựa vào các thông tin S-CSCF phục vụ
người dùng tải được về thông qua giao diện Sh, nó sẽ chuyển tiếp bản tin
INVITE khởi tạo đến S-CSCF của người gọi để khởi tạo dịch vụ.
87
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
5 CHƯƠNG V : DỊCH VỤ IPTV TRÊN NỀN IMS
IPTV được định nghĩa là các dịch vụ đa phương tiện như truyền hình, video,
audio, hình ảnh được cung cấp trên nền tảng là mạng IP nhằm cung cấp các
mức cần thiết về chất lượng dịch vụ, chất lượng trải nghiệm, khả năng bảo mật,
tính tương tác và tính ổn định.
Trên nền tảng IMS, yếu tố di động và truy nhập không dây trở nên khả thi, càng
tạo điều kiện cho IPTV phát triển thành một trong những dạng dịch vụ Quad-
Play. Ngoài các dịch vụ truyền hình quảng bá thông thường, Video theo yêu cầu
(Video on Demand – VoD), IPTV còn hỗ trợ sự tương tác giữa người xem với
chương trình và đây cũng chính điểm đặc biệt và hấp dẫn nhất của IPTV.
Không đơn thuần là truyền hình như truyền hình cáp truyền thống, IPTV là một
tổng thể chuỗi các dịch vụ truyền hình có tính tương tác. Ngoài việc tự do lựa
chọn chương trình truyền hình hay phim muốn xem, người sử dụng có thể tham
gia các cuộc hội thảo từ xa, chơi game, mua hàng qua TV hoặc viết blog video
(vlog), nhắn tin qua TV...
5.1 Giới thiệu dịch vụ IPTV trên nền IMS
IPTV trên nền IMS cho phép người dùng truy cập và xem các kênh truyền hình
hoặc các kênh phát theo yêu cầu bằng cách thiết lập 1 cuộc gọi đến 1 địa chỉ
dạng email (sip uri) 1 cách dễ dàng và tiện lợi như cách người ta vẫn gọi điện
thoại cho bạn bè.
Khác với dịch vụ IPTV truyền thống, IPTV trên nền IMS cho phép người dùng
truy cập dịch vụ từ bất kỳ đâu, ở nhà cũng như đang đi xe bus. Tất cả những gì
cần chỉ là gọi điện thoại tới 1 địa chỉ URI hoặc tới 1 số điện thoại đã được định
88
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
sẵn, sau đó luồng media trực tiếp được truyền về máy người sử dụng mà không
cần phải cài đặt thêm bất cứ cái gì khác.
Ngoài ra IPTV trên nền IMS còn mở ra cho nhà cung cấp dịch vụ cách thức tốt
nhất và nhanh nhất để phát triển dịch vụ của mình. Dựa vào nền tảng rất mạnh
trong thiết kế dịch vụ của IMS, nhà cung cấp có thể thêm vào dịch vụ của mình
rất nhiều giá trị gia tăng làm tăng sự thoải mái của khách hang.
Trong đề tài này, dịch vụ IPTV được tích hợp khả năng quản lý quyền truy cập,
là chức năng rất cần thiết đối với những bậc phụ huynh không có thời gian quản
lý con em mình. Đối với những người dùng đăng ký chức năng Parental Control
– quản lý quyền truy cập đối với trẻ em, hệ thống tự động lọc những nội dung
được yêu cầu.
Trước hết hệ thống sẽ loại bỏ tất cả những kênh không phù hợp với lứa tuổi khi
được yêu cầu danh sách kênh hiện có. Sau đó đối với những kênh thuộc diện
quản lý của cha mẹ hoặc những kênh cấm truy cập theo giờ (vd như các kênh
phim hành động mỹ trong thời gian cha mẹ vắng nhà hoặc các kênh giải trí
trong thời gian làm bài tập hoặc tất cả các kênh khi đến giờ đi ngủ…) hệ thống
sẽ nhắn tin đến cha mẹ hoặc người lớn tuổi có liên quan để hỏi quyền truy cập
của người dùng này.
Nếu tin nhắn trả lời của cha mẹ là tin nhắn đồng ý, hệ thống sẽ phục vụ như
thường, còn nếu ngược lại, 1 tin nhắn thông báo sẽ được gửi về người dùng nói
rằng bạn không được người lớn cho phép.
89
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
5.2 Các luồng xử lý cuộc gọi trong IPTV nền IMS
5.2.1 Đăng ký vào mạng IMS
5.2.1.1 Thiết bị đầu cuối người dùng thực hiện đăng ký tới S-CSCF
UE P-CSCF I-CSCF HSSS-CSCF
F1. REGISTER
F2. REGISTER
F3. REGISTER
Chọn S-CSCF
Chứng thực dữ liệu
Ipsec sercurity
F4. 401 ( Unauthorized )
F5. 401 ( Unauthorized )
F6. 401 ( Unauthorized )
F7. REGISTER
F8. REGISTER
F9. REGISTER
HÌnh 5-33:Quá trình đăng ký của user vào mạng IMS (tiếp)
Các thủ tục đăng ký IMS:
• UE xác định địa chỉ của P-CSCF, P-CSCF sử dụng như một proxy
biên SIP trong suốt quá trình đăng ký và cho tất cả các báo hiệu SIP
khác trong khi nó đã được đăng ký.
• UE gửi bản tin REGISTER tới mạng chủ của alice để thực hiện đăng
ký SIP cho nhận dạng người dùng công cộng của alice.
• I-CSCF lựa chọn S-CSCF phục vụ người dùng khi nó đã đăng ký.
90
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• S-CSCF tải các dữ liệu xác thực người dùng từ HSS.
• UE và mạng S-CSCF xác thực mỗi dữ liệu đó.
• Các chức năng bảo mật IP (IP sec) giữa UE và P-CSCF được thiết
lập.
• UE học đường đến S-CSCF.
• S-CSCF học đường đến UE.
UE P-CSCF I-CSCF HSSS-CSCF
Tải về hồ sơ người dùng
F13. SUBSCRIBE
F10. 200 OK
F11. 200 OK
F12. 200 OK
F14. SUBSCRIBE
F15. 200 OK
F16. 200 OK
F17. NOTIFY
F18. NOTIFY
F20. 200 OKF19. 200 OK
F21. SUBSCRIBE
F22. SUBSCRIBE
F23. 200 OK
F24. 200 OK
F25. NOTIFY
F26. 200 OK
HÌnh 5-34: Quá trình đăng ký của user vào mạng IMS (tiếp)
Quá trình đăng ký tiếp tục với các thủ tục:
91
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• S-CSCF tải về hồ sơ người dùng từ HSS.
• S-CSCF đăng ký nhận dạng người dùng công cộng mặc định của
người dùng.
• S-CSCF có thể dựa trên hồ sơ người dùng để đăng ký nhận dạng
người dùng công cộng khác.
• UE biết về tất các nhận dạng người dùng công cộng đã được gán cho
alice và trạng thái đăng ký hiện tại của anh ta.
• P-CSCF biết tất cả các nhận dang công cộng được gán cho alice và
trạng thái đăng ký hiện tại của anh ta.
S-CSCF Application Server
REGISTER
200 OK
Đánh giá các tiêu chuẩn lọc
REGISTER
200 OK
HÌnh 5-35: Quá trình đăng ký của user vào mạng IMS (tiếp)
Sau khi người dùng đăng ký thành công, S-CSCF sẽ kiểm tra các tiêu chí
lọc đã tải về của người dùng.
92
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
5.2.2 Call flows của các chức năng chính trong dịch vụ IPTV
5.2.2.1 Chức năng “Danh sách chương trình nâng cao”
Danh sách chương trình là thành phần không thể thiếu đối với dịch vụ
truyền hình. Danh sách chương trình cho người xem biết hiện tại có tổng
cộng bao nhiêu kênh đang được chiếu, có những nội dung nào đáng quan
tâm.
Chức năng “danh sách chương trình nâng cao” của dịch vụ IPTV nền IMS
cho phép lọc danh sách kênh phù hợp với lứa tuổi. Trong danh sách chương
trình của những người sử dụng là trẻ nhỏ sẽ không có các kênh dành cho
người lớn và danh sách kênh của những người dùng thông thường sẽ không
giống với của những người dùng cao cấp (trả thêm tiền, quan chức, lãnh
đạo v.v…)
93
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 5-36: Người dùng thông thường
UE gửi bản tin SUBSCRIBE tới các CSCF với event = “iptv”, các CSCF sẽ
chuyển tiếp bản tin SUBSCRIBE này lên Application Server. AS sẽ kiểm
tra ở HSS xem UE có được quyền xem IPTV hay không, và nếu có thì user
có đăng ký dịch vụ parental control hay ko.
Nếu user đã đăng ký với nhà cung cấp dịch vụ IPTV và không dùng gói
parental control thì AS sẽ trả về bản tin 200 OK, trong phần content của
200 OK chứa file xml có thông tin về các kênh. Bản tin 200 OK được các
CSCF chuyển tiếp tới UE.
94
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Tại UE, IMS – Communicator có trách nhiệm tách bản tin 200 OK lấy file
xml về thông tin các kênh, hiển thị ra một Frame cho người sử dụng thấy
dưới dạng cây thư mục. Nếu muốn xem một kênh nào đó người sử dụng sẽ
nhấn vào kênh đó, từ đó kết nối với kênh được thiết lập.
Với những user sử dụng gói dịch vụ parental control thì AS sẽ lọc nội dung
các kênh hiện có và chỉ trả về các kênh phù hợp với lứa tuổi của user đã
đăng ký.
HÌnh 5-37: Đăng nhập với dịch vụ IPTV trường hợp có Access control
95
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
5.2.2.2 Chức năng “Truyền hình cơ bản”
Đây là chức năng cơ bản nhất của ngành truyền hình, đối với bất cứ công
nghệ nào, truyền hình qua vệ tinh, qua dây cáp hay qua sóng vô tuyến hay
nền IP, những nội dung truyền hình cơ bản như các kênh thông tin chính
thức của nhà nước đều nhất thiết phải có. Những kênh này có 2 dạng, 1 là
truyền hình trực tiếp, 2 là truyền phát lại từ thiết bị lưu trữ. Phần lớn những
nội dung này đều được chiếu phát miễn phí cho tất cả đối tượng khách
hang.
HÌnh 5-38: Dịch vụ truyền hình cơ bản
96
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Người sử dụng gửi bản tin INVITE với trường “To” là ID của kênh cần
xem ( nhận được từ file xml) . Ví dụ là : [email protected]. Bản tin này
được các CSCF chuyển tới AS. AS tiếp nhận bản tin này. Nếu đồng ý nó sẽ
tìm kiếm trong cơ sở dũ liệu của nó xem kênh được yêu cầu là do đài truyền
hình nào phát, kết quả tìm kiếm là 1 “Media Resource Location - MRL”
giống như địa chỉ URL như chúng ta thường duyệt web.
Địa chỉ này thường có dạng “rtsp://domain/channel.sdp” , sau đó được
đính kèm vào bản tin 200 OK gửi lại cho người sử dụng.
Từ đó người sử dụng sẽ mở 1 phiên media kết nối trực tiếp với đài truyền
hình – đơn vị cung cấp nội dung truyền hình và xem các kênh ở đây.
5.2.2.3 Chức năng “Video theo yêu cầu”
Bên cạnh truyền hình truyền thống, dịch vụ IPTV được phát triển trong đồ
án có kèm theo chức năng Video on Demand tạm dịch là Video theo yêu
cầu. Để sử dụng dịch vụ này, người sử dụng sẽ đăng ký với nhà cung cấp
dịch vụ các gói tương ứng là Standard VoD hay là Advanced VoD – VoD
tiêu chuẩn hoặc VoD cao cấp.
Dịch vụ VoD tiêu chuẩn phục vụ khách hàng như dịch vụ truyền hình theo
yêu cầu thông thường, khách hàng gửi yêu cầu vào nhận lại danh sách nội
dung số, danh sách này được cập nhật thường xuyên. Để xem 1 nội dung
nào đó người sử dụng sẽ gửi bản tin INVITE và nội dung số sẽ truyền tới
người sử dụng.
Dịch vụ VoD cao cấp cho phép người dùng chặn quyền truy cập đối với trẻ
nhỏ theo phân loại nội dung và thời gian truy cập. Ngoài ra còn có chức
năng nhắn tin tới người lớn khi có yêu cầu từ trẻ nhỏ tới những nội dung
không phù hợp hoặc vi phạm thời gian được phép sử dụng. Dịch vụ này còn
có khả năng cung cấp video hiện trường, cho phép người sử dụng có thể
97
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
xem trực tiếp cận cảnh ở 1 nơi nào đó – vd như tình hình giao thông ở 1 số
tuyến đường có lắp hệ thống camera.
Đầu tiên, UE gửi bản tin INVITE với trường “To” là ID của kênh cần xem (
nhận được từ file xml) . Ví dụ là : [email protected]. Bản tin này
được các CSCF chuyển tới AS. AS tiếp nhận bản tin này. Nếu đồng ý nó
chuyển tiếp bản tin này sang cho máy chủ phục vụ nội dung số MRF, MRF
chỉ có nhiệm vụ phục vụ nội dung cho người sử dụng, nó sẽ gửi về bản tin
183 Session Progress và bản tin 200 OK xác nhân là yêu cầu của quý khách
đã được chấp nhận.
Sau đó MRF sẽ mở 1 luồng media streaming truyền tải nội dung số tới ip
của máy tính của người dùng như đã đăng ký trong bản tin SIP/SDP
98
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 5-39: Dịch vụ VoD tiêu chuẩn
Nếu UE muốn kết thúc xem, UE gửi bản tin BYE tới AS với trường “To” là
[email protected], Call-ID là Call-ID của phiên hiện thời, chính là
Call-ID của bản tin INVITE. AS nhận được bản tin BYE sẽ gửi về bản tin
200 OK cho UE biết AS đã nhận được bản tin BYE của UE
99
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 5-40: Dịch vụ VoD nâng cao
Đối với những kênh thuộc diện quản lý hướng dẫn của cha mẹ (Rating PG
– parental guidance) thì AS sẽ gửi cho reference user của người dùng 1
thông điệp có nội dung xin phép truy cập. Nếu nhận được sự đồng ý thì
phiên dịch vụ diễn ra bình thường, còn ko thì 1 bản tin unauthorize sẽ được
trả về cho người yêu cầu kèm với lý do của cha mẹ.
100
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
5.2.3 Các tình huống khi đăng nhập và sử dụng dịch vụ IPTv
5.2.3.1 Các trường hợp từ chối dịch vụ
Máy chủ IPTV từ chối không phục vụ người dùng trong các trường hợp
sau:
Từ chối đăng ký dịch vụ: khi IPTv server tải xuống profile người dùng từ
HSS mà không thấy dịch vụ Iptv được đăng ký thì server sẽ trả về bản tin
401 unauthorized với lý do là xin mời đăng ký với nhà cũng cấp dịch vụ
IPTV trước.
Từ chối phục vụ dịch vụ:
o khi người dùng gửi bản tin INVITE yêu cầu 1 kênh bất kỳ mà chưa
Login vào dịch vụ bằng bản tin SUBSCRIBE thì hệ thống sẽ trả về
bản tin 401 Unauthorized với lý do là xin hay đăng nhập vào dịch
vụ trước.
o khi người dùng gửi bản tin INVITE yêu cầu 1 kênh không có trong
cơ sở dũ liệu của máy chủ IPTV thì hệ thống sẽ trả về bản tin 604
kèm lý do là kênh được yêu cầu không tồn tại hoặc đã bị xóa khỏi
hệ thống.
o khi người dùng gửi bản tin INVITE yêu cầu 1 kênh mà phải có sự
chấp thuận của người khác mà máy chủ IPTV kiểm tra thấy người
đó hiện không lien lạc được hoặc đang trả lời 1 yêu cầu truy cập
khác thì hệ thống sẽ trả về bản tin 603 với lý do là không thể liên
lạc được với cha mẹ bạn hoặc họ đang bận.
5.2.3.2 Thiết bị đầu cuối bị ngắt đột ngột
Về nguyên tắc, trước khi có thể thực hiện bất kỳ 1 yêu cầu dịch vụ nào,
người dùng đều phải đăng ký vào phiên IPTv bằng bản tin SUBSCRIBE.
Tuy nhiên trong quá trình sử dụng sẽ gặp phải trường hợp là thiết bị đầu
101
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
cuối bị ngắt đột ngột, có thể là do mất điện, khi đó sau khi bật lên thiết bị
sẽ lại đăng nhập lại 1 lần nữa. Trong trường hợp này phía server sẽ tự
nhận biết được và sẽ xóa phiên làm việc trước của user sau đó tự dộng
đăng nhập lại, mọi thay đổi trên hệ thống đều được cập nhật mới.
102
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
6 CHƯƠNG VI : THIẾT KẾ DỊCH VỤ IPTV
Nội dung chương này sẽ tập trung vào quá trình thiết kế dịch vụ, các công nghệ
được áp dụng, các yêu cầu thực tế, sơ đồ lớp và các sơ đồ thuật giải để thực
hiện dịch vụ.
6.1 Tổng quan về công nghệ SIP Servlet
6.1.1 Mô hình SIP Servlet
SIP Servlet là một thành phần ứng dụng của Java cơ bản, được quản lý bởi
một SIP Servlet container và được thực thi bởi các bản tin SIP. Giống như
các thành phần Java cơ bản khác, các servlet là các lớp Java trên nền tảng
độc lạp mà nó được biên dịch thành mã máy, các mã máy này có thể được
nạp tự động vào và chạy như là một máy chủ ứng dụng SIP. Các container
thi thoảng còn được gọi là các phương tiện servlet, là các phần mở rộng của
máy chủ cung cấp các chức năng servlet. Servlet tương tác với các client này
bằng cách trao đổi các bản tin yêu cầu (request) và hồi đáp (response) thông
qua các servlet container.
Servlet container là một bộ phận máy chủ là một bộ phận máy chủ ứng dụng
cung cấp dịch vụ mạng thông qua các yêu cầu nhận được và hồi đáp gửi đi.
Servlet containter quyết định các ứng dụng nào để gọi và trong lệnh nào. Một
servlet container vừa chứa và vừa quản lý các servlet thông qua vòng đời của
chúng. Một servlet container có thể được dựng lên bởi một máy chủ SIP,
hoặc được cài đặt như là một bộ phận bổ xung tới SIP server thông qua các
giao diện lập trình ứng dụng mở rộng riêng của server đó. Một SIP servlet
container có thể vừa được dựng lên hoặc có khả năng được cài vào servlet,
kích hoạt các máy chủ ứng dụng. Một SIP servlet container quản lý các điểm
lắng nghe (listener) của mạng và các điểm đó lắng nghe các luồng lưu lượng 103
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
SIP theo chiều đến (một điểm lắng nghe được tổ hợp bởi giao thức vận
chuyển, địa chỉ IP và số hiệu cổng). Các đặc tính SIP yêu cầu tất cả các nhân
tố SIP hỗ trợ cả UDP và TCP, và có thể là TLS, SCTP, và một số các lớp vận
chuyển khác. Một servlet container có thể đặt các giới hạn bảo mật ở trên
môi trường mà một servlet thực thi. Trong môi trường J2SE 1.2 và J2EE 1.3,
các giwosi hạn này nên được đặt bằng cách sử dụng các kiến trúc cho phép
định nghĩa Java2 Platform.
SIP Servlet cũng tương tự như HTTP Servlet ngoại trừ việc chúng xử lý các
yêu cầu SIP. Chúng thực hiện việc này bày cách định nghĩa các phương thức
đặc tả cho mỗi yêu cầu SIP. Ví dụ HTTP Servlet định nghĩa phương thức
doPost() viết đè lên phương thức Service() để xử lý yêu cầu Post. Trong khi
đó, SIP Servlet sử dụng giao thức doInvite() viết đè lên phương thức
Service() để xử lý yêu cầu Invite. SIP servlet và HTTP servlets có thể được
đóng gói với nhau với tài nguyên khác nhau như các thư viện và các lớp khác
nhau, nội dung tĩnh (tập tin âm thanh, tệp hình ảnh, video,…) và một vài tập
tin cấu hình để tạo ra một ứng dụng hội tụ.
6.1.2 Các khái niệm chính của SIP Servlet API
Khái niệm chính của SIP Servlet tương tự như HTTP Servlet.Các phần dưới
đây sẽ mô tả phần chính của một vài khái niệm.
6.1.2.1 Mục đích của SIP Servlet API
Một số thuộc tính quan trọng của API bao gồm:
• SIP Signaling: chấp nhận cho các ứng dụng thực hiện hoàn thành
một chuỗi các hành động của tín hiệu SIP, bao gồm hỗ trợ các nhiệm
vụ như User Agent Client (UAC), User Agent Server (UAS) và
proxy.
104
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Tính đơn giản: các Container xử lý các việc phức tạp không cần thiết
như quản lý các điểm lắng nghe mạng, truyền lại, Cseq, Call-ID
thông qua các trường điều khiển, định tuyến,…
• Các ứng dụng hội tụ: các Container có khả năng hỗ trợ cho các ứng
dụng hội tụ, đó là các ứng dụng có thể chia ra thành nhiều các giao
thức và các loại media khác nhau, ví dụ như web, telephony và
presence.
• Phát triển ứng dụng tại nhà cung cấp thứ ba: mô hình servlet hỗ trợ
việc phát triển ứng dụng cho bên thứ ba. Việc mô tả triển khai XML
thường được sử dụng để giao tiếp thông tin ứng dụng từ các bên thiết
kế ứng dụng cho tới bên triển khai.
• Thành phần ứng dụng: có thể dùng cho một vài các ứng dụng thực
thi trên các yêu cầu hoặc hồi đáp theo chiều đến hoặc đi. Mỗi một
ứng dụng có một bộ các quy tắc của nó và thực thi một cách độc lập
với các ứng dụng khác một cách rành mạch và tạo thành theo thứ tự.
• Carrier grade (cấp độ carrier): các servlet lưu trữ dữ liệu ứng dụng
trong các container quản lý các phiên đối tượng. Việc triển khai có
thể tiếp tục tái tạo dữ liệu này để đạt được hiệu quả cao.
6.1.2.2 Vòng đời của SIP Servlet
Vòng đời của một servlet được bắt đầu tính từ khi nó được nạp vào trong
bộ nhớ của máy chủ ứng dụng (AS) và kết thúc khi servlet bị ngắt hoặc nạp
lại.
Vòng đời của servlet bao gồm các bước sau:
• Lớp servlet được nạp bởi container trong suốt quá trình khởi động.
• Bộ chứa gọi phương thức init(). Phương thức khởi tạo servlet và phải
được gọi trước khi servlet có thể phục vụ bất kỳ yêu cầu nào. Trong 105
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
toàn bộ vòng đời của một servlet, phương thức init() chỉ được gọi
một lần.
• Sau quá trình khởi tạo, servlet có thể phục vụ các yêu cầu từ phía
client. Mỗi một yêu cầu được phục vụ trong một chuỗi riêng biệt mà
nó sở hữu. Bộ chứa gọi phương thức nào được làm và gửi nó đi với
một phương thức thích hợp với yêu cầu đẻ xử lý yêu cầu đo. Người
phát triển servlet phải cung cấp việc triển khai cho các phương thức
này. Nếu một yêu cầu cho phương thức mà không được triển khai
bởi servlet, phương thức của lớp cha sẽ được gọi, thường là kết quả
của một lỗi được trả lại từ người yêu cầu.
• Cuối cùng, bộ chứa gọi phương thức destroy() để cho container làm
cho servlet không thực hiện phục vụ. Phương thức destroy() tương tự
như phương thức init() chỉ được gọi một lần trong vòng đời của
servlet.
Hình 6-41 : Vòng đời của Servlet
Có thể hiểu vòng đời của một servlet thông qua các phương thức sau: đoạn
mã (code) được nạp vào server; sau đó các lớp servlet được thực hiện và
khởi tạo; servlet được gọi nhiều lần để xử lý các bản tin đến; cuối cùng
servlet được phá hủy.
6.1.2.3 Ngữ cảnh SIP Servlet
Ngữ cảnh servlet được định nghĩa trong đặc tả servlet cũng được áp dụng
cho SIP servlet. Đặc tả servlet định nghĩa các thuộc tính ngữ cảnh cụ thể
106
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
được sử dụng để lưu trữ và truy nhập thông tin tới SIP servlet và các giao
diện từ ngữ cảnh. Ngữ cảnh servlet có thể dùng chung với HTTP servlet
trong cùng một ứng dụng.
6.1.2.3.1 SIP Factory
SIP Factory là một lớp xưởng (factory) để tạo các đối tượng chuẩn SIP
Servlet cần thiết cho việc thực thi ứng dụng. Giao diện của SIPFactory
được sử dụng bởi các servlet để tạo các thực thể của các giao diện khác
nhau:
Tên lớp Mô tảURI, Sip URI, Address có thể tạo ra thông tin địa chỉ bao gồm SIP URI từ một
chuỗi.SipApplicationSession tạo một phiên ứng dụng mới. Nó được gọi khi một SIP
Servlet bắt đầu xử lý một tín hiệu SIP mới. Điều đó có nghĩa là các phiên ứng dụng thường được sử dụng trong thời gian khởi động khi một ứng dụng được gọi để khởi chạy nó và nên được sử dụng tiết kiệm.
SipServletRequest sử dụng khi một SIP servlet hoạt động như một UAC tạo một yêu cầu. Thí dụ như các yêu cầu có thể không được gửi với Proxy.proxyTo. Chúng có thể được gửi với SipServletRequest.send. Nói cách khác: • Các phương thức creatRequest tạo các thực thể của
giao diện SipServletRequest và được sử dụng bởi các ứng dụng UAC khi khởi tạo các yêu cầu trong một hộp thoại mới.
• Khi khởi tạo một chuỗi con các yêu cầu trong hộp thoại đang tồn tại, SipSession.createRequest được sử dụng thay thế.
SIPFactory được đặt trong ngữ cảnh servlet dưới tên mặc định. Ta có thể
thực hiện nó với đoạn mã dưới đây:
ServletContext context = getServletContext();
SipFactory factory =
(SipFactory) context.getAttribute(“javax.servlet.sip.SipFactory”);
107
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Tất cả các container servlet phải thực hiện một trường hợp của giao diện
javax.servlet.sip.SipFactory tồn tại với các servlet thông qua ngữ cảnh có
cùng tên, javax.servlet.sip.SipFactory.
6.1.2.3.2 Đường dẫn ngữ cảnh
Servlet API định nghĩa về khái niệm đường dẫn ngữ cảnh. Đây là một tiền
tố đường dẫn URL kết hợp với một ứng dụng web. Tất cả các yêu cầu
HTTP URL bắt đầu với đường dẫn ngữ cảnh của một ứng dụng web sẽ
được định tuyến tới ngữ cảnh servlet tương ứng. Trong khi SIP URIs
không có khái niệm về các đường dẫn, các phương thức ServletContext
dưới đây không có nghĩa cho các ứng dụng hoặc bộ chứa servlet SIP và
phải trở về giá trị rỗng:
ServletContext getContext(String uripath);String getRealPath(String path);RequestDispatcher getRequestDispatcher(String path);
Để việc nạp tài nguyên được đề cập tới, đường dẫn ngữ cảnh của SIP
servlet luôn luôn có “/”. Tổ hợp giữa thực thi ứng dụng HTTP và SIP
trong bộ chứa HTTP Servlet, đường dẫn ngữ cảnh được định nghĩa bởi
HTTP Servlet API và việc nạp tài nguyên xử lý theo chuẩn Java Servlet
[Servlet API].
6.1.2.3.3 Các tham số ngữ cảnh
Các bộ chứa với các chuẩn phải được thực hiện theo các thông số của
bảng tham khảo dưới đây với các ứng dụng có ngữ cảnh Servlet:
Thông số Mô tảjavax.servlet.sip.supported Một thực thể không đổi của giao diện
java.util.List chứa các tên xâu của phần mở rộng SIP hỗ trợ bởi bộ chứa.
javax.servlet.sip.supportedRfcs Một thực thể không đổi của giao diện java.util.List chứa các số RFC mô tả như xâu của SIP RFC hỗ trợ bởi bộ chứa
108
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
javax.servlet.sip.100rel Thông số mà giá trị đề xuất được bộ chứa hỗ trợ phần mở rộng 100rel. Thông số này không được tán thành trong chuẩn của tham số javax.sip.supported
javax.servlet.sip.SipSessionsUtil Bộ chứa lớp SipSessionUtil cho ID trên cơ sở tìm kiếm thực thể SipApplicationSession
javax.servlet.sip.SipFactory Thực thể của các ứng dụng SipFactoryjavax.servlet.sip.outboundInterfaces Một thực thể không đổi của giao diện
java.util.List chứa trong Sip URI mô tả bởi địa chỉ IP được sử dụng bởi bộ chứa để gửi đi các bản tin
javax.servlet.sip.TimeService Thực thể của lớp TimeService
6.1.2.4 SIPServletRequest và SIPServletResponse
Phương pháp luận yêu cầu–hồi đáp trong SIP cũng tương tự như trong
HTTP Servlet. Một yêu cầu được định nghĩa trong đối tượng
SipServletRequest và một hồi đáp được định nghĩa trong đối tượng
SipServlerResponse. Tuy nhiên, chỉ có một đối tượng ServletRequest hoặc
ServletReponse là có giá trị. Điều này là do một yêu cầu SIP không đưa ra
một hồi đáp đối xứng. Cũng có một giao diện chung gọi là
SipServletMessage cho cả đối tượng SipServletRequest và
SipServletResponse. Giao diện SipServletMessage định nghĩa các phương
thức chung cho các đối tượng SipServletRequest và SipServletResponse.
109
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Hình 6-42 : Minh họa cấu trúc phân cấp của đối tượng SipServletRequest và
SipServletResponse
6.1.2.5 Đóng gói ứng dụng
Các ứng dụng SIP có thể được đóng gói với cùng cấu trúc của các ứng dụng
web. Chúng được đóng gói trong định dạng JAR cùng với phần mở rộng
là .sar (Sip archive) hoặc .war (web archive).
6.1.2.6 Mô tả triển khai (deployment descriptor)
Một bản mô tả triển khai trên nền XML thường được dùng để mô tả SIP
Servlet, các nguyên tắc để khởi tạo chúng cũng như các đặc tính về nguồn
tài nguyên và đặc tính môi trường được sử dụng trong ứng dụng. Bản mô tả
này nằm trong tập tin sip.xml và cũng giống như tập tin được sử dụng trong
HTTP servlet. Sip.xml được định nghĩa bởi một giản đồ XML.
110
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
6.1.2.7 Ngữ cảnh hội tụ và ứng dụng hội tụ (converged context –
converged application)
Một ứng dụng có thể sử dụng cả SIP Servlet và HTTP Servlet để tạo ra dịch
vụ. Để cho phép HTTP và SIP Servlet nằm trong cùng một gói ứng dụng,
đặc tả SIP servlet định nghĩa một đối tượng ConvergedContext. Đối tượng
này nắm giữ ngữ cảnh servlet chia sẻ bởi cả HTTP và SIP servlet và cung
cấp một tầm nhìn ứng dụng chung cho cả SIP và HTTP servlet trong các
khái niệm thuộc tính ngữ cảnh servlet, nguồn tài nguyên và JNDI
namespaces.
Khi một ứng dụng bao gồm cả SIP và HTTP servlet thì ứng dụng đó có thể
được hiểu là ứng dụng hội tụ. Điều này trái ngược với ứng dụng chỉ có SIP
được gọi là một ứng dụng SIP. Một ứng dụng hội tụ cũng tương tự như một
ứng dụng SIP về cấu trúc ngoại trừ nó có thêm tập tin web.xml như là một
bản mô tả triển khai thêm vào một tập tin sip.xml. Trong SIP Servlet API
1.1 (JSR289), khái niệm ứng dụng hội tụ có thể được mở rộng để bao hàm
cả các ứng dụng thương mại. Một ứng dụng thương mại có thể được gọi là
ứng dụng hội tụ.
6.1.2.8 Phiên SIP
Đặc tả SIP Servlet định nghĩa các đối tượng SipSession để thể hiện một
phiên thông qua SIP trong cùng một cách với HttpSession để thể hiện phiên
thông làm việc thông qua HTTP. Bởi vì một ứng dụng đơn như ứng dụng
hội tụ có thể thực hiện một phiên thông qua cả HTTP và SIP, đặc tả này có
thể định nghĩa SipApplicationSession là một đối tượng session ở mức ứng
dụng. Đối tượng SipApplicationSession có thể hoạt động như một lớp cha
với các phiên HTTP và SIP trong một ứng dụng. SipApplicationSession
phục vụ hai mục đích: cung cấp kho chứa dữ liệu cho ứng dụng và phối hợp
với một số protocol session.
111
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
6.2 Thiết kế dịch vụ
6.2.1 Yêu cầu
Thiết kế dịch vụ truyền hình nền ip sử dụng kiến trúc mạng IMS.
Dịch vụ cần có các chức năng:
o Phục vụ nội dung số tới người sử dụng trong mạng IMS sử dụng thiết
bị đầu cuối có cài đăt IMS client có chức năng IPTV.
o Có khả năng phân loại người dùng
o Phân loại nội dung số
o Danh sách chương trình nâng cao
o Quản lý quyền truy cập theo người dùng, thời gian và phân loại nội
dung.
o Có khả năng nhắn tin truy vấn quyền sử dụng.
Dịch vụ cần đáp ứng các yêu cầu:
o Có khả năng truyển tải các nội dung số đa dạng về mã hóa.
o Gửi các thông điệp thân thiện tới khách hang.
o Đảm bảo về bảo mật thông tin của kho nội dung số.
o Đảm bảo chất lượng nội dung số - thời gian phục vụ.
6.2.2 Kiến trúc hệ thống
Dịch vụ IMS based IPTV trong phạm vi đồ án được chia làm 2 modul lớn,
IPTV và Parental Control
Trong đó dịch vụ IPTV được xây dựng hướng đến người dùng phổ thông
có nhu cầu xem các chương trình truyền hình (Linear tv) và truyền hình
112
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
theo yêu cầu (Video on demand) cả trên di động lẫn trên tivi qua bộ thu
setop box.
Dịch vụ Parental Control hướng tới người dùng là vị thành niên hoặc trẻ
nhỏ chưa đủ 18 tuổi có nhu cầu tiếp cận với kho nội dung số, có chức năng
lọc nội dung truyền hình và Video on demand, phát theo giờ hoặc theo sự
chỉ định của cha mẹ (người dùng tham vấn – reference user)
Mô hình tổng quát:
HÌnh 6-43: Mô hình tổng quát dịch vụ IMS based IPTV
Chú thích:
Ims client, setopbox: là thiết bị đầu cuối truy cập dịch vụ
CSCFs: các thành phần thuộc mạng lõi IMS113
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HSS: server lưu trữ hồ sơ người dùng
Media server: server lưu trữ, điều khiển và truyền tải nội dung số
Application server: server xử lý các logic dịch vụ IPTv – cung cấp dịch vụ
IPTv
Sip: giao thức báo hiệu trong mạng IMS
RTP/RTSP: giao thức báo hiệu – truyền nội dung số
Diameter: giao thức chứng thực, cấp quyền và tính toán trong mang IMS.
• Việc nhận thực người dùng trong mạng do CSCFs thực hiện và quản lý
dựa trên hồ sơ người dùng lưu trữ tại HSS.
• Việc cung cấp nội dung số cho người sử dụng sẽ được Application
Server quản lý dựa trên hồ sơ dịch vụ mà người dùng đã đăng ký lưu trữ
tại HSS.
• Media server đóng vai trò là nguồn nội dung số mà Application server
lấy ra cho người sử dụng.
Server cung cấp dịch vụ (AS) được chọn là Sailfin v2.0 dùng công nghệ
Java EE làm nền tảng. Bao gồm các module:
• Các sip servlets phục vụ điều khiển phiên làm việc
• Các class hỗ trợ 1 số logic dịch vụ
• Database lưu trữ thông tin về các kênh như phân loại, đánh giá, mô tả
nội dung 1 kênh và giới hạn độ tuổi cho phép truy cập vào kênh đó.
• Web interface để quản lý và thiết lập cấu hình dịch vụ cũng như thông
tin về dịch vụ tới người dùng cuối.
Diameter client để tương tác với HSS trên giao diện Sh truy vấn các thông
tin về người dùng.
114
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Server cung cấp nội dung số (MRF) được chọn là Darwin Streaming Server
v5.5.5 truyền tải nội dung truyền hình cơ bản và HUT – Media Resource
Function truyền tải nội dung truyền hình theo yêu cầu dựa trên giao thức
RTP/RTSP. Bao gồm các module:
• Web interface để quản lý thiết lập các kênh linear tv
• Module stream manager
• Module báo hiệu điều khiển dựa trên giao thức SIP
User endpoint hay user agent hay terminal hay thiết bị đầu cuối có thể là di
động, setop box, hay máy tính để bàn, laptop…với điều kiện có IMS client
platform cài sẵn và hỗ trợ xem truyền hình dựa trên giao thức RTP/RTSP.
6.2.3 Thiết kế các lớp cho dịch vụ
6.2.3.1 Sơ đồ lớp
Dành cho gói user.profile
Đối với user profile, mỗi user có profile cho dịch vụ IPTV được định nghĩa
gồm có các kiểu dịch vụ đăng ký, các ràng buộc đối với 1 user trong đó có
reference user, các ràng buộc về thời gian và phân loại kênh. Lớp
RepDataHandler có nhiệm vụ lấy các thông tin trên của user từ profile
người dùng tải về từ HSS. Sau đó các user được đưa vào 1 danh sách phục
vụ là QueueLoggedUsers. Lớp TimeService dùng để thực hiện các thao tác
kiểm tra về thời gian
115
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 6-44: sơ đồ lớp cho gói user profile
Dành cho gói servlets
Gói này bao gồm các servlet thực hiện logic dịch vụ
116
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 6-45: Sơ đồ lớp gói servlets
Gồm có 5 servlet chính.
• Main servlet làm nhiệm vụ khởi tạo ban đầu các giá trị tham số cũng
như các dụng cụ sử dụng cho logic dịch vụ trong thời gian chạy ứng
dụng.
• IPTVdoSERVICE servlet làm nhiệm vụ nhận bản tin INVITE và xử
lý..
• IPTVdoLOGIN servlet làm nhiệm vụ nhận bản tin SUBSCRIBE và
xử lý
• MediaContentProvider servlet chuyên làm nhiệm vụ thực hiện những
yêu cầu INVITE đã qua xử lý và đã được chấp thuận.
117
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• IPTVdoMESSAGE servlet làm nhiệm vụ gửi nhận bản tin trong quá
trình quản lý truy cập.
Dành cho gói tools
Gói này có các lớp công cụ để xử lý các thành phần logic hoặc các công cụ
xử lý dữ liệu trong quá trình thực thi dịch vụ
HÌnh 6-46: Các lớp trong gói tools
Lớp Database tạo ra kết nối tới máy chủ dữ liệu.
Lớp Xmlhandler xử lý các yêu cầu liên quan tới Xml document.
Lớp StringManipulate xử lý các yêu cầu liên quan tới xâu chuỗi.
Lớp QueueAuthRequests lưu giữ các yêu cầu cần sự cho phép của người
dùng tham vấn.
118
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Lớp MediaContent đại diện cho 1 kênh, bao gồm thể loại, mô tả,
rating,...của kênh đó
Dành cho gói diameter
HÌnh 6-47: Sơ đồ lớp gói diameter
Lớp ShApp khởi tạo và duy trì kết nối tới máy chủ HSS
119
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Lớp ClientShSession quản lý luồng bản tin và tạo ra các bản tin diameter.
Lớp ShSessionEventListenerImpl nghe các trả lời từ HSS
6.2.3.2 Các khâu xử lý trong quá trình chạy dịch vụ
6.2.3.2.1 Cơ sở dữ liệu các kênh
Các thông tin về kênh – nội dung truyền hình và các user đã đang ký sẽ
được lưu trong máy chủ cơ sở dữ liệu bao gồm 2 bảng. Bảng
iptv_subscription chứa thông tin về các người dùng đã đăng ký dịch vụ.
Bảng iptv_media_source chứa thông tin về danh sách các kênh xem hiện tại
đang phục vụ. Nội dung các bảng như sau:
120
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
6.2.3.2.2 Khởi tạo dịch vụ
Lưu đồ thuật toán khâu khởi tạo dịch vụ:
121
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 6-48: Lưu đồ thuật toán khởi tạo dịch vụ
Khi dịch vụ được triển khai lên server ứng dụng, hàm init() trong servlet
Main.java sẽ được kích hoạt, khởi tạo module diameter và các biến, tham
số dùng cho dịch vụ.
6.2.3.2.3 Đăng nhập vào dịch vụ
Dưới đây là lưu đồ thuật toán đăng nhập vào dịch vụ
122
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 6-49: Lưu đồ thuật toán đăng nhập vào dịch vụ
123
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Lớp IPTvdoLOGIN.java mô tả cách thức đăng nhập người dùng bằng bản
tin SUBSCRIBE, nhận thực người dùng thông qua giao diện Sh giữa AS
và HSS và sau đó cấu trúc lên nội dung chương trình cho từng đối tượng
cụ thể rồi gửi về cho người dùng trong bản tin 200 Ok.
Chi tiết mã nguồn được để trong đĩa CD đính kèm tài liệu.
6.2.3.2.4 Thực hiện và xử lý yêu cầu đối với 1 kênh cụ thể
Lưu đồ thuật toán xử lý yêu cầu đối với 1 kênh:
124
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
HÌnh 6-50: Lưu đồ thuật toán xử lý yêu cầu kênh
Lớp IPTvdoSERVICE.java mô tả cách thức xử lý mỗi yêu cầu truy cập
vào 1 kênh cụ thể bằng bản tin INVITE. Kiểm tra xem người dùng đã
đăng nhập chưa, kênh yêu cầu có tồn tại hay không và là yêu cầu truyền
hình cơ bản hay là Video on demand, người dùng có phải thuộc diện quản
lý truy cập hay không… và phục vụ với chức năng tương ứng
125
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Chi tiết mã nguồn được để trong đĩa CD đính kèm tài liệu.
6.2.4 Kịch bản thực thi ứng dụng
Sip.xml là file định nghĩa các lớp SIP servlet và chỉ ra các ánh xạ của chúng.
Các ánh xạ cho Sip Servlet sử dụng các toán tử “and”, “equal”, và “not” để
định nghĩa ra các điều kiện trong đó servlet được kích hoạt.
6.3 Cài đặt và sử dụng dịch vụ
6.3.1 Yêu cầu hệ thống
Yêu cầu về phần cứng:
• Máy tính để bàn có cài đặt hệ điều hành Unix (tốt nhất dùng
Ubuntu phiên bản 8.04 trở lên).
• Đường truyền ADSL hoặc các thiết bị trong mạng LAN.
Yêu cầu về phần mềm:
• Linux có kernel 2.6.
• Máy tính có cài đặt Sailfin với đầy đủ thư viện.
• Hut - Communicator
6.3.2 Hướng dẫn cài đặt
Xem phụ lục kèm theo.
6.3.3 Kết quả thu được
Xem phụ lục kèm theo.
126
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
KẾT LUẬN
Trong thời đại ngày nay, Internet có vai trò ngày càng quan trọng trong lĩnh vực
viễn thông, chính vì vậy IMS – sự kết hợp giữa điện thoại di động truyền thống và
mạng internet hứa hẹn sẽ đem lại nhiều lợi ích cho cả người sử dụng lẫn nhà cung
cấp dịch vụ. Trong thời gian thực hiện đồ án, dưới sự tận tình của TS. Nguyễn Tài
Hưng cùng sự giúp đỡ chia sẻ của các bạn trong nhóm. Em đã nắm được những
kiến thức về kiến trúc IMS và hiểu cách phát triển các dịch vụ mới trên nền kiến
trúc IMS.
Trong đồ án, em đã tiến hành xây dựng các lược đồ báo hiệu và điều khiển trong
các trường hợp khác nhau của dịch vụ IPTV, và bước đầu đi vào triển khai dịch vụ
trong các trường hợp đơn giản đến phức tạp. Tuy nhiên bên cạnh những mặt thuận
lợi và những gì đã đạt được là những khó khăn, những nhược điểm:
• Đó là sự thiếu kinh nghiệm trong lập trình dẫn đến việc phát triển
nâng cao hệ thống còn nhiều hạn chế.
• Vấn đề bảo mật chưa được quan tâm nhiều.
• Hệ thống mới chỉ phát triển trong mạng nội bộ chứ chưa đưa ra được
ngoài mạng internet công cộng.
• Dịch vụ đa phần chỉ dừng lại ở mức nghiên cứu lý thuyết, thực hiện
mô phỏng chứ chưa đi vào thực tế.
Tuy nhiên, với sự nỗ lực hết mình của cá nhân và sự giúp đỡ nhiệt tình của các thầy
giáo và các bạn, em tin rằng trong thời gian tới sẽ có thể tiếp tục nghiên cứu và phát
triển dịch vụ hoàn thiện hơn. Đồng thời tiến tới xây dựng được nhiều dịch vụ ứng
dụng phục vụ cho người sử dụng và đem lại nhiều lợi ích cho các nhà cung cấp dịch
vụ.
127
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
PHỤ LỤC
1. Poster paper gửi tại hội nghị TridentCom – Berlin
IMS IPTV: An Experimental Approach
Nguyen Tai Hung, Nguyen Huu Thanh, Giang Ky Nam, Bui Quang Anh, Dinh Thai Hoang
Department of Communication Engineering Hanoi University of Technology{hungtaifet, thanhnh}@mail.hut.edu.vn
Abstract. IMS has been widely recognized as the control and signaling framework for delivering of the rich communication & multimedia services to broadband users. Amongst others, it’s deploying as the service (middleware) platform for interactive and personalized IPTV services. The goal of this paper is to provide a short description and analysis of the (IPTV) use cases that have been selected for design and implementation at Hanoi University of Technology (HUT) in scope of its initiatives for NGN researching program. Major use cases, or we called intelligent features, are the advanced electronic service guide, video on demand (VoD), (IPTV) session continuity, and parental control. Development results for each of the use case are depicted.
Keywords: IMS; IMS IPTV; enhanced EPG; Parental Control; Blending Service, Intelligent Features;
1. Introduction
IP Multimedia Subsystem (IMS) is a next generation network (NGN) architecture currently planned for mobile and fixed multimedia services, standardized by the 3rd Generation Partnership Project (3GPP) [1]. IMS promises a scalable integrated platform that enables new services and provides for the combination of telecommunications and Internet services, therefore, we have chance of using IMS to provide a highly integrated solution for seamless, networked-based media transportation over any end-user device. Since the IPTV had been developed and deployed for some time and had gone through numbers of generation with different middleware technologies. It’s now facing the challenges of the market which demands that IPTV must be equipped with more intelligent and interactive features in a standardized & interoperable way. This paper therefore will explore, in experimental perspective, the possibility of application of the IMS framework as the service control plane to provide the interactive and personalized Video services. The paper begins with a concise description of the novel IMS based IPTV architecture as well as our setup for an academic IMS Test-bed. The main part of the paper will be reserved for presentation of IPTV use cases that we have developed in our test-bed environment. Six use cases have been selected for design and implementation as listed below.
• Standard Video on Demand• Parental Control/Authorization: An intelligent feature that allows the parent to control their children
access to (IPTV) broadcast channels and/or on-demand contents.
• Enhanced EPG: Another feature that provides the (IPTV) viewers with personalized program guide
• Blending services [8]: a feature that allows the composition of telephony/messaging session with IPTV session.
128
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Sharing IMS profiles in the same device and IPTV application examples: Usage of several IMS profiles on a device when several users are sharing the same device
• Session transfer: A rich multi-device and multimodal interaction model that allows the user to start up a session of a converged service while commuting on the train, continue the interaction while walking to his office and complete the transaction while sitting down at his office-desk.
2. IMS Based IPTV Architecture
Novel Framework
Fig. 1. IMSbased IPTV
Figure-1 shows a high-level functional IPTV network architecture being supported by an IMS infrastructure. The model provides multimedia services to the end user by means of the SIP Application Server (SAS). The SAS implements the SIP server with which users interact and request the movies or other online contents and, more importantly, inclusive of advanced functionalities like the personalized electronic service guide (ESG), interactive (parental) authorization, blending sessions, etc. The SAS interacts with the IPTV User Terminal (IUT) that handles the display and interactivity functions for viewers. The IUT also performs functions such as content encoding/decoding and buffering for both unicast and multicast streams. The system is divided into a number of logically separated parts, namely, the home network, access network, aggregation network, and the service/content domain.
IPTV User ProfileIn the IMS IPTV architecture, personalization is an important feature. To achieve personalization at the
application level (i.e. personalized EPG’s, advertisements, or even personalized blended communication services), every user has an IPTV profile. The relation between the IPTV profile and the IMS profile depends on the availability of a home IMS gateway. The home gateway is a functional block with an attached ISIM card reader, which can be deployed in the residential gateway or any other networked consumer equipment. The gateway translates home signaling, whether SIP, UPnP or perhaps pure HTTP to IMS signaling. It also takes care of NAT traversal and secures connectivity with the P-CSCF in the IMS domain, as well as identity, device subscription, and management inside the home domain and towards the IMS core.
If the household contains a home gateway, the family members can choose whether they want to have full IMS identity, one which enables them full communication capabilities supported by IMS, or they opt to just have an IPTV profile, that will use the default IMS household identity for authentication purposes. The IPTV profile information that needs to be shared between different IMS services is stored in the IPTV XDMS database. This database is accessed using XCAP, which works over HTTP. These profiles can be shared by different users and other stakeholders within the IPTV system.
129
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Our Testbed
In the scope of the joint-research project between Hanoi University of Technology and Fraunhofer Institute FOKUS, we was setting up a next generation Test-bed in our lab for purpose of prototyping of new multimedia and rich-feature communication services using IMS framework. The test-bed consists of all three layers: media layer for transportation of media traffic in the modes of unicast, multicast and broadcast. The core layer of signaling and session/service control uses the FOKUS’ open source IMS Core [3][4][5] that delivers CSCF servers and a light user profile database (HSS). Our project main focus is on the application layer in which we specified and developed prototypes for value added services to IP Telephony and IP Television using the Sailfin platform. A Media Server was also developed at our lab using VLC (VideoLAN) media stack. Besides that we had developed a comprehensive framework and prototype of IMS IPTV Client that based on the open source IMS Communicator. Finally, several IMS interfaces, namely, Sh, Mw, etc are implemented on our own effort. Figure 2 depicts high level view of our Test-bed setup.
Fig. 2. The HUT Next Generation Test-bed
3. IMS IPTV Use Cases
3.1. Message Flow
Standard Video on Demand
130
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
UE (emulated STB)CSCFs IPTV AS IMS MRF
RTP
INVITE
sip:[email protected] INVITE
183 Session Progress183 Session Progress
183 Session Progress
ACK
BYEBYE
BYE
200 OK
200 OK
200 OK
200 OK
200 OK
ACKACK
200 OK
Fig. 3. Requesting the on-demand contents
In our research, as depicted on figure 3, we consider a scenario in which an IMS user initiates a call to a specific content (a movie, a song or other resources) at the content provider through an IMS domain. The request would be routing through different SIP servers (CSCFs) and at S-CSCF a suitable iFC would be invoked to forward the request to IPTV AS, the AS will then proxy the request to MRF (Media Server). Media Server, after accepting the request, will send back the successful responses (via AS) as well as the RTP streams directly to Emulated STB. In our scenario, we had implemented the AS based on Sailfin platform and our Media Server was designed and implemented using VLC (VideoLAN) RTP stack and oSIP library.
Parental Control
`
Peter CSCFs AS Alice
INVITEsip:[email protected]
INVITEsip:[email protected]
Permission Resquest Message
Permission Resquest Message
Answer: Decline
Answer: Decline
Decline Message
Decline Message
603 Decline
603 Decline
Acess Control Decision
Fig. 4. IPTV Parental Control Feature
A special feature, called Parental Control, had been designed and implemented which allows the parent to control their child from requesting and viewing classified contents. In this scenario, as shown on the figure 4, the child (Peter) initiates a call to a specific content (movie and channel), the request will be forwarded to IPTV AS through IMS Core, the AS, through the in-house developed Sh interface, will download and check the service registration of this user and learnt that this user need the permission (from his parent) in order to view the requested content. The AS then checks the status of Parent (Alice) through Presence service and asks for her permission (via Message method). Depend on the response from Alice, whether she accept or
131
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
deny the request, IPTV AS will either send back to Peter the denial response (603 Decline) or proxy the request to Media Server which will subsequently send RTP stream to Peter’s Client.
Enhanced EPG Personalization is a key feature in the IMS IPTV solution. In this sense, we have complemented the user
profile with a new XML-formatted [9] service profile for each IMS identity to contain the personalized information. That leads to another intelligent feature for IMS-based IPTV, we called Enhanced EPG. With this feature user will be classified in to different groups (via subscription) with different service levels.
UE CSCFs AS HSS
SUBSCRIBEsip:[email protected]
SUBSCRIBEsip:[email protected]
User Data Request
User-Id: [email protected] Reference: ifc
User Data Answer
Ifc Attached
200 OK
200 OK
Channel list
If no acess controlConstruct the list of channel
Channel list
Fig. 5. Message Flow for EPG of uncontrolled access
UE CSCFs AS
SUBSCRIBEsip:[email protected] SUBSCRIBE
sip:[email protected] Data Request
User-Id: [email protected] Reference: ifc
User Data Answer
Ifc Attached
Acess control required
User Data Request
User-Id: [email protected] Reference: Repository Data
User Data Answer
Peter’s Repository Data Attached
Construct channel list Add access control to session
200 OK200 OK
Channel listChannel list
Fig. 6. Message flow for Enhanced EPG Feature
In this scenario, users in different classes, after registering in to the IMS Core, will send Subscribe request to IPTV AS for the EPG service. The AS then, via Sh interface, will query the HSS to download the relevant iFC and check the registered service profile of requesting user, if user is belonging to the free service package (no need access control) then AS will build the relevant channel list and send it, through the payload (in XML) of 200 OK Response message, back to the requesting user. In the other hand, if user is belonging to the group that need access control (e.x. for Premium service packages) then the AS need to query the HSS
132
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
again to obtain the necessary data to build the suitable channel list and send back to the requesting user. Figure 5&6 below show the basic message exchanges for implementation of these two scenarios. The access control also provides the time constrained service profile in which the requesting for different time slots will receive different channel lists.
Session ContinuityThe issue of session continuity is also studied in our test-bed, in which we investigated a new approach that allows handing over of an on-going IPTV session between different access heterogeneous environments. We propose a new component in the IMS domain, namely an proxy based on mSCTP (mobile Stream Control Transmission Protocol) that acts as an anchor point for soft vertical handover of mobile nodes, which have multiple physical interfaces (e.g., WLAN/UMTS). The mSCTP-based proxy also supports QoS provisioning and adaptation for the mobile nodes when moving in a heterogeneous wireless environment. Our simulation results show that the signaling cost for handover in our approach can be up to 23 times smaller than that in the conventional approach.
MN P-CSCF I-CSCF S-CSCF proxy AS
305 use proxy
INVITE(mSCTP)INVITE
INVITE(mSCTP) INVITE(mSCTP)INVITE(mSCTP)
INVITE(mSCTP)INVITE(mSCTP)
INVITE(mSCTP)100 trying
100 trying100 trying
183 sp183 sp183 sp
183 sp183 sp
PRACKPRACK
PRACKPRACK
MN PDP Context Activation 200 OK
200 OK
proxy PDP Context Activation
AS PDP Context Activation
200 OK200 OK
Visited IMS Domain 1 Home IMS Domain
REFER (AS)
200 OK
MN P-CSCF I-CSCF S-CSCF proxy AS
305 use proxy
INVITE(mSCTP)INVITE
INVITE(mSCTP) INVITE(mSCTP)INVITE(mSCTP)
INVITE(mSCTP)INVITE(mSCTP)
INVITE(mSCTP)100 trying
100 trying100 trying
183 sp183 sp183 sp
183 sp183 sp
PRACKPRACK
PRACKPRACK
MN PDP Context Activation 200 OK
200 OK
proxy PDP Context Activation
AS PDP Context Activation
200 OK200 OK
Visited IMS Domain 1 Home IMS Domain
REFER (AS)
200 OK
UPDATEUPDATE
180 ringing180 ringing
180 ringing180 ringing
180 ringing
PRACKPRACK
PRACKPRACK
200 OK200 OK
200 OK200 OK
UPDATE
200 OK200 OK
200 OK200 OK
UPDATE
200 OK200 OK
200 OK200 OK200 OK ACK
ACKACK
ACKACK
mSCTP connection between MN and proxy
TCP/UDPconnectionproxy <> AS
UPDATEUPDATE
180 ringing180 ringing
180 ringing180 ringing
180 ringing
PRACKPRACK
PRACKPRACK
200 OK200 OK
200 OK200 OK
UPDATE
200 OK200 OK
200 OK200 OK
UPDATE
200 OK200 OK
200 OK200 OK200 OK ACK
ACKACK
ACKACK
mSCTP connection between MN and proxy
TCP/UDPconnectionproxy <> AS
Fig. 7. mSCTP connection setup between MN, proxy, AS and other components in IMS
After registering with a network, let’s say the visited IMS domain 1 as illustrated on Figure 7, the MN wants to initiate a call to an IPTV Application Server. At this moment the MN does not know the existence of an mSCTPbased proxy, thus it sends an INVITE message with the URI of the service identity (PSI). Since the MN supports mSCTP in the transport layer, it would like to set up an mSCTP connection if possible. In our implementation, instead of sending an INVITE message informing that the expected transport protocol is TCP or UDP, mSCTP is specified in the INVITE message on the VIA header field. Upon receiving the INVITE message, the home SCSCF analyses the message and realizes that the MN requests mSCTP. Instead of forwarding INVITE to the AS, the home SCSCF sends a redirect message “305 use proxy” to the MN,
133
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
which specifies the URI of the mSCTPbased proxy in the Contact field. The MN then sends INVITE to the proxy, requesting to build an mSCTP transport session between the MN and the mSCTPbased proxy. When the home SCSCF process the redirected INVITE message from the MN, it will also send a REFER to the proxy instructing it to establish a session from the proxy to the AS.Following INVITE messages are QoS provisioning steps. These steps are much like the conventional signaling flow, except that the proxy should set up two sessions: one between MN and the proxy with mSCTP tunnel, and the other between the proxy and the AS. There are three PDP contexts that should be established for the MN, proxy and AS. The session setup procedure in our approach is a bit more complex than usual with 66 messages. In Figure 7, we neglect some messages that do not play significant role in the signaling flow.
3.2. Results
This section highlights some of the various intelligent features implemented in the prototype at our Test-bed. Figure 8 illustrates a personalized user portal which provides a different content meta data (channel list) to different registered user. Figure 8 shows the Parental Control feature in which the child’s request (for a specific online content, like movie) will be accepted or rejected based in different criteria like the acceptance from the parent, the time slot of the request and the category of the requested content.
Fig. 8. Channel List for different User Categories of Enhanced EPG feature
134
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Fig. 9. Incoming Call/Message Display
Figure 9 shows feature of blending services that allows displaying the Incoming Call/Message from buddies on the online TV screen if the watching user is not on the “Do not Disturb” mode. The viewer then has options of pausing the TV session to handle the incoming call/message or reject it. Finally, figure 10 shows our proposed architecture for the implementation of (IP TV) session continuity.
Visited IMS domain 2 - WLANVisited IMS domain 1 - UMTS
Home IMS domain
GGSN PDG
AP
P-CSCF
I-CSCF
HSS
GGSN
S-CSCF
AS
MN
mSCTPProxy
P-CSCF
Data path
Signaling path
RNC
Visited IMS domain 2 - WLANVisited IMS domain 1 - UMTS
Home IMS domain
GGSN PDG
AP
P-CSCF
I-CSCF
HSS
GGSN
S-CSCF
AS
MN
mSCTPProxy
P-CSCF
Data path
Signaling path
RNC
Fig. 10. Signaling paths and data paths between MN, mSCTP proxy, AS and IMS components
4. Conclusions and Further Discussions
This paper presents our investigation, in experimental perspective, of using IMS framework to provide intelligent features for IPTV services. In particular, it focuses on the video on demand, remote parental control, blending services, session handover without interruption and other interactive features which some of the use cases were discussed and presented here-above. It shows how SIP [2][7] signaling and IMS can be used to provide the Interactive and Blending features for the entertainment video services.
135
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
The initial results promise the great potential of those IMS-based TV interactive and differentiated features, which offer attractive and rich multimedia experiences to the end user. We are currently investigating and developing several other intelligent features of IMS-based TV, namely, the context-based session continuity that allows to seamlessly handover the IPTV sessions across different screens/terminals on different access networks
2. Cài đặt Open IMS Core lên UbuntuBước 1: Download Open IMS Core về máy
sudo su (sau đó nhập pass của root để vào quyền root)
apt-get install subversion
mkdir /opt/OpenIMSCore/
chown –R username /opt/OpenIMSCore/
cd /opt/OpenIMSCore
mkdir ser_ims
mkdir FHoSS
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk
ser_ims
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk
FHoSS
Bước 2: Cài đặt các gói yêu cầu
apt-get install sun-java6-jdk mysql-server libmysqlclient15-dev libxml2
libxml2-dev bind9 ant flex bison
Sau đó thiết lập pass cho sql (mysql root password imshut)
Bước 3: Cài đặt DNS
Edit /etc/dhcp3/dhclient.conf và bỏ comment tại dòng:
prepend domain_name_servers 127.0.0.1;
136
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
cp /opt/OpenIMSCore/ser_ims/cfg/open-ims.dnszone /etc/bind/
Thêm dòng này vào file sau: /etc/bind/named.conf.local
zone "ims.hut.vn" {
type master;
file "/etc/bind/open-ims.dnszone";
};
Cấu hình file open-ims.dnszone thay thế địa chỉ IP
/etc/init.d/bind9 restart
Bước 4: Biên dịch
cd /opt/OpenIMSCore/ser_ims
make install-libs all
java –version (để kiểm tra phiên bản của java)
export JAVA_HOME="/usr/lib/jvm/java-6-sun-1.6.0.03/" (tùy theo phiên
bản ubuntu của người dùng, trong câu lệnh trên là ubuntu 7.10).
cd /opt/OpenIMSCore/FHoSS
ant compile deploy
Bước 5: Thiết lập cơ sở dữ liệu và chạy
cp /opt/OpenIMSCore/ser_ims/cfg/* /opt/OpenIMSCore/
cd /opt/OpenIMSCore
Thay đổi tên miền của IMS core (fresh install) (ims.hut.vn)
./configurator.sh pcscf.cfg icscf.cfg icscf.xml scscf.cfg scscf.xml
ser_ims/cfg/icscf.sql FHoSS/deploy/DiameterPeerHSS.xml
FHoSS/deploy/hss.properties FHoSS/scripts/hss_db.sql
FHoSS/scripts/userdata.sql
137
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Thiết lập cơ sở dữ liệu
mysql -uroot -p < ser_ims/cfg/icscf.sql
mysql -uroot -p < FHoSS/scripts/hss_db.sql
mysql -uroot -p < FHoSS/scripts/userdata.sql
Mở terminal và chạy:
./pcscf.sh
./icscf.sh
./scscf.sh
cd FHoSS/deploy
./startup.sh
Nếu gặp vấn đề khi chạy FHoSS thì thiết lập lại biến môi trường
JAVA_HOME bằng cách gõ lại dòng lệnh sau:
export JAVA_HOME="/usr/lib/jvm/java-6-sun-1.6.0.03/"
3. Cài đặt máy chủ ứng dụng sailfin• Yêu cầu tối thiểu để cài đặt là máy phải có jdk1.5 trở lên.
• Download phiên bản miễn phí của sailfin (v1.0 final release)
• Giải và tạo thư mục mới sailfin bằng cách thực hiện lệnh:
% java –Xmx256m –jar filename.jar
• Chuyển đến thư mục sailfin:
% cd sailfin
• Nếu sử dụng máy tính với các hệ điều hành có phân quyền như Unix
thì thực hiện cấp quyền thực thi cho các thư mục bin và sailfin:
138
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
% chmod –R +x lib/ant/bin
• Tiến hành cài đặt:
o Cho Linux:
% lib/ant/bin/ant –f setup.xml
o Cho Window:
% lib\ant\bin\ant –f setup.xml
4. Cài đặt dịch vụ IPTV lên máy chủ Sailfin
Provisioning FHoSSXem: “Kịch bản demo dịch vụ IPTv”
Povisioning content databaseTại dấu nhắc người dùng gõ lệnh:# mysql –uroot –p < iptv_db.sqlEnter password:# mysql –uroot –p < iptv_media_source.sqlEnter password:
Povisioning Diameter PeerCopy file clientForJ.xml tới thư mục /path/to/sailfin/domains/domain1/config/ Copy toàn bộ các file trong thư mục Libs/diameter/ tới thư mục /path/to/sailfin/domains/domain1/libs/ext/Sửa lại các tham số địa chỉ IP trong file clientForJ.xml cho đúng với hệ thống.
Povisioning User RepositorySử dụng phần mềm DiameterClient, tại terminal gõ lệnh:# java –jar diameterClient.jar upload /path/to/shdata.xml sip:[email protected] iptv
Cấu hình máy chủ IPTVKhởi động Sailfin:#asadmin <enter>#asadmin> start-domain --user admin domain1
Login to administration console at http://localhost:4848139
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
User: adminPassword: adminadmin
Tạo JDBC Resources cho MySQL(để kết nối tới máy chủ MySql)
Tải về connector của MySql cho java tại đây MySQL Connector/J .
Copy file mysql-connector-java-5.1.7-bin.jar tới thư mục <sailfin installation dir>/domains/sailfin-cluster-domain/lib/ext và khởi động lại máy chủ Sailfin như trên (asadmin stop-domain <name> followed by asadmin start-domain <name>).
Trong trang chủ quản lý của Sailfin, vào phần
JDBC Connection Pool
Click vào Connection Pools để tạo 1 JDBC Connection pool mới.
140
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Ấn vào new
Thiết lập tham số: jdbc:mysql://iptv.ims.hut.vn:3306/iptv_db?user=nhong&password=nhong
Ở đây ‘nhong’ là tải khoản truy cập vào mysql server.
141
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Click Finish sau đó chọn lại MySQLPool để kiểm tra xem nó có hoạt động không.
142
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Click Ping.
143
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Thành công.
144
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Cài đặt dịch vụ:
Trong panel bên trái click vào Converged SIP
145
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Click deploy, specify chọn file fet_iptv.war và click ok.
Xong!
146
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
5. Chạy thử với HUT - CommunicatorXem: “Kịch bản demo dịch vụ IPTv”
Kịch bản đê mô dịch vụ IMS based IPTV
Ngữ cảnh:• Có 2 User đăng ký dịch vụ IPTv, 1 là Alice và 2 là con gái của cô, Alice’s
daughter• 2 người đăng ký chung 1 thuê bao IMS có tên là Alice.• Alice đăng ký 1 private user identity là [email protected] và 1 public user
identity kèm theo nó là sip:[email protected].• Con gái của cô Peter được Alice đăng ký 1 private user identity là
[email protected] và 1 public user identity kèm theo là sip:[email protected].
• Việc này được thực hiện thông qua trang cấu hình của FHoSS (HSS provisioning):
Thiết lập dịch vụ Iptv và Parental control:• Tạo Iptv-parental control server:
147
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Tạo Iptv trigger point:
• Tạo Iptv IFC:
• Tạo Iptv service:
148
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
• Tương tự với Parental control:
149
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Như thế chúng ta đã tạo xong 2 gói dịch vụ, 1 là Iptv và gói kia là Parental control, user sử dụng gói Iptv sẽ được xem tất cả các kênh mà IPtv server cung cấp còn user sử dụng dịch vụ Parental control thì chỉ được phép xem 1 số kênh nhất định, nếu yêu cầu xem các kênh ko cho phép server sẽ gửi tin nhắn hỏi quyền truy cập từ 1 user khác.
Sau đây là thiết lập 2 user nói trên với các gói dịch vụ tương ứng: Alice sử dụng dịch vụ Iptv còn con gái cô ấy được đăng ký dịch vụ Parental control. Cả 2 mẹ con đều đăng ký chung 1 IMS subscriber.
150
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
151
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Và chúng ta có subscriber ‘Alice’ như sau :
Với user Alice có sẵn của FHoSS ta sửa lại service profile của user này thành iptv:
Hoạt độngBây giờ chúng ta mở 2 client, 1 client đăng ký với tên Alice và 1 đăng ký với tên Peter, ở đây 2 user được đăng ký trong HUT Communicator
152
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Danh sách chương trình của User Alice:
Và danh sách chương trình của user Peter:
153
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Danh sách chương trình của user Alice dài hơn và bao gồm cả nhưng kênh người lớn.
Alice xem 1 kênh truyền hình:
154
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Peter truy cập vào 1 kênh thuộc diện phải quản lý: hệ thống gửi tin nhắn tới Alice hỏi xem có cho phép hay không.
155
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Alice từ chối:
156
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Peter truy cập vào 1 kênh khác và lần này Alice cho phép con bà ta xem:
157
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
Và kết quả:
158
Thiết kế và triển khai dịch vụ IPTV trên nền IMS
Khoa điện tử viễn thông - Đt4 K50
Giang Kỳ Nam
TÀI LIỆU THAM KHẢO
[1] Gonzalo Camarillo & Miguel A.Garcia-Martin, The 3G IP Multimedia
Subsystem Merging The Internet And The Cellular Worlds, Second Edition, John
Wiley & Sons, Ltd, 2006.
[2] Alan B.Johnston, SIP: Understanding the session initiation protocol, second
edition, Artech House telecommunications library, 2004.
[3] Miikka Poikselkä and Georg Mayer, The IMS: IP Multimedia Concepts and
Services, Second Edition, Hisham Khartabil and Aki Niemi © 2006 John Wiley &
Sons, Ltd. ISBN: 0-470-01906-9
[4] Rfc 3725, Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP)
[5] 820-4281, SunGlassFish Communications Server 1.5 AdministrationGuide,
SunMicrosystems, Inc. 4150Network Circle Santa Clara, CA 95054 U.S.A.
[6] Presence, Vishal Kumar Singh and Henning Schulzrinne April 10, 2006,
Columbia Computer Science.
[8] Rfc 3327, Session Initiation Protocol (SIP) Extension Header Field
[9] http://www.iptel.org
[10] http://tech-invite.com
[11] http://uctimsclient.berlios.de
[12] https://sailfin.dev.java.net
[13] http://blogs.sun.com/enterprisetechtips/entry/adding_voice_to_java_ee
[15] http://blogs.voxeo.com/speakingofstandards/tag/sipoint/
159