Network operators have begun. Standardization Activities for IPTV Set-Top Box Remote Management IPTV

Transcription

1 Standardization Activities for Set-Top Box Remote Management services are gaining widespread use, requiring service providers to have effective methods for remotely configuring and managing set-top boxes (STBs). Solutions for such remote management are becoming standards-based. This article examines published specifications and ongoing activities on STB remote management in four standards organizations: the Broadband Forum, the Digital Video Broadcasting Project, the Open Forum, and the Alliance for Telecommunications Industry Solutions Interoperability Forum. The authors compare the protocol and data model definitions, investigate interoperability test events, and comment on possible future directions for standardization. Jun Shan Wey, Joachim Lüken, and Jürgen Heiles Nokia Siemens Networks Network operators have begun deploying services television and content-on-demand services delivered over managed broadband networks to the home over the past few years. As services mature and become more widely deployed, service providers must have an efficient way to remotely configure and manage set-top boxes (STBs), which terminate the service in the user s home, render the content for display on the TV set, and allow user interaction via a remote control. Commercial products for STB remote management have evolved from purely proprietary to standards-based solutions. Several standards development organizations (SDOs) have published STB remote-management standards and are working on extending these protocols. Furthermore, tests have been performed to validate the interoperability of standards-based implementations. In this article, we examine current standards as well as the results of recent interoperability tests. Device management within the digital home, defined in SDOs such as the Universal Plug and Play Forum and the Digital Living Network Alliance, is out of this article s scope. Standardization for STB Remote Management One important challenge for an service provider is reducing its churn rate that is, the number of cus- 32 Published by the IEEE Computer Society /09/$ IEEE IEEE INTERNET COMPUTING

2 Standardization Activities for Common Acronyms tomers leaving its service by improving problem response and resolution time. A remotemanagement application is thus a critical component that lets service providers quickly resolve problems customers report and lower the cost of troubleshooting. An STB remote manager lets service providers perform initial configuration, initiate diagnostic tests, download firmware on all or a group of STBs, or retrieve STB performance data and network status. Protocols such as the Simple Network Management Protocol (SNMP) with its often vendor-specific content as well as proprietary solutions have been available for remotely managing network devices for many years. However, these solutions aren t well suited to operate in networks behind firewalls and routers performing network address translation of private IP addresses. The Open Mobile Alliance (OMA) defines remote management for mobile devices, whereas CableLabs specifies it for cable TV deployments. With respect to, the Broadband Forum s (BBF s) remote-management specification for DSL-based fixed-line access, which is widely deployed to manage DSL home gateways, is a natural choice because services are usually provided via fixed-line networks. This approach also lets service providers have a single back end for managing consumer equipment such as DSL home gateways and STBs. BBF TR-069 the CPE WAN Management Protocol (CWMP) 1 defines a generic mechanism for facilitating the communication between customer premises equipment (CPE) and its remote-management server, the autoconfiguration server (ACS). The BBF has defined data models for TR-069-capable devices, including STBs. The Digital Video Broadcasting (DVB) Project, the Open Forum (OIPF), and the Alliance for Telecommunications Industry Solutions (ATIS) Interoperability Forum (IIF) have all adopted CWMP in their specifications. However, each body has added specific extensions to suit its needs. Here, we ll examine these extensions in more detail. Broadband Forum Since TR-069 s publication in 2004, the broadband industry has widely accepted and deployed it for remote home-gateway management. The BBF (formerly the DSL Forum) has been continually extending its specification set to cover ACS: autoconfiguration server ATIS: Alliance for Telecommunications Industry Solutions BBF: Broadband Forum CPE: customer premises equipment CWMP: CPE WAN Management Protocol DVB: Digital Video Broadcasting FUS: firmware update system IIF: Interoperability Forum MSF: MultiService Forum OIPF: Open Forum RMS: remote-management system RPC: Remote Procedure Call SDO: standards development organization STB: set-top box Policy OSS/BSS Call center Auto-configuration server (ACS) ACS northbound interface Scope of CPE WAN Management Protocol (CWMP): ACS southbound interface Managed Internet gateway device other devices in the home, such as STBs. Commercial deployments of STB extensions have already begun and are gaining momentum as other SDOs adopt BBF specifications. TR-069 specifies CWMP for bidirectional communication between a CPE and its associated ACS for secure autoconfiguration and other CPE-management functions. Figure 1 shows how the protocol is applied in an end-to-end architecture. The home network might consist of Internet gateway devices as well as LAN devices such as STBs, voice-over-ip (VoIP) phones, and storage devices. TR-106 defines the baseline data model required for all TR-069- Managed LAN device Managed LAN device Managed LAN device Figure 1. End-to-end architecture using the CPE WAN Management Protocol (CWMP). CWMP is the autoconfiguration server southbound interface for managing devices in broadband home networks. It was initially targeted for Internet gateway devices and later extended to other residential devices. (Source: Broadband Forum; redrawn with permission.) MAY/JUNE

3 Functionality Configuration Trouble management Performance management Fault management Table 1. Key set-top box (STB) remote-management functionalities. Description An autoconfiguration server (ACS) initially configures STB parameters and updates STB firmware or software. The ACS collects information to perform diagnostics and takes required actions, such as rebooting or updating software to remotely clear the fault. This functionality usually acts in response to customer complaints (trouble tickets). The ACS periodically polls STBs to collect usage statistics and quality-of-service (QoS) or qualityof-experience (QoE) parameters. The STB QoS/QoE reporting capabilities let service providers conduct measurements at the service level. The ACS periodically polls or receives reports from STBs when faults occur. This functionality lets service providers proactively diagnose and troubleshoot problems before consumers complain about service degradation or outage. Customer premises equipment Open connection SSL initiation HTTP post Inform request HTTP response Inform response HTTP post (empty) HTTP response GetParameterValues request HTTP post GetParameterValues response HTTP response SetParameterValues request HTTP post SetParameterValues response HTTP response (empty) Close connection Auto-configuration server Figure 2. A customer premises equipment (CPE) autoconfiguration server (ACS) transaction session. A CPE always initiates a transaction session using an Inform method. In this example, the ACS subsequently reads some parameter values from the CPE and, based on the received information, sets the parameter values. (Source: Broadband Forum; redrawn with permission.) enabled devices, 2 whereas TR-135 specifies the additional data model for STBs. 3 These BBF specifications let service providers perform four key remote-management functionalities, described in Table 1. CWMP s architecture specifies a generic mechanism using Remote Procedure Call (RPC) methods that allow the ACS to configure and monitor a CPE s status and statistics. The RPC is encoded in SOAP, transferred via HTTP or HTTPS (HTTP over Secure Sockets Layer [SSL] or Transport Layer Security [TLS]), and carried over the standard TCP/IP protocol. SOAP lets one program use another s services in a remote machine for example, an STB receiving a GetParameterValues RPC will respond to the ACS with the values for that parameter. Furthermore, SOAP is platform independent and has inherited capabilities such as encryption and authentication from the underlying HTTPS. This is similar to a Web services design. We can view the basic interaction between the ACS and a CPE as follows. First, the CPE follows a set of mechanisms to discover the address of its associated ACS. After this discovery, the CPE can initiate connections on special events, such as reboot, or periodically, by issuing an Inform RPC; or the ACS can request the connection through a Connection Request RPC. Thus, for each transaction session, the CPE opens a TCP connection, then might initiate SSL/ TLS. The CPE then initiates a session by sending an initial Inform request to the ACS. For example, a session might consist of the Inform transaction and a transaction in which the ACS calls the Reboot method at a CPE, which then responds with RebootResponse and performs the reboot. A session terminates after certain predetermined conditions are met. Figure 2 shows another example CPE ACS transaction session. The BBF has developed and included several improvements in an updated version of TR-069. For example, as a result of the BBF s close collaboration and alignment with the DVB Project, TR-069 Amendment 2 adds multicast firmware download support. TR-135 defines a data model for describing STB capabilities, such as basic audio/video streaming, content security, quality of service 34 IEEE INTERNET COMPUTING

4 Standardization Activities for CE manufacturer Firmware update system (FUS) FUS storage FUS multicast server FUS unicast server RMS administration 11 FUS manager RMS inventory Firmware announcement service RMS manager 13 Remote management systems (RMS) 7 8 End device Interfaces: 1. Firmware package 2. Firmware metadata 3. CE vendor-rms admin 4. RMS-FUS control 5. Multicast firmware delivery (FLUTE, DSM-CC) 6. Unicast firmware delivery (HTTP[S], [s]ftp, TFTP) 7. Firmware announcement (SDP/SAP, XML/DVBSTP) 8. Query response channel (SOAP) 9. CPE management (TR-069 CWMP 1.1 or others) 10. RMS administration 11. FUS storage (internal) 12. FUS processing (internal) 13. RMS inventory (internal) Figure 3. Digital Video Broadcasting software download architecture. This architecture describes the functional elements and interface protocols for a firmware update system (FUS) and a remote-management system (RMS). (Source: Digital Video Broadcasting Project; redrawn with permission.) (QoS), and video service performance monitoring. It defines several profiles to allow for more efficient and effective management. Each profile is a collection of requirements associated with a particular data object. The BBF is continuing its efforts to update both TR-069 and TR-135. The next amendment for both specifications is expected in DVB Project The DVB Technical Module, IP Infrastructure (TM-IPI) group completed the first phase of remote- management work in early 2008, enabling CPEs firmware upgrade capability within the home environment. 4 It accomplished this phase in close cooperation with other SDOs, specifically BBF and ATIS IIF, resulting in good alignment of the specifications. The DVB specification focuses on defining a firmware update system (FUS) that can either stand alone in unmanaged environments or work with existing remote-management systems (RMSs) that other bodies have specified for managed environments. Although the DVB specification is basically RMS neutral and will eventually support more than one RMS, it currently specifies and recommends only extensions for a TR-069- based solution. Figure 3 shows a logical architecture that describes the functional elements and interface protocols for a FUS and an RMS. DVB introduces some new concepts not currently covered by existing RMS capabilities: DVB defines the firmware metadata transferred via interfaces 2, 3, and 4 in detail using XML Schema. A firmware download can be triggered by a multicast announcement (interface 7) rather than an RMS-issued event, enabling selective and scalable firmware updates for a large population of STBs. Alternatively, interface 8 provides a unicast query/response channel to inform end devices about new firmware versions. MAY/JUNE

5 Residential network Open terminal function (OITF) Application gateway (AG) IMS gateway (IG) User-network interface (UNI) Broadband network WAN Amendment 2. Furthermore, the TR-106 data model has several DVB-specific extensions that configure the CPE end of the multicast announcement service, such as the specific multicast IP addresses the STBs should listen to. The DVB specification s first phase doesn t define a CPE data model, but the organization is discussing these aspects and plans to develop data model specifications later in Remote management support: Content and service protection gateway (CSPG) WAN gateway TR-069 and browser API No support TR-069 only Figure 4. Open Forum (OIPF) residential network architectures. The figure describes the different functional entities and protocol usage on the residential network side. (Source: OIPF; redrawn with permission.) Table 2. Open Forum functional entity data models. Functional entity Open Terminal Function Supported data models TR and TR WAN gateway TR-106 and TR-98 Internet gateway data model 9 IP Multimedia Subsystem gateway Application gateway TR-106 Session Initiation Protocol end points of TR-104 voice-over-ip customer premises equipment data model 10 TR-106 DVB enables the use of multicast protocols for firmware downloads (interface 5), such as File Delivery over Unidirectional Transport (FLUTE) 5 and Digital Storage Media Command and Control (DSM-CC). 6 Because TR-069 is the recommended management protocol, DVB has defined some extensions in cooperation with the BBF to support requirements for firmware updates. The DVB specification defines a new method for informing the RMS upon the completion of a file transfer (either successful or unsuccessful) that the RMS didn t specifically request. The BBF has also adopted this new method in TR-069, OIPF The OIPF defines an end-to-end solution for both IP Multimedia Subsystem (IMS)-based managed networks and open Internet deployments. A common user network interface (UNI) ensures that end users have access to services from multiple service providers over both network types. Remote management is applicable only to managed networks in this context. The OIPF architecture separates the residential network functionality into several functional entities, 7 as Figure 4 shows. Whether a functional entity is required depends on the supported services and deployment scenarios. The physical implementation of functional entities in a residential network is outside the OIPF specifications scope. The Open terminal function (OITF) that Figure 4 shows provides user access to basic services. It terminates video and audio streams, processes metadata, handles content and service protection, and includes a browserbased declarative application execution environment. The WAN gateway represents the home gateway, which provides an interface between the access network and the home network. The OITF and WAN gateway are always required. For managed network deployments, the IMS gateway (IG) provides an IMS client for authentication and session management, network discovery, and interface with the OITF. The content and service protection gateway (CSPG) allows alternative content protection solutions on the network side and transfers them into a standardized format to the OITF. With the application gateway (AG), Java applications can be downloaded to and executed in the residential network. Volume 4 of the OIPF Technical Specifications 8 defines the use of TR-069-based remote management for the OITF, WAN gateway, IG, and AG. OIPF will consider remote management for the CSPG in future releases. Table 2 lists the 36 IEEE INTERNET COMPUTING

6 Standardization Activities for specific data models 2,3,9,10 the BBF defines as applied to different OIPF functional entities. As an alternative to TR-069-based remote management, service providers can perform remote diagnostics and management on the OITF using APIs of the Consumer Electronics Association (CEA) 2014-based 11 declarative application execution environment. 12 Such APIs provide access to OITF properties such as vendor and model names as well as diagnostic information related to packet loss and decoder errors. The APIs also support reading out and modifying optional vendor-specific parameters. Furthermore, they allow triggering of software updates, although the software update process itself is outside the release 1 specifications scope. Note that remote management doesn t depend on specific IMS functionality. It isn t coupled with IMS except as regards the configuration of IMS/Session Initiation Protocol (SIP)-related parameters in the IG. OIPF finalized its release 1 technical specifications in late It will complement these specifications with profile specifications later this year. The organization has started work on release 2, with already-approved requirements. No major additions for remote management are expected for this release. Software download server (SDS) Software store Software distribution preparation Software originator a b Software download manager Unicast delivery function Multicast delivery function Business I/F c Remote configuration and management server (RCMS) d Signaling and metadata Unicast download f1 f 2 Multicast download e1 e2 Transport network TR TR-069 1, other ATIS IIF While coordinating with other global SDOs, ATIS IIF focuses on developing both IMS- and non-ims-based managed network standards, with special emphasis on the North American market. ATIS IIF completed its remotemanagement specification (ATIS ), 13 which closely follows definitions from the BBF and the DVB Project. ATIS defines a remote-management and configuration server (RCMS) that serves as the key entity for remote-management functionalities. ATIS IIF adopts the TR-069 protocol and methods for provisioning and configuring both terminal function (ITF) and delivery network gateway (DNG) devices. For mobile devices, the specification follows the OMA Device Management protocol. 14 ATIS covers three main functionalities: software download management, remote device management, and remote device monitoring. For software download management, ATIS IIF adopts some but not all of the BBF and DVB specifications. Figure 5 shows the ATIS IIF software download architecture. Functional entities are self-explanatory in the figure. Interfaces i1/ i2, based on TR-069, are for configuration and download management signaling. Protocol definitions follow the DVB Project specifications for interfaces d (signaling and metadata for software download), e1/e2 (multicast delivery), and f1/f2 (unicast delivery). ATIS IIF will specify metadata definitions for these interfaces in future releases. The other interfaces are out of this specification s scope. The ATIS IIF definitions and those from BBF and DVB have some major differences: The ATIS IIF specification applies only to managed devices in the consumer domain. It doesn t endorse DVB FUS as a standalone capability without RMS. The ATIS IIF specification distinguishes between DNGs and ITFs, as opposed to referring to both as CPEs. DNG and ITF bootstrapping for software downloading strictly follows the definitions in TR-069, Amendment 2. ATIS IIF also specifies additional security mechanisms to guarantee authentication of the downloaded file before executing it. This isn t covered by the existing DVB and BBF specifications. ATIS gives detailed definitions for trust mechanisms for this and other security requirements. i1 DNG Figure 5. Alliance for Telecommunications Industry Solutions (ATIS) Interoperability Forum (IIF) software download architecture. The figure shows the functional entities and interfaces between a service provider and a residential network for remote-management and software download. (Source: ATIS IIF; redrawn with permission.) i2 ITF MAY/JUNE

7 The ATIS IIF remote device management specifications basically follow the BBF s definitions for ITF and DNG, and OMA s for mobile devices. For remote device monitoring, ATIS IIF employs a layered principle to monitor information at the device, IP transport, and service layers. The remote device management specifications cover various aspects of the functionalities we describe in Table 1. ATIS defines specific QoS- and quality-of-experience (QoE)-related metrics. Currently, the ATIS IIF data model definition contains only high-level descriptions; future releases will define the details, although ATIS IIF hasn t finalized a specific timeline for this yet. Interoperability Test Events A successful roll-out of remotemanagement services relies heavily on validating published standards via interoperability tests. TR-069 Interoperability Plugfests have focused on testing the protocol layer and haven t been specific. The Global Multi-Vendor Interoperability test event that the MultiService Forum (MSF) hosted in 2008 has included STB remote-management test cases. Here, we look at these test events more closely. BBF TR-069 Interoperability Plugfests The BBF hosts a quarterly TR-069 Interoperability Plugfest for manufacturers of TR-069- capable CPEs and ACSs. During these plugfests, the participants test the interoperability of TR- 069-capable devices based on the latest version of TR-069 and all its related working texts. Although past plugfests haven t been -related, discussions are in progress about interoperability tests that will ensure successful rollouts. MSF Global Multi-Vendor Interoperability Test One of the MSF s main charters is to validate standards that major SDOs define for nextgeneration network-related topics. Every other year, MSF hosts the Global Multi-Vendor Interoperability (GMI) test event based on interoperability agreements (IAs) and test plans its member companies have developed. GMI 2008 was conducted at five global test sites involving four major service providers during two weeks in October. Two significant contributions were related to : the first-ever IMS interoperability test event and a partnership between MSF and ATIS IIF to conduct early validation of ATIS IIF standards in a realistic network environment. The STB Remote Management IA and test plan are based on the BBF specifications. The test plan, applicable to both IMS (ETSI TISPAN-based) and non-ims-based architectures, focuses on three categories of test cases derived from Table 1: Configuration. Verify that the baseline profile is supported. Remote diagnostics. Verify the capability for remotely identifying STB fault conditions. Performance management. Collect audience statistics and performance parameters. Due to the unavailability of test equipment from participating vendors, STB remote management was only partially tested in GMI The results showed that some specifications don t provide clear implementation guidelines, especially regarding optional features. Consequently, vendors interpret the specifications differently, causing interoperability issues. MSF published a whitepaper in January that provides the industry with the GMI 2008 test results and the MSF s recommendations to SDOs for future specification improvements. A s commercial RMSs are being widely deployed, one important consideration is the scalability of the remote-management protocols for supporting mass STB configuration and simultaneous retrieval of data from all or a subset of STBs. Given that CWMP currently requires stateful TCP connections for communication between CPEs and an ACS, multicast techniques and UDP-based communication are being investigated. As commercial deployments of the current specifications are under way and SDOs continue to develop new ones, the industry must continue aligning standardization work to avoid duplication and conflict of definitions. Industry-wide interoperability test events to validate published specifications can benefit service providers tremendously in the end-to-end architecture design. In the next phase of STB remotemanagement standardization, SDOs should pay special attention to improving efficiency and 38 IEEE INTERNET COMPUTING

8 Standardization Activities for security, ensuring scalability, and addressing the management of converged wireline and wireless devices. Acknowledgments We acknowledge the ATIS IIF, BBF, DVB Project, OIPF, and MSF for permission to reuse diagrams published in their specification documents. Special thanks to David Francisco and Jeff Lowery of Nokia Siemens Networks for their valuable comments. References 1. BBF TR-069, CPE WAN Management Protocol v1.1, Issue 1, Amendment 2, Broadband Forum, Dec. 2007; 2. BBF TR-106, Data Model Template for TR-069-Enabled Devices, Issue 1.1, Broadband Forum, Nov. 2006; www. broadband-forum.org/technical/trlist.php. 3. BBF TR-135, Data Model for a TR-069-Enabled STB, Broadband Forum, Dec. 2007; org/technical/trlist.php. 4. ETSI TS , Remote Management and Firmware Update System for DVB IP Services, European Telecommunication Standards Institute, Feb. 2008; org/website/standards/standardsdownload.aspx. 5. T. Paila et al., FLUTE File Delivery over Unidirectional Transport, IETF RFC 3926, Oct. 2004; org/rfc/rfc3926.txt. 6. ISO/IEC , Information Technology Generic Coding of Moving Pictures and Associated Audio: Digital Storage Media Command and Control, Int l Organization for Standardization/Int l Electrotechnical Commission, July Functional Architecture; V1.2; Open Forum, Dec. 2008; 8. Release 1 Specification Volume 4 Protocols, V1.0, Open Forum, Jan. 2009; 9. BBF TR-98, Internet Gateway Device Data Model for TR- 069, Issue 1, Amendment 2, Broadband Forum, Sept. 2008; BBF TR-104, Provisioning Parameters for VoIP CPE, Broadband Forum, Sept. 2005; org/technical/trlist.php. 11. CEA-2014, Web-Based Protocol and Framework for Remote User Interface on UPnP Networks and the Internet (Web4CE), Consumer Electronics Assoc., June Release 1 Specification Volume 5, Declarative Application Execution Environment, v1.0, Open Forum, Jan. 2009; ATIS , Remote Management of Devices in the Consumer Domain for Services, Alliance for Telecommunications Industry Solutions, Mar. 2008; www. atis.org/docstore/default.aspx. 14. OMA Device Management Protocol, Version 1.2, OMA- TS-DM_Protocol-V1_2, Open Mobile Alliance, 9 Feb. 2007; _program/dm_v1_2.aspx. 15. ATIS , Secure Download and Messaging Interoperability Specification, Alliance for Telecommunications Industry Solutions, Mar. 2008; docstore/default.aspx. 16. ATIS , QoS Metrics for Linear Broadcast, Alliance for Telecommunications Industry Solutions, Aug. 2007; MultiSerive Forum, Application and Service Testing in Global Next Generation Networks, Global Multi- Vendor Interoperability whitepaper, Jan. 2009; www. msforum.org/interoperability/02-mgs81044-mfs _Whitepaper.pdf. Jun Shan Wey is with the research division at Nokia Siemens Networks. Her research interests include development of high-speed semiconductor lasers, WDM long-haul optical fiber communications, and set-top-box and middleware products. Wey has a PhD in electrical engineering from the University of Maryland, College Park. She currently participates in the ATIS IIF, ATIS NIPP-OAN, MSF, and FSAN Group. She is a senior member of the IEEE. Contact her at shan. wey@nsn.com. Joachim Lüken is with the research division at Nokia Siemens Networks, where he s responsible for the security aspects of its Home Entertainment solution. He has more than 20 years experience in telecommunications covering software development in digital public-switched telephone network switches to systems engineering for asynchronous transfer mode and IP-based products. Lüken has a Teacher Exam degree in mathematics from the University of Muenster, Germany. He has been active in the ITU-T and ETSI and participates in the DVB Project and the BBF. Contact him at joachim.lueken@nsn.com. Jürgen Heiles is with the research division of Nokia Siemens Networks, where he leads the standardization program. He has been involved in development, system engineering, and standardization of transport network technologies like SONET/SDH and Carrier Ethernet as well as in the standardization of. Heiles has a Dipl.-Ing. (FH) degree in electrical engineering from the University of Applied Sciences Rhineland- Palatinate, Germany. He represents Nokia Siemens Networks in the DVB Project and the OIPF Steering Group. Contact him at juergen.heiles@nsn.com. MAY/JUNE