ATIS 0800009-2009 Remote Management of Devices in the Consumer Domain for IPTV Services (Version 2).pdf

《ATIS 0800009-2009 Remote Management of Devices in the Consumer Domain for IPTV Services (Version 2).pdf》由会员分享，可在线阅读，更多相关《ATIS 0800009-2009 Remote Management of Devices in the Consumer Domain for IPTV Services (Version 2).pdf（26页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0800009.v002 REMOTE MANAGEMENT OF DEVICES IN THE CONSUMER DOMAIN FOR IPTV SERVICES ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry.

2、 More than 250 companies actively formulate standards in ATIS 20 Committees, covering issues including: IPTV, Service Oriented Networks, Home Networking, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support. In addition, numerous Incubators, Focu

3、s and Exploratory Groups address emerging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contribu

4、tor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, please visit . Notice of Disclaimer multiple ITF devices, such as Set Top Boxes (STBs) and storage devices that

5、terminate the IPTV streams; and mobile devices that are likely to communicate with the network directly rather than through the DNG. Remote management for each of these devices is required for the proper operation of the managed IPTV service. Due to the topology of the home network, different manage

6、ment flows are required to fully meet the remote management requirements for the IPTV service. As shown in the figure below, the following flows are required: Flow (1) for the remote management between the network and the DNG. Flow (2) for the remote management between the network and the ITF device

7、s. Flow (3) for the remote management between the network and the mobile devices. ATIS-0800009.v002 4 Figure 1: Remote Device Management Architecture Management flows 1 and 2 are based on the Broadband Forum TR-069 architecture and protocol specifications 3, with specific additions and enhancements

8、deemed necessary to better satisfy the remote management needs of the IPTV consumer domain environment. Due to the difference in the connectivity topology for each of the three flows, the security considerations for each flow are quite different. Specifically, while a direct line identification alle

9、viates some security issues for flow 1, this may not be possible for flows 2 and 3 due to the dynamic/mobile nature of the end device. Thus, it is prudent to consider a network architecture that is generic enough to address the security concerns for each of the flows. The Network Attachment Control

10、Function (NACF) in the Network Provider domain needs to provide an Authentication Function (AF) to the devices. Only devices that successfully pass an authentication process (implicit or explicit) shall be allowed to contact the Remote Configuration and Management Server (RCMS). The authentication s

11、hould be mutual so that the consumer device is also ensured that it is receiving its configuration from the intended network or service provider. Mutual authentication between the device and the authentication function/server of NACF is based on the certificate hierarchy defined in ATIS-0800015 16 a

12、nd ATIS-0800016 17 and will be described in ATIS-0800037 20. Both the device and the authentication server will use their deviceCertID and certificates for authentication purposes. Once the mutual authentication is complete, the RCMS will proceed with the device management procedure. ATIS-0800009.v0

13、02 5 It shall be noted that this specification assumes that user subscription profile may not have bearing on the device management procedure. Future versions of this specification may provide further granularity by integrating user subscription profiles in device management decisions, but will depe

14、nd on subscriber authentication and authorizations. For TR-069 devices, the protocol stack is based on invoking Remote Procedure Call (RPC) methods, expressed in a SOAP presentation layer, communicated in Hyper Text Transport Protocol (HTTP) 13 over a Transport Layer Security (TLS)14, and carried ov

15、er Transport Control Protocol (TCP) over IP, as shown below. Table 1: Remote Management Protocol Stack for TR-069 Management Applications RPC Methods SOAP (presentation layer) HTTP TLS TCP IP TLS shall be used for securing management session exchanges between the RCMS and the device. The RCMS and th

16、e device shall use their certificates according to ATIS IIF certificate trust hierarchy in ATIS-0800015 16 and ATIS-0800016 17. The architecture proposed above takes into account the reference model of the home network specified in ATIS-0800002, IPTV Architecture Requirements, the separation between

17、 layers and domains specified in the Next Generation Network (NGN), and the need to allow both the Network Provider (NP) and Service Provider (SP) to download software images and other information to the home devices. This architecture accommodates IP Multimedia Subsystem (IMS)-based IPTV networks a

18、nd non-IMS-based IPTV networks. There is a common sequence that takes place between a home/consumer device when it first initializes and attaches to the network and the RCMS for both IMS and non-IMS networks described in ATIS-0800017 2. For Groupe Spcial Mobile (GSM), Time Division Multiple Access (

19、TDMA), and Code Division Multiple Access (CDMA) Mobile Devices, management flow 3 is to be based on the Open Mobile Alliance (OMA) Device Management specifications 4, including device authentication, device bootstrapping, and device management. 4 SOFTWARE DOWNLOAD MANAGEMENT The software download se

20、rvice is part of the remote device management service in the remote device management architecture. 4.1 Software Download Definition Software to be downloaded is defined in a broad term that includes the following: ATIS-0800009.v002 6 An executable (image) running on the device. Updates to certain m

21、odules of the executable. Applications/modules running on top of the basic executable image. Profile files for the customization of certain features and services on the managed device. It shall be possible to download run-time applications without the need to re-boot the ITF device after the updates

22、 are made effective. Such a capability is highly desirable for the DNG. It should be noted that any of the software types mentioned above may require some preparation prior to being available to the download server or to the device as a result of download. The following are a few examples of such pr

23、eparation: Addition of a destination identifier in cases where a specific entity - e.g., a download manager or a separable security environment within the device - is the target residence for the downloaded image. Addition of security protection mechanisms such as signatures, encryption, and headers

24、 that indicate the existence of encrypted as well as non-encrypted parts and their corresponding length. Note that media file downloads are out of the scope of this document. 4.2 Software Download Sequence Software download to a DNG and ITF may happen in several ways, and is different for unicast ve

25、rsus multicast transport and for OMA-DM devices versus TR-069 devices. For OMA-DM devices, the software download service is based on OMA-DM FUMO specifications 22. For TR-069 devices, the software download service is based on the Broadband Forum TR-069 Amendment 2 12 as extended for multicast delive

26、ry in DVB Remote Management and Firmware Update System for DVB IP Services 10, with exceptions and additions noted. Some of the major distinctions are: This specification only applies to managed devices in the consumer domain (DVB RMS-only and RMS-FUS modes are endorsed; FUS-only mode is not endorse

27、d). This specification makes a distinction between DNGs and ITFs. DVB treats them the same and refers to them both as Customer Premise Equipment (CPE). DNG and ITF bootstrapping for software downloading is accomplished as specified by TR-069 Amendment 2 12 (the additional DVB method involving a FUS

28、stub file and multicast boot sequence is not endorsed). Completely new software and updates to previously-installed software in a DNG or ITF are downloaded from a Software Download Server (SDS) with the active participation of an RCMS. The logical sequence for a software download operation is shown

29、below in Figure 2. ATIS-0800009.v002 7 Figure 2: Software Download Sequence As preconditions to the sequence, it is assumed that the device has already authenticated and attached to the network and obtained the RCMS URL as specified in ATIS-0800017 16. It is also recommended that prior to performing

30、 device management exchanges, the ITF and RCMS establish a secure session (i.e., TLS) to prevent configuration of the ITF by third-party rogue attackers. The next step involves the initiation of the download process and the passing of download information, such as the location of the software image,

31、 from the RCMS (or the Operator in general) to the device. This step depends on the remote management protocol used by the device. For OMA-DM devices, the RCMS as the OMA Device Management Server (DMS) issues the PUSH message to the device as defined by OMA FUMO specifications 22. The device then co

32、ntacts the RCMS and provides it with its current running environment including the current software version. The RCMS then provides the device with the software image URL by writing it into the proper object in the OMA object tree, and then instructs the device to execute/run the download process, p

33、er OMA-DM 4. For TR-069 devices, there are three different possibilities based on the type of download to be performed: ATIS-0800009.v002 8 For a unicast download operation, the device establishes a TR-069 management session with the RCMS, which in turn provides the device with the URL of the softwa

34、re image to be downloaded. For multicast download, there are two cases depending on how the download control information is communicated from the network to the device: o For a unicast control using TR-069, the device establishes a TR-069 management session with the RCMS, which in turn provides the

35、device with the URL of the file that contains the download information. This file is called the atis-iif-softwaredownloadlocator.xml. The content of the file is an XML document containing a single element of name SoftwareDownloadLocator and XML datatype mps:ResourceLocatorType, as defined in ATIS-08

36、00013 21. o For a multicast control using an announcement mechanism, the Operator broadcasts the download information over some known channel/mechanism that contains the channel to tune to in order to get the new software image. The definition of the announcement channel is out of scope for this doc

37、ument. For the OMA-DM and TR-069 unicast cases, the device reaches out to the network and retrieves/downloads the image file using one of the protocols listed in Table 4 below. For the multicast cases, the device tunes to the appropriate downstream multicast channel using the IGMP protocol, and down

38、loads the image file using one of the protocols listed in Table 4 below. In all cases, the device acknowledges the status of the download operation to the RCMS, using the corresponding protocol (OMA-DM or TR-069). The network supporting this sequence is described in the next section. 4.3 Software Do

39、wnload Architecture The SDS could be part of the RCMS or could be a separate entity under the control of the RCMS. Figure 3 shows two separate systems (RCMS and SDS) with exposed interfaces. ATIS-0800009.v002 9 Figure 3: Software Download Architecture 1Interfaces are defined so that the device hosti

40、ng the SDS could be an integral part of RCMS or a separate device in the same or different domain. The SDS could be in a NP or SP domain. 4.3.1 Software Originator: A DNG or ITF manufacturer or an independent software vendor having a business relationship with the provider controlling remote configu

41、ration and management. In cases where the software is to be signed for integrity protection or encrypted for confidentiality protection, the software originator may either perform these functions directly, as may be the case for DRM/CAS software, or provide evidence of authenticity to a specific sig

42、ning server (e.g., software download manager or other third parties) that performs the signing or encryption, per ATIS-0800014 15. 1This interface for software downloads requires additional capability to be added to the TR-069 mechanism that is specified in Annex 1 of the DVB RMS-FUS (Annex 1: Exten

43、sions to TR-069 / CWMP required for DVB RMS-FUS). ATIS-0800009.v002 10 4.3.2 Software Download Server: A logical entity containing all the components required for a software download service. It is possible for all the components in the server to be physically co-located. 4.3.3 Software Download Man

44、ager: Coordinates the receiving and storage of software files and associated metadata from a software originator. It uses the metadata to add new entries to the notification service. It also uses the metadata to help in the formatting and packaging of the software file by the software distribution p

45、reparation function. 4.3.4 Software Store: Provides persistent storage of downloaded software from the software originator. 4.3.5 Notification Service: Notifies the availability of any software to a DNG or ITF device. 4.3.6 Software Distribution Preparation: A function that prepares the software fil

46、es for delivery over an IP network. It includes fragmenting, adding headers, and adding parameters compatible with delivery format. 4.3.7 Unicast Delivery Function: The delivery function provided for IPTV content delivery, characterized by a 1:1 correspondence between a data source and a sink point.

47、 4.3.8 Multicast Delivery Function: The delivery function provided for IPTV content delivery, characterized by a 1:N correspondence between a data source and a sink point. The definitions of the depicted interfaces and the correspondence with DVB RMS/FUS 10 interfaces are shown in the table below: A

48、TIS-0800009.v002 11 Table 2: Software Download Interfaces Interface label Equivalent DVB I/F 2Description Standardization a 1 This interface carries the files containing the software from the software originator entity to the software download manager. This interface is out of scope for this specifi

49、cation document. b 2 This interface carries the files containing the metadata from the software originator entity to the software download manager. This interface is out of scope for this specification document. c 3 Business-to-business relationship between the software originator and the network operator. This interface is out of scope for this specification document. d 4 Signaling and metadata between RCMS and the software download manager. Signaling based on DVB specs. Metadata to be specified by the ATIS II