ATIS 0800017-2012 Network Attachment and Initialization of Devices and Client Discovery of IPTV Services (Version 3 0).pdf

《ATIS 0800017-2012 Network Attachment and Initialization of Devices and Client Discovery of IPTV Services (Version 3 0).pdf》由会员分享，可在线阅读，更多相关《ATIS 0800017-2012 Network Attachment and Initialization of Devices and Client Discovery of IPTV Services (Version 3 0).pdf（74页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0800017.v003 NETWORK ATTACHMENT AND INITIALIZATION OF DEVICES AND CLIENT DISCOVERY OF IPTV SERVICES As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Through ATIS committ

2、ees and forums, nearly 200 companies address cloud services, device solutions, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecyclefrom design and innovation through solut

3、ions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP),

4、 a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit . Notice of Disclaimer it could be, among o

5、ther things: a smart phone, a laptop, a tablet, a desktop computer, a game console, an in-vehicle entertainment systems, or even a TV set. 1.3.4 Mobile IPTV: A subset of the IPTV service requirements as specified in ATIS-0800007, IPTV High-Level Architecture, and applies to where the Consumer ITF is

6、 connected to the IPTV Service Provider via an IPTV-ATIS-0800017.v003 5 enabled mobile transport network. The architectural requirements of Mobile IPTV shall comply with all existing requirements of ATIS IIF IPTV specifications while also supporting physical mobility and resources for the ITF. 2 Ref

7、erences 1 3GPP TS 23.218, IP Multimedia (IM) session handling; IM call model; Stage 2, V8.1.0, 2008.12 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2, V8.4.0, 2008.13 3GPP TS 24.229, Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Sessio

8、n Description Protocol (SDP); Stage 3, V8.3.0, 2008.14 3GPP TS 29.228, IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents, V8.1.0, 2008.15 3GPP TS 33.203, 3G Security; Access Security for IP-based services, V8.2.0, 2008.16 3GPP TS 33.220, Generic Authentication

9、Architecture (GAA); Generic bootstrapping architecture, V8.3.0, 2008.17 ATIS-0800002, IPTV Architecture Requirements, 2006.28 ATIS-0800003, IPTV Architecture Roadmap, 2006.29 ATIS-0800007, IPTV High Level Architecture, 2007.210 ATIS-0800009, Remote Management of Devices in the Consumer Domain for IP

10、TV Services, 2008.211 ATIS-0800013, Media Protocols Specification, work in progress.212 ATIS-0800020, IPTV EPG Metadata Specification, 2008.213 ATIS-0800022, Consumer Domain Device Configuration Metadata, work in progress.214 Broadband Forum TR-069, CPE WAN Management Protocol v1.1, Issue 1 Amendmen

11、t 2, 2007.315 Broadband Forum TR-101, Migration to Ethernet Based DSL Aggregation, 2006.316 IETF RFC 1884, IP Version 6 Addressing Architecture, 1995.417 IETF RFC 2131, Dynamic Host Configuration Protocol, 1997.418 IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions, 1997.419 IETF RFC 2365, Admi

12、nistratively-Scoped IP Multicast, 1998.420 IETF RFC 2782, A DNS RR for specifying the location of services (DNS SRV), 2000.421 IETF RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification, 2002.422 3GPP TS 23.208, Policy and Charging Control Architecture, V11.5.0, 2012.123 3GPP TR 21

13、.905, Vocabulary for 3GPP Specifications, V11.0.1, 2011.13 DNG Attachment that is, the ITF device may chose to complete the entire DHCP DISCOVER-OFFER-REQUEST-ACK sequence and then perform the DNS operation. Specifically, the following takes place: 1) The ITF device establishes Layer 1 and Layer 2 c

14、onnectivity with the DNG across the home network, which could be a copper network, coaxial network, fiber network, or wireless network. 2) The ITF device issues a DHCP DISCOVER message toward the DNG that shall include all mandatory DHCP client options, as specified in Table A.3 in Appendix A. The I

15、TF device shall also include Option 60 to allow it to identify itself to the network. The DNG passes this DISCOVER message to the core/access network transparently. 3) The network provider DHCP server replies to the ITF device with a DHCP OFFER message that shall include all mandatory DHCP server op

16、tions, as specified in Table A.4 in Appendix A. The DHCP server shall provide the following information to the ITF device: ATIS-0800017.v003 13 a) ITF device IP address in the “yiaddr” field of the DHCP OFFER message. b) ITF device network mask in the subnet mask Option 1. c) DNS Server IP address(e

17、s) in the DNS Option 6. d) If available, the RCMS IP address in the “siaddr” field of the DHCP OFFER message. e) Default gateway IP address in the Default Router Option 3. The DNG shall pass the DHCP OFFER message to the ITF device transparently. There are three possibilities at this point reflected

18、 in the content of the DHCP OFFER message: a) If the DHCP server is provisioned with the RCMS IP address, then it shall include it in the siaddr field of the OFFER message. This is shown as step 3-a in the figure above. Since a complete RCMS URL is required per TR-069 specifications to reach the RCM

19、S, the ITF device shall construct the RCMS URL based on the following URL syntax: URL = protocol:/host:port/path where, The “protocol” could be “http” or “https”. The “host“ portion of the URL may be the IP address or the FQDN of the RCMS, and in this case it is the RCMS IP address that is included

20、in the “siaddr” field of the OFFER message. The “path” could be the default path /. In this specification document, the ITF device shall assume that the RCMS is deployed under the default path / and SHALL construct the RCMS URL as follows: RCMS URL = http(s):/ip:port/. In this specification document

21、, the ITF device shall assume that the RCMS is deployed under the default TR-069 port number 7547, and shall construct the RCMS URL as follows: RCMS URL = http:/ip:7547/. (for the http protocol) or RCMS URL = https:/ip:7547/. (for the https protocol) To resolve the two protocols issue, the ITF devic

22、e shall attempt to contact the RCMS using https protocol first, then attempt the http protocol if the first attempt fails. b) If the DHCP server is provisioned with the RCMS FQDN but not with the RCMS IP address, then it shall set siaddr = 0.0.0.0 and provide the ITF with the RCMS FQDN using one of

23、the following three options: 1) Option 43 with a complete RCMS URL per TR-069 specification 2) Option 43 with an RCMS FQDN, as specified in Appendix A, Table A.4. 3) Option 15, as extended by the ATIS IIF, in Appendix A, Table A.4, use case b. In case 1, the URL is provided, and can be used directly

24、 by the ITF device to contact the RCMS. In case 2 or case 3, the ITF device can construct the RCMS URL from the FQDN as follows: RCMS URL = http(s):/FQDN:7547/. or can perform a DNS query first to obtain the RCMS IP address, and then construct the RCMS URL from the IP address, as follows: RCMS URL =

25、 http(s):/ip:7547/. ATIS-0800017.v003 14 Option 43 takes precedence over Option 15 for the RCMS FQDN case. That is, if Option 43 (with an RCMS FQDN) and Option 15 are both received, then the client shall use the RCMS FQDN specified in Option 43. Please refer to the DHCP conformance table in Appendix

26、 A for more details. The ITF device shall interact with the DNS to resolve the RCMS IP address. This is shown as step 3-b in Figure 5 above. c) If the DHCP server is not provisioned with the RCMS address information (IP address or FQDN) and therefore does not provide the RCMS IP address or its FQDN,

27、 then there shall be a mechanism in place to allow the end user to manually configure the ITF device, or the ITF device can obtain the configuration information directly from its Service Provider during the Attachment to SP phase, per section 8. 4) The DHCP protocol sequence completes with the stand

28、ard DHCP REQUEST and DHCP ACK messages. Note - It is possible for the ITF device DHCP client to request additional information from the DHCP server via the use of the DHCP INFORM operation as described in RFC 2131. The DHCP INFORM operation, which usually includes the parameter list Option 55, can b

29、e invoked by a DHCP client at any time to request configuration information from the DHCP server. After acquiring the IP address of the RCMS, the ITF device interacts with the RCMS to acquire needed configuration parameters, per ATIS-0800009, Remote Configuration of Devices in the Consumer Domain fo

30、r IPTV Services. NOTE - The RCMS discovered in any of the previous steps could be designated by the network provider as the initial RCMS. Consequently, and per TR-069 specifications, this discovered RCMS, upon its first contact with the ITF device, can set the following element in the ITF device dat

31、a model: Device.ManagementServer.URL to re-direct it to its operational RCMS. From that point on the ITF device interacts with the RCMS based on the URL specified by this object. 6.3 Use of a Mobile Network In this case, a mobile device is located within the consumer domain but is outside the home n

32、etwork, as per Figure 1. The mobile device connects through a mobile network to receive and consume IPTV services. It is assumed that the mobile device has already discovered the mobile network and is registered with it as per relevant 3GPP specifications. The first step for a mobile device wanting

33、to use data services (such as the IPTV service) is to establish an appropriate IP-CAN bearer service. This involves obtaining an IP address to complete registration to the IMS. This is performed as per section 7.2 of 3GPP TS 23.203 5. It should be noted that this applies whether the mobile device is

34、 connecting either through its home mobile network (HPLMN) or a visited mobile network (VPLMN) i.e., when roaming. 7 ITF Service Provider Discovery Service Provider (SP) Discovery is the process by which an ITF becomes aware of the available IPTV Service Provider(s), and learns the means for attachi

35、ng to a Service Provider over a secure managed network. The list of one or more Service Provider(s) available to the consumer is offered by the Network Provider (NP). The information will be represented in the manner appropriate for each service discovery method. Six Service Provider Discovery metho

36、ds are defined in this section. The discovery methods differ in the number of steps to be performed by an ITF to obtain the SPs information. A method can obtain the Service Provider discovery information directly in a single step or indirectly by first obtaining a pointer to the information and then

37、 obtaining the information. The details are described in the sections below. Each method concludes with the ITF obtaining the following information for each service provider: Attachment addressing information (required), in one of the following forms: ATIS-0800017.v003 15 o SP P-CSCF URL through whi

38、ch to connect to the IMS registrar (IMS case). o Application Server URL/IP address along with basic common configuration required by all ITFs. SP ID (Note: not required for IMS and whether this is required for non-IMS is for further study). SP name (optional, multi-lingual). SP description (optional

39、, multi-lingual). SP logo (optional). Version number of SP information (optional). This information is used by an ITF to perform the subsequent attachment to the Service Provider (see section 8) and Services Discovery and Selection (see section 9) procedures. The information retrieved in this stage

40、is typically not secured - i.e., a non-authenticated client can perform the discovery process, and it is possible that the retrieved information would contain no data to authenticate the “publisher” of the information. The attachment information for each Service Provider is specific to the attachmen

41、t method and shall be sufficient for attachment using at least one of the following methods: multicast push, unicast pull, or IMS. The methods are described in section 8. The discovery methods described below differ in the representation of the discovery information retrieved. The discovery data is

42、represented in a format specific to the protocol in use as specified in each section below. The details of the service provider attachment data will be defined in ATIS-0800022, IPTV Consumer Domain Device Configuration Metadata, using XML format. The Service Provider Discovery procedures for the dif

43、ferent alternatives are summarized in the following figure. ATIS-0800017.v003 16 Figure 6: Service Provider Discovery Procedures Summary 7.1 Alternative 1: Preconfigured or Manual SP Discovery Method The ITF may be preconfigured (as described in section 5) with a list of one or more SPs containing a

44、ll the necessary information as specified in section 7. 7.2 Alternative 2: DHCP-based SP Discovery Method In addition to acquiring its own IP address and the IP address of the RCMS from the DHCP server, the ITF can acquire a list of one or more SPs containing all the necessary information as specifi

45、ed in section 7 through the DHCP Container Option as described in Appendix C. The format of the list is for further study. 7.3 Alternative 3: Download of the Discovery Information from the Network Provider Domain Method In this case, the client uses an FQDN defined by the network provider as the loc

46、ation from which to download the atis-iif-service-provider-locator.xml file using TFTP. This file contains the service provider(s) attachment information in XML format as described in ATIS-0800022, IPTV Consumer Domain Device Configuration Metadata. The network providers DNS is used to resolve the a

47、vailable FQDN to an IP address. ATIS-0800017.v003 17 7.4 Alternative 4: TR-069 Protocol-based SP Discovery Method In this case, the discovery is performed by the ITF using the TR-069 protocol during phase 1 of the ITF device initialization and attachment sequence. Specifically, upon a successful ITF

48、 device network attachment and successful establishment of a management session between the ITF and the RCMS, the RCMS provides the ITF with a list that contains the SP information. It is possible that the RCMS is aware of addressing information of a single IPTV SP, multiple IPTV SPs, or no IPTV SPs

49、 at all. For each known IPTV SP, however, the RCMS shall provide the ITF with the information as stated at the beginning of this section. The details of the data structure (list of SP information) and its formal representation shall be compliant with TR-069 data model syntax, and will be defined in ATIS-0800022, IPTV Consumer Domain Device Configuration Metadata. 7.5 Alternative 5: Streaming of the SPs Information to a Multicast Address Method In this case, the atis-iif-service-provider-locator.xml file is