Hai thành phần quan trọng của một dịch vụ true VOD là dịch vụ di động và phiên di động. Dịch vụ di động đề cập đến khả năng truy cập một dịch vụ từ các thiết bị khác qua sử dụng các mạng truy cập khác nhau. Dịch vụ di động True cũng yêu cầu chuyển vùng, tức là không chỉ cho phép các phương pháp truy cập khác nhau cho người sử dụng thiết bị khác nhau, mà còn cho phép các UE và để kết nối thông qua mạng lõi IMS quản lý bởi các nhà khai thác khác.
Chương 3
Phiên di động là tắnh năng cho phép người dùng kết thúc việc xem các video giữa các phiên và sau đó tiếp tục xem từ cùng một vị trắ bằng cách sử dụng một UE. Điều này có nghĩa rằng thời gian hiện tại (thiết lập) trong bộ phim cần phải được lưu trong mạng khi chấm dứt phiên ban đầu, cho phép các MF để bắt đầu streaming bộ phim từ các ô đã lưu thiết lập khi bộ phim được phát trên các thiết bị của người dùng kế tiếp.
Hình 3.10. Bản ghi dữ liệu hoạt động dịch vụ IPTV
3.6.4. Tràn tắn hiệu
Kiểu VOD điển hình được bắt đầu khởi tạo với dịch vụ, tiếp theo là phiên giao dịch, kiểm soat dòng và phân luồng. Phiên có thể sửa đổi trên đường đi. Nó kết thúc với một phiên. Phần này trình bày một mô tả các cấp cao của bước này.
Thủ tục đầu tiên là khởi tạo dịch vụ VOD, bao gồm các bước mô tả trong hình vẽ sau đây:
Chương 3
Hình 3.11. Các bước khởi tạo
Lúc khởi động, bước đầu tiên của UE là để thực hiện một tập tin đắnh kèm mạng. Điều này liên quan đến việc giao tiếp với các tập tin đắnh kèm mạng NASS. Hai bộ phận quan trọng của các tập tin đắnh kèm mạng:
1. Có được một địa chỉ IP.
2. Nhận được một địa chỉ P-CSCF.
Một địa chỉ IP có thể được tự động nhận được thông qua Giao thức điểm Ờ điểm (PPP) hoặc DHCP], trong khi P-CSCF nhận thức về địa chỉ có thể được lấy tại một trong các cách:
1. UE có thể được cấu hình sẵn với một địa chỉ P-CSCF.
2. Các UE có thể nhận được địa chỉ P-CSCF từ NASS như là một phần của tập tin đắnh kèm mạng.
Nếu địa chỉ P-CSCF thu được là một Fully Qualified Domain Name (FQDN) hơn là một địa chỉ IP, các UE sẽ cần phải có được một máy chủ DNS địa chỉ IP của NASS (hoặc được cấu hình sẵn với một) để được có thể giải quyết địa chỉ IP của P-CSCF. Sau đắnh kèm mạng IMS đến đăng ký. Sau khi đăng ký thành công, các UE đã được xác thực và ủy quyền để giao tiếp với các thiết bị người dùng khác trong mạng IMS cũng như với các máy chủ ứng dụng. Bước tiếp theo là để thực sự khởi tạo dịch vụ VOD. Điều này được thực hiện thông qua một file đắnh kèm dịch vụ quy trình VOD, trong đó có hai phiên bản khác nhau:
Chương 3
Ớ Phần đắnh kèm dịch vụ VOD chế độ kéo.
Ớ Phần đắnh kèm dịch vụ VOD chế độ đẩy.
Theo dự kiến, chế độ kéo có nghĩa rằng các tập tin đắnh kèm dịch vụ được khởi xướng bởi UE, trong khi chế độ đẩy cho thấy các hoạt động do SDF khởi tạo. Các chế độ đẩy có thể hiệu quả hơn, vì nó không gọi cho một UE hoàn thành - SDF - UE khứ hồi (SDF có thể có được tình trạng UE thông qua S-CSCF). Tuy nhiên, nếu đăng ký với IMS UE chỉ sử dụng một số dịch vụ khác không phải IPTV, một SSF lựa chọn không cần thiết sẽ được thực hiện và VOD dịch vụ thông tin sẽ được gửi đến UE, mặc dù nó sẽ không bao giờ được sử dụng.
Hai phương pháp kéo và đẩy được thể hiện trong hình 3.12 và 3.13 dưới đây:
Chương 3
Hình 3.13. Dịch vụ kèm theo sử dụng chế độ đẩy
Khởi tạo phiên được mô tả như trong hình vẽ sau đây:
Chương 3
Sau khi nhận được thông tin dịch vụ VOD, là một địa chỉ SSF cùng với những thông tin bổ sung cần thiết để xây dựng một yêu cầu cho một danh mục VOD, các địa chỉ UE ánh xạ lên SSF để có được danh mục này. SSF sau đó trả về dữ liệu yêu cầu, và các UE có thể trình bày thông tin cho người sử dụng để cho phép người dùng thực hiện lựa chọn và bắt đầu một phiên.
Phiên khởi tạo:
Phiên khởi tạo luôn được bắt đầu bởi UE. Các dòng tắn hiệu cơ bản của phiên khởi tạo được thể hiện trong hình 3.14. Việc phiên khởi tạo đi qua mạng lõi IMS, trong đó các tuyến theo yêu cầu để các SCF đúng bằng IFC từ UPSF. SCF Các uỷ quyền chăm sóc và lựa chọn một MCF thắch hợp để hành động như là điểm khác cấp phương tiện truyền thông kiểm soát (UE là người đầu tiên) trong phiên này. MCF lần lượt, có trách nhiệm lựa chọn một MDF.
Khi nhận được một phiên khởi tạo thành công, các mạng lõi IMS tương tác với các tài nguyên và kiểm soát cổng vào hệ thống con (RACS) (không được hiển thị ở đây) để đảm bảo rằng một lượng thắch hợp của băng thông được dành riêng cho phiên này. Phiên thay thế. Trong một phiên hoạt động, các tham số phiên có thể sẽ thay đổi. Nếu thay đổi điều kiện truyền dẫn, điều này dẫn tới 1 yêu cầu truyền 1 user tốt hơn. Yêu cầu này có thể được bắt đầu 1 phiên thay thế của UE cũng như MF. Các dòng tắn hiệu cơ bản của phiên thay thế được thể hiện trong hình dưới đây:
Chương 3 Phiên kết thúc:
Phiên này có thể được kết thúc bởi UE (Hình 3.16), các SCF (Hình 3.17) hoặc các MCF (Hình 3.18). Lý do cho một phiên SCF kết thúc bắt đầu có thể là một UE đã đăng ký cùng phiên khởi tạo. Điều này đơn giản có nghĩa là người sử dụng muốn tiếp tục xem trên một thiết bị khác được đưa ra ngay khi phiên kết thúc yêu cầu đến mạng lõi IMS thông qua giao tiếp giữa các P-CSCF và các RACS.
Hình 3.16. UE bắt đầu kết thúc phiên
Chương 3
Hình 3.18 MF bắt đầu kết thúc phiên
3.7. Thiết kế lược đồ truyền tắn hiệu cho VOD dựa trên IMS - NGN
Trong chương này, sẽ nghiên cứu về các thủ tục được trình bày trong mục 4.3.4
tràn tắn hiệu ở mức chi tiết hơn. Đây là cấp độ mới về chi tiết cụ thể bao gồm giao thức và quyết định những loại tin nhắn được phù hợp. Một số giao thức đã ngụ ý bởi các điểm tham chiếu được sử dụng trong định nghĩa của TISPAN và định nghĩa của họ trong IMS. Các giao thức liên quan và nhiệm vụ của chúng được thể hiện trong bảng 3.
Bảng 3. Các Giao thức IETF và sử dụng trong dịch vụ VOD IMS/NGN
Giao thức RFC chắnh Các chức năng
SIP 3261 Khởi tạo, sửa và teardown phiên, đăng ký IMS và đắnh kèm dịch vụ VOD
SDP 4566 Truyền tải phương tiện/ thông tin phiên
RTSP 2326 Điều khiển luồng
RTP/RTCP 3550 Phân phối luồng và phần phối báo cáo Đường kắnh 3588 Tác động UDSP ( cơ sở dữ liệu )
Tất cả các giao thức này là giao thức IETF và như vậy, các đặc điểm kỹ thuật có sẵn như là RFC. Lược đồ tắn hiệu được trình bày trong chương này sẽ mở rộng , tìm hiểu về các thức truyền tắn hiệu, báo hiệu bởi SIP và RTSP có thể sử dụng để xây dựng
Chương 3
dịch vụ VoD như là mô tả bởi các thủ tục mức cao của kỹ thuậ đó. Đầu tiên phần nội dung này tìm hiểu về khởi tạo dịch vụ VoD. Sau đó phiên làm việc được xem xét và chức năng ra sao sẽ phân bổ giữa SIP và RSTP, trước khi tìm hiểu những chú ý về các vấn đề khác liên quan như bảo mật, sửa phiênẦ
3.7.1. Khởi tạo dịch vụ VoD
Mạng kèm theo và đăng ký IMS sẽ thực hiện như trong mô tả của ESTI TISPAN TS 182 006 và ESTI TISPAN ES 282 004. Tuy nhiên, dịch vụ kèm theo và phục hồi danh mục cần được tìm hiểu kỹ càng.
3.7.1.1. Dịch vụ VOD chế độ đẩy
SDF cần trở thành kiến thức của người mới đăng ký sử dụng và gửi SSF-các thông tin liên quan cho người sử dụng mới. Từ khi giao diện Gm,Mx1 và ISC được sử dụng cho truyền thông UESSF là các giao diện chuẩn SIP, vấn đề rút ra là lựa chọn phù hợp với các phương thức SIP và cách thức thắch hợp để gắn các thông tin cần thiết trong tiêu đề và (hoặc) nội dung bản tin. Đối với thông báo cho SDF của người sử dụng mới, chỉ có một giải pháp thắch hợp; một đăng ký của bên thứ ba... S-CSCF sẽ gửi yêu cầu đăng ký của bên thứ ba, để mỗi AS phù hợp với các Tiêu chuẩn bộ lọc của thông tin dịch vụ từ các HSS cho đăng ký. Thủ tục này có nghĩa là yêu cầu đăng ký SIP được gửi cho các bên thứ ba gần S-CSCF trên khi đăng ký thành công. Đăng ký thành công xảy ra khi S-CSCF trả lời yêu cầu đăng ký với phản hồi 200 OK. Một đăng ký của bên thứ ba sẽ được gửi đến mỗi AS phù hợp với IFC cho việc đăng ký.
Khi nhìn qua, hai phương pháp có vẻ giống như lựa chọn thay thế thắch hợp để gửi các thông tin đắnh kèm dịch vụ: INFO và MESSAGE. Tuy nhiên, phương pháp INFO chỉ nên được sử dụng cho phiên báo hiệu và do đó không thắch hợp, từ khi UE và các SDF không tham gia phiên. Phương pháp MESSAGE là một lựa chọn tốt hơn, nó được gửi như là một yêu cầu độc lập / thực hiện trả lời.
Mục tiêu lúc đầu có 1 sự thay đổi trong tổng đài message giữa các user. Đó là sự thay thế tốt nhất, mà không phải là SIP, được mở rộng với các phương pháp bổ sung.
Dịch vụ VOD chế độ đẩy bằng cách sử dụng bên thứ 3 đăng ký và phương pháp MESSAGE được thể hiện trong hình 3.19 sau đây:
Chương 3
Hình 3.19. Dịch vụ kèm theo VOD chế độ đẩy
Các Thông tin dịch vụ thực gửi kèm trong các yêu cầu MESSAGE SIP bằng Phần thân bản tin. Chúng ta không nghiên cứu nhiều trong định dạng của thông tin này. Tuy nhiên, có thể nói: chắc chắn dạng cơ bản Ờ XML, và thông tin sẽ được chứa ở trong 1 hay nhiều địa chỉ SSF.
3.7.1.2. Dịch vụ VoD chế độ kéo
Trong chế độ kéo, UE có chức năng bắt đầu chuyển truyền thông tin kèm theo dịch vụ VoD . phương pháp INFO được loại bỏ giống như trong trường hợp chế độ đẩy. Cách thứ nhất sẽ dùng cho UE gửi yêu cầu MESSAGE và nhận thông tin đắnh kèm dịch vụ trong quá trình phản hồi.
Chương 3
Hình 3.20. Dịch vụ VoD chế độ kéo sử dụng MESSAGE
Tuy nhiên, do "Một phản hồi 2xx đến MESSAGE yêu cầu MUST NOT chứa trong phần thânỢ. Sử dụng Message như vậy có nghĩa là hai vòng khứ hồi là cần thiết Ờ một là để UE hoạt động như là các UAC, cho biết nhận được yêu cầu thông tin đắnh kèm dịch vụ sử dụng MESSAGE đầu tiên, còn lại là SDF làm nhiệm vụ của UAC gửi thông tin yêu cầu MESSAGE khác. Điều này được minh họa trong hình 3.20. Giải pháp này trông giống như một mô hình SUBSCRIBE-NOTIFY. Khi sử dụng SUBSCRIBE-NOTIFY, bạn bổ sung thêm có một phương hướng tốt của thông báo thay đổi tới thông tin đắnh kèm dịch vụ; đơn giản là gửi một Thông báo đến UE. Sử dụng Thuê bao và Thông báo đòi hỏi một gói mới được định nghĩa rằng trạng thái, bao gồm trong những điều sau: Sử dụng yêu cầu dành cho SUBSCRIBE (đồng ý) và NOTIFY (thông báo) là phần đầu của gói để xác định trạng thái, như:
- Giá trị của phần tiêu đề cho bản tin NOTIFY và SUBSCRIBE; - Định dạng của phần thân yêu cầu NOTIFY.
Chương 3
Lựa chọn cho các tham số gói sự kiện được đưa ra trong đề tài, chúng ta chỉ ra rằng một gói sự kiện mới cần phải được đăng ký với Internet Assigned Numbers Authority (IANA) . Một giải pháp kéo bằng cách sử dụng các phương pháp SIP được thể hiện trong hình 3.21 (phần đăng ký là bỏ qua thời gian cho ngắn gọn).
3.7.1.3. Phục hồi danh sách
Các giao thức được sử dụng cho các điểm tham chiếu Xa không được đề cập trong ESTi TISP. Các tác giả cảm thấy chắc chắn, tuyu nhiên không chắc điều này dựa trên HTML cơ bản, tương tự như quy định các điểm tham chiếu Ut. Các thông tin danh sách thực tế sẽ được đắnh kèm như là phần cơ bản XML để phản hồi HTTP. Các danh sách phục hổi sử yêu cầu HTTP phương thức GET được thể hiện trong hình 3.22.
Dịch vụ VoD chế độ kéo sử dụng SuBSCRIBE/NOTIFY được mô tả như trong hình vẽ sau:
Chương 3
Hình 3.22. Phục hồi danh sách sử dụng HTTP/GET
3.7.2. Phiên trình bày và luồng
Thủ tục bắt đầu và kết thúc phiên VOD được trình bày trong phần này, cũng như cách điều khiển các luồng video và cách thức phân phối dữ liệu thực.
3.7.2.1. Giao thức
Đối với chuyển luồng qua mạng IP, Giao thức truyền tải thời gian thực (RTP) ở đầu của giao thúc Dữ liệu người dùng(UDP) thường được sử dụng và đáp ứng tốt nhất ở đây.
Bảng 4. So sánh các phương tiện (phương thức) được sử dụng bởi SIP và RTSP để thực hiện phiên hoạt động.
SIP RTSP Tham số điều chỉnh/phục hồi phiên SDP (s) trong INVITE Ờ OK - ACK SDP trong trả lời DESCRIBE
Khởi tại phiên INVITE SETUP
Điều khiển luồng phương tiện
N/A PLAY/PAUSE
Kết thúc phiên BYE TEARDOWN
Để bắt đầu / chấm dứt phiên, SIP cần phải được sử dụng. Điểm tham chiếu giữa UE / IMS lõi, IMS lõi / SCF và SCF / MCF (có thể thông qua IMS lõi) tất cả các SIP sử dụng. Đối với việc kiểm soát dòng video trong mạng IP, RTSP là giao thức phổ biến nhất được sử dụng. Chưa có quy trình chuẩn hóa cho điều khiển hình ảnh luồng video (play, pause, vv) sử dụng SIP.
3.7.2.2. Đặt vấn đề
Để tóm tắt, các giao thức sau đây cần được sử dụng: Ớ SIP để bắt đầu phiên và kết thúc phiên.
Ớ RTSP để điều khiển luồng.
Chương 3
Vấn đề với kết hợp SIP và RTSP là cả hai được thiết kế để cung cấp các chức năng cần thiết thành lập và chấm dứt phiên. Phân bổ như trong trong Bảng 5.2. Làm thế nào để phân bổ trên là đúng chức năng từ SIP và RTSP một vấn đề cơ bản của VOD dựa trên IMS.
Ớ Nhu cầu thông tin
Có một vài giải pháp cho vấn đề kết hợp SIP và RTSP. Đầu tiên nghiên cứu những thông tin chức năng mạng khác nhau cần thiết cho một phiên hoạt động .
UE cần :
1. Mô tả các luồng video người dùng có nội dung thông tin chứa ở trên chẳng hạn như những Luồng nội dung gì có và những code gì được sử dụng.
2. Một RTSP URL nhận dạng các MCF và dòng để điều khiển dòng thông qua XC.
3. Bù lại được những vị trắ mà người dùng dừng xem các video trong một phiên trước (có thể sử dụng một thiết bị khác )
SCF cần
4. Một nhận dạng luồng để xác định chắnh xác và cho phép / từ chối phiên dựa trên hồ sơ người dùng.
5. ID người dùng của một số loại tìm lại (phục hồi) các dữ liệu hoạt động dịch vụ IPTV thắch hợp (xem mục 4.3.2) và hồ sơ người dùng IPTV. Một ID người dùng cũng cần thiết cho mục đắch tắnh cước.
6. Bù lại khi chấm dứt phiên trước để lưu trữ thông tin này trong dữ liệu hoạt động IPTV cho các phiên sau.
MCF cần:
7. Được thông báo của các loại thiết bị sử dụng và kết nối mạng để chọn codec thắch hợp (các máy chủ phương tiện có thể có một vài phiên bản của mỗi đoạn video, những kết hợp khác của các kết nối và thiết bị người dùng).
8. Tham gia trao đổi khóa với UE nếu bản tin RTSP bảo đảm.
3.7.2.3. Đáp ứng nhu cầu thông tin
(1) và (2) có thể được thỏa mãn bằng nhiều cách. Tất cả bao gồm truyền thông tin