ImageVerifierCode 换一换
格式:PDF , 页数:22 ,大小:291.18KB ,
资源ID:799047      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-799047.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ITU-T J 703-2010 IPTV client control interface definition (Study Group 9)《网络电视(IPTV)用户控制接口定义 9号研究组》.pdf)为本站会员(cleanass300)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ITU-T J 703-2010 IPTV client control interface definition (Study Group 9)《网络电视(IPTV)用户控制接口定义 9号研究组》.pdf

1、 International Telecommunication Union ITU-T J.703TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2010) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS Secondary distribution of IPTV services IPTV client control interface definition Recommend

2、ation ITU-T J.703 Rec. ITU-T J.703 (03/2010) i Recommendation ITU-T J.703 IPTV client control interface definition Summary Recommendation ITU-T J.703 defines the interface that enables the service client in the customers network to send requests for content and application transport using Internet P

3、rotocol (IP) technology to the Internet Protocol Television (IPTV) service functions in the operators network. Examples of IPTV content include digital video and audio programme content, including the metadata describing the programme content. Examples of IPTV requests include requests for broadcast

4、 or video on demand (VoD) content, requests to manipulate VoD content delivery (pause, play, rewind, etc.), and requests to record content for later viewing. History Edition Recommendation Approval Study Group 1.0 ITU-T J.703 2010-03-01 9 ii Rec. ITU-T J.703 (03/2010) FOREWORD The International Tele

5、communication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and t

6、ariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Reco

7、mmendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recomm

8、endation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interopera

9、bility or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that co

10、mpliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, valid

11、ity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be requi

12、red to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2010 All rights reserved. No part of this publication may be reproduce

13、d, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T J.703 (03/2010) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 1 4 Abbreviations and acronyms 1 5 Conventions 3 6 Overview 3 6.1 IPTV network reference points 3 7 IPTV client control interface 4 7.1 Proced

14、ures for client sign-on 4 7.2 System information or service information management 7 7.3 EPG acquisition and management 7 7.4 Emergency alert service . 7 7.5 Procedures for broadcast/multicast content signalling . 8 7.6 Procedures for on-demand content signalling 8 7.7 Admission control and policy m

15、anagement . 9 Appendix I IPTV client bootup sequence . 11 Bibliography. 13 Rec. ITU-T J.703 (03/2010) 1 Recommendation ITU-T J.703 IPTV client control interface definition 1 Scope The scope of this Recommendation is the i-3 interface, identified as the control interface for IP transport for enhanced

16、 broadcasting defined in ITU-T J.700 and in Figure 1 below, that enables the service client in the customers network to send requests for content and application transport using IP technology to the IPTV service functions in the operators network. Examples of IPTV content and application to be reque

17、sted through the i-3 interface include digital video and audio programme content, including the metadata describing the programme content, and applications to be presented or executed at the service client. Examples of IPTV requests include requests for broadcast or video on demand (VoD) content, re

18、quests to manipulate VoD content delivery (pause, play, rewind, etc.), and requests to record content for later viewing. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At th

19、e time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed belo

20、w. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T H.770 Recommendation ITU-T H.770 (2009), Mechanisms for service discovery and selec

21、tion for IPTV services. ITU-T J.222.0 Recommendation ITU-T J.222.0 (2007), Third-generation transmission systems for interactive cable television services IP cable modems: Overview. ITU-T J.700 Recommendation ITU-T J.700 (2007), IPTV service requirements and framework for secondary distribution. IET

22、F RFC 2326 IETF RFC 2326 (1998), Real Time Streaming Protocol (RTSP). IETF RFC 3376 IETF RFC 3376 (2002), Internet Group Management Protocol, Version 3. ISO/IEC 13818-6 ISO/IEC 13818-6:1998, Information technology Generic coding of moving pictures and associated audio information Part 6: Extensions

23、for DSM-CC. 3 Definitions None. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: CAS/DRM Conditional Access Solution/Digital Rights Management CBI Common Billing Interface CDRP Call Data Rating Point CORBA Common Object Request Broker Architecture CPE C

24、ustomer Premises Equipment 2 Rec. ITU-T J.703 (03/2010) DHCP Dynamic Host Configuration Protocol DNS Domain Name System DOCSIS Data Over Cable Service Interface Specifications DSM-CC Digital Storage Media Command and Control DVR Digital Video Recorder EAC Emergency Alert Controller EAM Emergency Ale

25、rt Message EAS Emergency Alert System ECM Entitlement Control Message EPG Electronic Program Guide FTP File Transfer Protocol G-PON Gigabit-Passive Optical Network HD High Definition HTTP HyperText Transfer Protocol IANA Internet-Assigned Numbers Authority IGMPv3 Internet Group Management Protocol,

26、version 3 IPT IP Telephone IPTV Internet Protocol TeleVision ISA Instruction Set Architecture iTV interactive TV MAC Media Access Control MPEG Moving Picture Expert Group MST Minimum Spanning Tree NAT Network Address Translation NGN Next Generation Network NMS Network Management System PVR Personal

27、Video Recorder QoS Quality of Service RG Residential Gateway RSVP Resource reSerVation setup Protocol RTP Real Time Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SI System Information or Service Information SRM Service Reference Model SSM Source Specific Multicast STB S

28、et Top Box Rec. ITU-T J.703 (03/2010) 3 STUN Simple Traversal of UDP through NATs UDP User Datagram Protocol VoD Video on Demand XML Extensible Markup Language 5 Conventions None. 6 Overview 6.1 IPTV network reference points ITU-T J.700 identifies significant reference points, shown in Figure 1 betw

29、een the CPE and the various network functions with which it interfaces, between the session/resource/policy management functions and the IPTV application servers, and between the IP content sources and the content processing, distribution and storage functions. The CPE reference points are meant to

30、address IP interfaces for hybrid and IP CPE. The network interface points for the moving picture expert group (MPEG) CPE and the MPEG portion of hybrid CPE are of a legacy nature and therefore not addressed. Transport LayerCustomer NetworkOperator NetworkIPTV Application Functions(e.g. VOD, EPG, DRM

31、)Content Sources(e.g. VOD, Linear)Application Client(e.g. DRM, CAS)Service ClientContent ClientIPTV Service FunctionsIPTV Content Functionsi-3i-4IPTV Control/Metadata FlowIPTV Content Flowi-6OSS Functionsi-2i-5i-7Web Srvcs 2) CAS/DRM control processing and client handling; 3) EPG acquisition and man

32、agement; 4) Emergency Alert System (EAS); 5) Accessing broadcast services, including accessibility functions; 6) Accessing on-demand services, including accessibility functions; 7) Networked DVR control functions; 8) Session/resource control; 9) Policy management. 7.1 Procedures for client sign-on T

33、he following procedures are necessary for a client CPE to sign-on to the operators network. The operator provides information about itself and its network topology to CPEs using a set of IP multicast flows. The first multicast flow, known as the system-wide flow, contains IP names or address of the

34、various IPTV application functions and servers in the system and a code download list that tells the set-tops in the system when to upgrade boot and client code. After obtaining an IP address from a dynamic host configuration protocol (DHCP) server, all CPEs join the system-wide flow during the boot

35、 process (once the boot loader has control and again when it launches the CPE client application). The system-wide flow resides at a well-known IP multicast address, registered with the IANA. The IP names or addresses are provided on the system-wide flow using the DSM-CC UNConfigIndication messages.

36、 The remaining flows in the system should be arranged in a hierarchy as shown in Figure 2. The system is divided into hubs and clusters as shown in the diagram below. The lowest level in the hierarchy, a cluster, is a collection of IP subnets. The operator assigns each CPE in a system to a cluster a

37、nd each cluster to a hub. Since there is only one system-wide flow, a well-known multicast address is used. The remaining flows use dynamic addresses. The set-tops acquire the address of the hub and cluster flows during the registration process (in the UNConfigConfirm message). Rec. ITU-T J.703 (03/

38、2010) 5 Figure 2 Multicast control flows The hub flow provides the system information or service information (SI) table, which contains service parameters for each service in the system. The cluster flow provides a way for the IPTV service functions to send messages to one or more set-tops. The clus

39、ter flow is special in that it is the only permanently joined multicast flow in the system. All other flows in the system are joined on demand. The cluster flow allows the IPTV service functions to provide change notification for all other flows. When there is new information in one of the other sys

40、tem multicast flows, a change notification is sent on the cluster flow. The CPE will then join the dynamic flow that contains new information and wait for the update. Once the updated information is obtained, the CPE will leave the dynamic flow. The change notifications are provided on the cluster f

41、low using DSM-CC ISO/IEC 13818-6 UNPassThru messages. When the emergency alert services are used, the EAM messages are carried on the cluster flow. After each CPE boots, it registers with the IPTV service functions in the operators network. The registration process consists of a request from the CPE

42、 to the service functions, called the UNConfigRequest or UNCR, and a reply from the service functions to the CPE, called the UNConfigConfirm or UNCC. The UNCR message, sent from the CPE to the service functions, contains the MAC address of the CPE, among other parameters. The service functions store

43、 the information from the UNCR for each CPE in a database. The UNCC message, sent from the service functions back to the CPE, contains the multicast addresses of the site, hub and cluster flows, the SRM hostname, and the location of the broadcast file system directory carousel. An IPTV client that c

44、ontains an embedded data over cable service interface specification (DOCSIS) modem MUST follow all mandatory DOCSIS procedures specified in ITU-T J.222.0, including the DOCSIS provisioning flow as the first step in the provisioning process. 7.1.1 CPE booting process There are two parts in the CPE bo

45、oting process. First, the boot loader must obtain an IP address and check for a new code. If a new code is available, the boot loader must obtain the new code from the service functions, then boot the new code. Second, the boot loader must start the video applications (client code). The booting proc

46、ess is outlined in this clause and is summarized in Table 1. ITU-T H.770 describes some portions of the booting process. System-Wide FlowHub FlowCluster ClusterCluster ClusterHub FlowCluster ClusterCluster Cluster6 Rec. ITU-T J.703 (03/2010) Table 1 Set-top box booting process Step Description 1 Boo

47、t loader obtains IP address from DHCP server. 2 Boot loader joins system-wide flow (IANA registered address) and obtains code download list. 3 Boot loader compares the CPE identity and current code version to the code download list. If there is a new available code, the boot loader downloads new cod

48、e before continuing. If there is no new available code, continue with next step. 4 Boot loader boots CPE client code. 5 The CPE continues to listen on the system-wide flow for UNCI messages containing: IP host name of the primary service function server; IP host name of any IPTV service function ser

49、vers (including STUN and NMS). 6 The CPE leaves system-wide flow. 7 The CPE uses DNS to resolve IP addresses of any IPTV service function servers (including STUN and NMS). 8 The CPE contacts a STUN server and obtains NAT mappings for any IPTV services that may require NAT mappings (including UNPassThru messages). 9 The CPE registers with the primary IPTV service function server by sending a UNConfigRequest message (UNCR). 10 The primary IPTV service function server replies to the UNCR with UNCon

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1