TR-069 Brings Flexibility To DSL Remote Management

Transcription

1 TR-069 Brings Flexibility To DSL Remote Management by Mukesh Kumar Product Manager, Networking and Multimedia Gateways Residential Gateway and Embedded Systems Business, Texas Instruments Incorporated Although DSL is growing faster than any other broadband access method, access providers face hot competition from cable operators, satellite TV providers and even Internet service providers (ISPs). As a result DSL access providers are being forced to place a greater importance on operating efficiencies, even as they roll out new services such as IP television (IPTV) and bundled triple-play offerings for voice, video and data. While these new services generate greater revenue and attract more customers, they also extend DSL networks to a wide range of customer premise equipments (CPEs), potentially driving up service and support costs. Remote network management can help contain these costs by automating CPE configuration and updates and by minimizing the need for on-site technical support. In addition, remote management can give innovative carriers an edge in providing services, helping to bring in additional revenue. Unfortunately, legacy methods of network management are not sufficiently flexible or robust for the increasingly complex requirements of DSL networks. Service providers need new techniques to help them remotely manage, control, configure, troubleshoot and provision the network and CPE devices efficiently. DSL networks are different in nature from the transport networks that telecom carriers are accustomed to managing. DSL services involve operator-managed CPEs such as residential gateways (RGs) and set-top-boxes (STBs) that will, in turn, be connected to multimedia appliances, HDTVs, home theaters, DVD players, phone systems, personal computers, and eventually other types of CPEs that are not yet available. Consumers often turn to service providers for support when these devices malfunction. Though these support expectations may at times be unjustifiable, service providers still have to do whatever they can to accommodate their customers -- or risk losing them. Given that DSL access providers must be concerned about managing or monitoring consumer electronics connected to the RG, a remote management system must be able to identify and manage many different types of CPEs, some of them purchased in retail stores. Recognizing that DSL networks would be a new type of network incorporating elements of both WANs and LANs, the DSL Forum in 2002 issued TR-046, Auto-Configuration Architecture and Framework. In this standard, the Forum defines in general terms what a remote management methodology has to accomplish. TR-069, CPE WAN Management Protocol, issued two years later, defines the means of implementation of a part of TR-046. Other, complementary standards deal with related issues. For instance, TR-038 specifies the requirements for flow-through provisioning, and TR-104 for voice-over-ip (VoIP) terminal adapters.

2 Fig. 1: Auto-Configured Working Group Scope Technology based on the TR-069 standard fits into an encompassing framework that provides the means for achieving robust, flexible remote management in DSL networks. Although the new standard is accepted industry-wide, its implementations are still emerging. As a result OEMs and management software vendors are working to make their systems interoperate successfully. Management System Based On TR-069 Fig. 2: Scope Of TR-069 CPE WAN Management Protocol Fig. 2 is a simplistic representation of a typical network using TR-069 as a management system. The service provider network has a primary Auto Configuration Server and potentially many secondary servers. The secondary ACS servers might belong to entities other than the primary broadband connectivity provider. These ACS can communicate

3 with CPE devices via the broadband connection as well as to devices beyond the CPE inside the customer premise. As the name suggests, an ACS is supposed to be able to configure a CPE without the intervention of any personnel or the end user of the CPE or any device on the LAN side. So a CPE should require minimal customer interaction when it is powered up initially for service activation, and the network service provider (NSP) is not required to perform on site such tasks as service provisioning or upgrading. After service activation, or a later power-up, the CPE is able to fetch configuration information from the right NSP automatically. The standard foresees that in the DSL industry the NSP for IP services may be different from the network access provider (NAP) that supplies the wired connection. In fact, multiple NSPs may supply their services through the same NAP (Network Access Provider) and a single NSP may supply its services through multiple NAPs. A variety of NSPs may provide different services such as voice, video-on-demand, digital broadcast video, and Internet data; and a single residential customer may subscribe to more than one NSP through the same DSL line. The network architecture can become even more complex if subscriber networks exist. These might, for instance, link small enterprises at different sites via DSL, just as large enterprises are linked today by virtual private networks (VPNs).The system represented in the diagram allows nested autoconfiguration framework for WAN management that is able to work between the NSP and subscriber irrespective of the network architecture. NSPs also have the ability to provision new services non-disruptively, so that they can differentiate their offerings and enlarge the utility of the network. In addition the interface is simple and allows for easy additions to subscriber services, and reaches inside subscriber networks. The communication protocols used between the CPEs and the ACS is based on openstandard-based protocols to make the system modular and easy to develop. That provides additional maturity to the system by virtue of these individual protocols having been field tested already. Except for the CPE management application, which is designed by the software vendor, everything is industry-standard, open-protocol developed independently of TR-069. Future changes in the lower-layer protocols will not affect the applications built on the stack today. From the top down, the layers of the stack are: CPE management application RPCs (remote procedure calls) SOAP, using XML-based RPC with methods and parameters defined by TR-069 HTTP 1.1 SSL 3.0/TLS 1.0 TCP/IP

4 Different services and parameters have different levels of security assigned by vouchers or digitally-signed pieces of data. Security measures ranging from basic to advanced are built into the standard to provide confidentiality, integrity, authentication and service protection. In addition, several methods of integrating security are provided, including SSL- and HTTP-layer, off-the-shelf or NSP-provided, and shared secret or authoritycertified security mechanisms. The mode of security to be used during communication is configured. This includes changes in security keys or protocols selection. When the CPE comes on line, the ACS discovers it automatically; alternatively the user needs to provide on-line information by, for example, entering the NSP in a Web page. Since there may be several ACSs that can control a given CPE, so the CPE discovers the right ACS belonging to a particular NSP by using a Uniform Resource Locator (URL). The URL is stored on the CPE by default or it is supplied at that time via DHCP based on specific identifiers. The URLs are protected and cannot be modified locally, but the ACS can send the CPE a different URL after the initial contact in order to hand off control to a different server. This is the start of the auto-configuration process. The ACS in turn connects to a centralized service configuration management system to get CPE/customer specific SLAs (Service Level Agreements) and configuration information. This information is passed back to the CPE via the TR-069 protocol which sets up additional services on the CPE. The ACS can provision many CPEs (this helps the service providers to automatically control a group of CPEs) both initially, and at other times, using service-related parameters that may have vendor-specific extensions. In addition to the basic services themselves, parameters include firewall rules, quality of service (QoS) settings, or other features that extend the utility of the service. Provisioning can be asynchronous, allowing the NSP to change service line agreements (SLAs) at any time. The ACS recognizes CPEs either individually or as group based on vendor codes, model numbers, software versions, or other identifiers. To accommodate different business models, the NSP can register the CPE at service initiation or pre-register it before sale, with or without preconfiguration. As was discussed before TR-069 based management system allows for nested management architecture. To provide for the many possibilities of network connection, multiple ACSs belonging to different NSPs can handle the same CPE or set of CPEs. Since only one ACS can control a CPE at a time, there is a mechanism for handing over control from one ACS to another. Either the ACS or CPE can initiate the connection, and the same connection can support multiple transmissions, some or all of which can be bidirectional. Once this step is completed the CPE is completely up and running and the service provider has complete knowledge and control over the CPE. From this point onwards a different secondary ACS can contact the same CPE or devices behind the CPE to provision other services and configurations.

5 Since the functions of any given CPE may be extensive or limited, the ACS queries and discovers the CPE s capabilities from time to time. This also takes care of the possibility of a parallel provisioning systems (eg CLI/SNMP) changing the system s capabilities. In addition, the ACS allows other methods of configuration, such as LAN-side autoconfiguration, and it may add vendor-specific parameters and controls. Status and performance monitoring and diagnostics are a big part of day-to-day control done by service providers. The standard allows for both solicited and unsolicited notification of status and parameters and provides the necessary formats. Multiple protocols, including SNMP and UPnP, can modify the same parameter, giving the NSP wide-ranging visibility into the CPE s network status. There is also an identified set of diagnostic parameters to aid in troubleshooting for, example, change in IP address, VoIP call logs, system failures etc. Since the software running on the CPE may need periodic upgrades based on either newer services being provisioned on the CPE or even just bug fixes, TR-069 allows the service provider to do solicited or unsolicited firmware upgrades. Either the ACS or CPE can initiate a version-identified firmware download. The ACS supplies the CPE with an IP address for the file image and the required transfer mechanism, such as FTP or TFTP, and the CPE notifies the ACS of the success or failure of the transfer. The firmware, which can be authenticated and digitally signed for security, may be used for complete system upgrades, to fix bugs or patch, to provide different software for different levels of service, or for other purposes. Other provisions of the protocol take into account the functions of the management framework and its ability to integrate within a wide variety of deployed architectures. The remote management system works irrespective of the DSL access layer and is based on network layer connectivity. It uses existing standards and protocols and works on any existing network. Access methods are secure, and multiple access methods are permitted. Deployment Issues One of the primary strengths of TR-069 is its flexibility, though a flexible standard can also take time to solidify in the marketplace since it allows for a wide variety of implementations. While there are many vendors developing TR-069-compliant equipment, both CPE and ACS, these products are not necessarily interoperable. To address these problems The DSL Forum arranges for regular interoperability testing sessions called TR-069 Plugfest where all vendors making ACS and CPEs come together and test each others implementations. Though TR-069 promises a complete end-to-end management system vendors have realized they have to develop proprietary extensions to TR-069 to handle specific requirements of the Service Providers especially with regards to initial boot up,

6 configuration file upgrade methods, communication security modes and parameters, pass through to devices on the residential networks through the CPE etc. Without such extensions a broadband service provider will not get the necessary advantages of installing TR-069. This introduces interoperability problems between ACS and CPE vendors. In parallel to the DSL forum the ACS vendors have started having their own Interop Certification programs. The aim of these programs is to encourage the CPE vendors to approach the individual ACS vendors and get their product certified. Though this goes against the grain of a standard based approach, it is probably going to lead to faster deployment of TR-069. The use of TR-069 opens up question about managed and unmanaged services of the CPE. The end consumer might not want to provide complete control to the service provider just for privacy reasons for eg information about what ports have been opened up in the firewall. This separation is still being discussed in DSL forum. In short TR-069 as it stands does not have the capability to control everything on a CPE -- neither is that desired, and how to create this separation is still being discussed. There are many technical requirements currently being developed for devices and services residing on the residential network like ones for IP STBs, IP phone adapters etc. Enabling DSL Networks DSL access providers are facing a challenging time as network use transforms into something altogether new. TR-069, its TR-046 framework, and the related specifications from the DSL Forum all serve to lay the groundwork for managing a new type of network that offers applications that have been merely dreamed of until now. Establishing and maintaining robust control of retail-purchased CPEs from a variety of vendors will take some adjustment in the traditional WAN management scheme. The TR-069 specification takes into account the need for auto-configuration, flexible network architectures, ease of update, security and monitoring -- all occurring remotely in order to keep operator costs in line. The availability and ease of use of fundamental enabling technology has a direct impact on OEMs who are designing TR-069 CPEs, and it also indirectly affects NSPs and their customers. Proven DSP-based silicon solutions can enhance interoperability and support DSL network growth while helping to keep costs competitive. About The Author As a Product Manager for Networking and Multimedia Gateways in Texas Instruments Residential Gateways and Embedded Systems business, Mukesh Kumar manages the strategic direction of TI's Network Support Package, Audio/Video Media Engine, voice and echo canceller products. Prior to this rôle, Mr Kumar was the Software Team Lead for TI s Network Support Package development efforts. He joined TI in 2001 as a Software Design Engineer in 2001.

7 Mr. Kumar earned a bachelor degree in Instrumentation and Control Engineering from the Delhi Institute of Technology and a master degree in Electrical Engineering from Johns Hopkins University Mr Kumar may be reached at mkumar@ti.com