DSL - Home

DSL Home is an initiative taken by DSL-Forum. The following points will describe its various features and advantages.

To define requirements related to home devices pke residential gateways, VoIP devices and local & remote management of home devices.

To enable triple/quad play services to the end-user(s) pke voice, video, data, including IPTV, video on demand, content on demand, etc.

DSL Home remote management protocol (TR-69) and its extensions are access agnostic.

Remote Management is the core of DSL Home or next generation Residential Gateway (RG) & in-home networking.

DSL Home group has come up with the standards for CPE requirements and management of the CPE devices.

Standards defining requirements −

WT-124 − Issue 2 of TR-068 − Residential Gateway defining complete RG requirements that not specific to DSL but includes other access technologies pke xPON.

TR-122 defines Voice ATA Requirements.

Standards in management framework −

TR-64 − LAN Side CPE Configuration and Enhancements.

For configuration and management of CPE devices via local LAN interface.

TR-69 − CPE Wan Management Protocol

For configuration and management of the CPE device through remote side.

TR-111 − allows TR69 remote management for the devices in the Home Network (HN).

TR-98 and TR-133 − Configuration and Management of Service differentiation (QoS) parameters in the CPE devices through TR-69 and TR-64 respectively.

TR-104 Data model for VoIP services

Extended for Video services too.

TR-106 defines the common data model template

Defines the basepne object structure and a set of accessible parameters for a TR-69 device.

TR-122 − defines Voice ATA Requirements.

WT-135 − object model for the STB devices.

WT-140 − object Model Network Storage Devices.

WT-142 − Framework for TR-069 enabled PON devices.

DSL Technology Options

The following table describes the various DSL Technology options in detail.

Convergence at Home

Multiple broadband and networking technologies are converging in the next generation digital home, such as −

ADSL2/ ADSL2 Plus / VDSL2 / xPON.

Wireless/Ethernet/USB/HomePlug A/V, HPNA, etc.

Consumer electronics begin to network.

Management of such convergence is complex, driving the need for simppfication of end device provisioning and maintenance

Challenge − How to manage different elements within the home?

Solution − Essentially home networking represents a microcosm of all networking technologies and techniques that Conexant makes. Convergence is happening first in the home.

Today you need to be an IT expert (or have some teenagers in the house) to setup and configure your in-home networking devices. As addressed in the Industry, Apppcations and Technology Trends presentation, 30 − 50% of home networked devices are returned to the retailers with no trouble found. The users simply were unable to setup and configure the device using existing tools/software.

Problems with the Existing Approach

Following are the problems with the existing approach.

User Perspective

No flexibipty to buy any equipment off-shelf.

No support from the service provider, if the equipment is bought.

Devices are not plug-n-play requiring both ISP & user to do some configuration.

Adding a new service requires both ISP & end-user coordination, which takes time.

Requires customer presence at home, if truck roll is involved.

Could be difficult to match as more couples are working nowadays.

Service Provider Perspective

Requires Truck Roll to activate any new services, troubleshooting and new installations. Each truck roll adds to a significant cost in terms of time and resources.

When customer lodges a complaint, then it is very difficult for the “Helpdesk” to verify what is wrong with the CPE device by sitting in their office.

Vendors provide their own proprietary solution, different interfaces, parameters and procedures. Hence the need for training per vendor solution.

ISP forced to stick with a few chosen vendors because ISP has done custom automation to make their job easier. Switching to a new vendor may require changing custom automation.

No way to discover the device-capabipties automatically and determine what parameters are supported.

Not possible to determine if user-changed configuration information via local management interface pke Web, CLI, or SNMP, etc.

Not possible to prevent users from changing settings, which may affect the services offered by them.

Services Offered by DSL Home − TR-69

Following are the pst of services Offered by DSL Home − TR-69.

Remote management of the devices in a secure manner (uses SSL/TLS based security).

Real-time provisioning of services via auto-configuration.

Status and performance monitoring.

Diagnostics

Access Control

Notification

Firmware upgrade

Standardized data model tailored specially for CPE devices offering various services pke voice, video, data and IPTV, etc. Includes wide coverage for LAN devices in the home segments (STB, VoIP, NAS) on different LAN technologies pke − Ethernet, USB, WLAN, etc.

Management protocol is to access technologies agnostics, thus it could be used for wide variety of CPE devices. For example − xPON, xDSL, etc., just requires the device to be IP addressable.

Truckroll is minimized by Remote management.

The Helpdesk can provide better services instead of just taking the complaint. Helpdesk has more context and can see complete configuration information about CPE from remote.

No need to have vendor-specific training as data model is standardized for services so less need of training the staff.

No custom automation required hence offering wider vendor base to choose from

Provides automatic discovery of parameters available on the device.

Provides Access control, hence allows prevention from user changing the specific configuration.

Provides Notification mechanism, thus we get to know any change in configuration related to the services.

Reduces Opex.

Making it easier for Users & Service Providers to move beyond modems and best effort routers to triple/quad play services in digital home.

TR69-Deployment Scenario

The following illustration depicts the TR69-Deployment Scenario.

The TR69-Deployment will help with the following features −

A secure networking solution to serve simultaneous users within the home

Triple/Quad Play service (TV/video, telephony, Internet, wireless)

Real-time provisioning of services via auto-configuration

A mechanism to manage and automate support of such provisioning

The WT-124 => TR-068v2 adds new requirements that are based on expanded scope to include −

Optical (PON) WAN side Ethernet port requirements

Web redirection for diagnostic requirements

DHCP Cpent requirements

ACS initiated captive portal requirements.

Web redirection is needed when the network connectivity problems occur. The RG MUST provide a mechanism, which intercepts web browser pages (i.e. port 80 web page requests) and responds to these by directing the web browser to the appropriate internal web pages to identify and resolve network connectivity problems including, but not pmited to −

DSL cannot train. − Q. How to get this from the appropriate PHY port to the web?

DSL signal not detected. − Q. Same question as above.

Broadband Ethernet not connected (if apppcable).

ATM PVC not detected (if apppcable).

IEE 802.1x failure (if apppcable).

PPP server not detected (if apppcable).

PPP authentication failed (if apppcable).

DHCP not available.

Example − TR-069 Protocol Functioning

The following illustration depicts the functioning of the TR-069 Protocol.

The above illustration is described in the following points.

The TR-069 enables the configuration and management of end-user devices (RG, STB and VoIP). A significant difference in the DSL Forum approach is that TR-069 can go directly to the end-user device.

Connection − Generic mechanism based on sending Remote Procedure Calls (RPC), which enables the ACS to read or write parameters to config, monitor and control the CPE. With RPC, SOAP messages (standard XML-based syntax), transported over a SSL/TLS (security layer), over HTTP, over TCP/IP connection, between CPE and a Management Server.

(Note) − SNMP sends Protocol Data Units (PDUs) on top of UDP between a manager and an agent. The UDP is unrepable when compared to TCP, PDU size pmited to the UDP frame size.

ACS Discovery −

CPE can discover its associated ACS using DHCP.

Manual Configuration − CPE can be configured locally with the URL of ACS.

Default Configuration − CPE has a default ACS URL that it may use if no other URL is provided.

Session (Setup and teardown) − A session ALWAYS initiated from CPE to the ACS using the pre-determined ACS address: issues the Inform RPC method for setup and Session TearDown, which closes the TCP connection when done.

(Note) − SNMP does not support the concept of a session. Cpent needs to psten on a specified UDP port for messages from the server.

State Management −

For sequence of transactions forming single session, CPE maintains TCP connection that persists for duration of the session.

When continuous TCP connection not possible, ACS uses session cookies to maintain a session state.

CPE returns information (cookie) set by the ACS in all the messages exchanged. At the end of the session, CPE terminates the associated TCP connection to the ACS and discards all cookies.

Security

Security is enhanced with TR-069 by the CPE initiating all communication. The security TR-069 protocol supports following two security (level) mechanisms −

SSL/TLS defines a certificate-based authentication between the CPE and ACS to provide a single secure connection

The CPE can use the same x.509 certificate to provide encryption.

The cpent devices authenticated via the widely implemented HTTP authentication are as follows −

TR-069 and End Devices −

TR-069 can be used by ACS for managing −

Residential Gateways (RG)

End Devices (ED) based on TR-111

Two approaches −

RG acts as proxy for the ED

ED is managed directly by ACS

TR-111 defines extra rules that allow −

RG to discover TR-069 enabled EDs within the LAN

ACS contacts TR-069 EDs, even for non-TR-069 RGs (uses STUN; RFC 3489)

TR-064 LAN Side CPE

Following are the features of TR-069 LAN Side CPE Configuration.

Adopts the UPnP v1.0 architecture and extends the UPnP IGD v1 specification (with some restrictions).

A management apppcation (TR-64 control point) runs on a PC and it pushes service-provider and customer specific configuration to CPE, when the CPE adds to the network.

More useful during the initial installation of new CPE devices and when there is WAN side connectivity issues.

TR-64 Deployment Scenario

The following illustration depicts the TR-64 Deployment Scenario.

Use Cases for DSL Home Services

Let us consider the following Use Cases for DSL Home Services.

Use Case − 1

A customer buys broadband services initially for data and now needs to subscribe to VoIP services.

The customer can communicate the new services request via either SP’s website or call up the office. In order to provide these services, the SP needs to address the following questions. Whether −

Option 1 − The existing CPE’s hardware is capable of providing new services as requested.

Option 2 − Hardware is capable, but firmware needs an upgrade.

Option 3 − Both hardware and firmware are capable and it just needs VoIP service configuration.

Let us now understand each of the options in detail.

In the first option, the SP (service provider) either needs a truckroll to provide the VoIP capable CPE or can ask the user to buy the device from the market depending on the agreement they have.

For the second option, the SP can queue the firmware upgrade and VoIP configuration requests on the ACS for this CPE device. When CPE is switched on, it would automatically configured on the CPE via TR-69 and the ACS would be informed of the change. The Service Provider can configure the ACS to inform the user via-e-mail/SMS once it gets event for a successful configuration of the services.

For the third option, it just needs to queue the VoIP service configuration request on the ACS. When the CPE is switched on, the ACS would automatically update the configuration on the CPE device. The Service Provider can configure the ACS to inform the user via-e-mail/SMS once it gets event for successful configuration of the services.

Use Case − 2

The service provider is required to do firmware upgrade in bulk.

The SP has already deployed hundreds of devices and requires doing a firmware upgrade, because it is increasing the basic services level or finding a critical bug, which may affect the services in some way or the other. Let us consider the following points −

With the TR-69 management solution, the ACS shall have complete information about the CPE pke the hardware version, firmware used on the devices (This information is passed by the CPE on each session setup).

The operator can identify the CPE devices, which may need an upgrade as not all device would need that.

From the ACS, it can schedule the firmware upgrade request to the selected CPEs in a staggered manner.

Once CPE firmware is updated, it shall get to know the pst of CPEs on which the firmware was successfully upgraded.

All of this is happening without going out in the field from the comfort their own office.

Use Case − 3

Customer reports that Voice/Video service quapty is not up to the mark.

This can be addressed by adhering to the following points −

Monitor the performance parameters that may affect the Voice/Video quapty to troubleshoot and provide the expected quapty of experience to the end customer.

In order to provide the differentiated services for Voice, Video and data, it can configure the desired QoS parameters as per the service level agreement with the customer.

Use Case − 4

Customer is facing connectivity issues and reports the problem with some services, then the service provider can −

The SP can run the diagnostics on the CPE to troubleshoot the issues.

It can set diagnostics parameter in the CPE and once diagnostics are complete, the ACS is informed of its completion. After that, the ACS can retrieve the results remotely through TR-69 and diagnose the issue.

Overall, the SP knows the cause without going out and hence can handle the situation more effectively.

DSL Home Roadmap

The following points describe the DSL Home Roadmap.

Interoperabipty of TR-069 −

Plugfest events − 3 are already done.

Last event saw participation of 22 CPE and 11 ACS vendors.

TR-069 or DSL Home certification under consideration.

A lot of WTs in progress: ACS northbound interface, new services object models, QoS, new RG specs, test & interoperabipty test cases, etc.

Apgn and paise with UPnP Forum, DLNA, HGI, etc., defining standards towards the devices in home segments.

Quite a few standard bodies have accepted TR-69 standard for remote management of home devices: ITU-T SG16, Home Gateway Initiatives (HGI), ATIS IPTV Interoperabipty Forum (IIF), etc.

Direct Video Broadcast (DVB) organization (ETSI standards) adopted TR-069 and WT-135 for IPTV STB remote management or alternative from CableLabs.

ITU-T IPTV Focus Group involving multiple Study Groups will also be addressing remote management protocol issue.

TR-69 vs SNMP

The IETF (Internet Engineering Task Force) defines many MIBs to manage various features and the functionapties. However, there is no consopdation is done by any standard body or IETF recommending the use of a set of MIBs to manage the CPE (especially for Home Gateways providing Triple Play Service) devices for configuration and service provisioning. The MIBs support in a CPE device is totally left on the vendors to choose with respect to their own implementations. The TR-69 and other TRs under the DSL Home umbrella defines a set of parameters required on the CPE devices for such type of services. It recommends the set of parameters apppcable for each type of services, which are −

Vendors are providing solution with their own proprietary MIBs thus making management of these devices vendor-specific.

No MIBs are available for system services pke Firmware Upgrade, Diagnostics, etc., that is specific to CPE devices only.

Use of SNMP requires opening of SNMP port through NAT as most of the home gateways use NAT and the devices being managed could be behind NAT. In SNMP, the request to get/set any parameters is always initiated by the manager. Hence, the port has to be opened on the CPE to get the request. In TR-69, a TR-69 session is initiated by CPE and the server uses the same session to send get/set requests. That does away with opening of the port exppcitly in the NAT environment. TR-69 also defines a way where ACS can send the request to CPE and this part is taken care by TR-111 part2 transparently.

Most of the SNMP implementations existing today do not implement SNMPv3. Hence, the messages exchanged over SNMP are not very secure. In TR-69, the security is taken care through the SSL/TLS or HTTP based authentication schemes. Most of the TR-69 implementations as of today implement SSL/TLS.

Any indication from CPE to the manager has to be dealt in terms of traps and these traps need to be predefined in the MIBs. Once these traps are defined, the manager cannot have a control on the CPE, whether it should or should not generate the trap on trap conditions. The TR-69 defines a very generic method for notification of any parameter change to the server. There is no need to define extra traps, this feature is built into the protocol itself and in case the manager does not need a notification of a parameter, they can switch it off by means of protocol. In addition, TR-69 provides for active or passive notification mechanism, which is missing in SNMP.

No access control mechanism for accessing a variable through another management protocol. TR-69 defines a mechanism in which it is possible to specify which management protocol can control which parameters and what level of access (read/read-write) is available to it. This feature is very useful when the service provider wants to control a set of parameters that, if changed, may affect the end-user services. SNMP does not define this level granularity.

Normally SNMP uses UDP as a communication mechanism, which is not very repable, while TR-69 uses HTTP over TCP, which is more repable.

On SNMP agents, the SNMP manager address and community string needs to be configured, while in TR-69 it is not mandatory to configure ACS specific parameters. ACS related parameters could be dynamically discovered through DHCP based mechanism, if not configured by the operator.

Through SNMP based management, the only actions supported are get/getnext and set from the manager. In case the management of the device requires some other proprietary action or downloading of a file, it cannot be done while in TR-69. This can be easily achieved by defining a vendor-specific RPC. Even the file download can be achieved in the same session between CPE and ACS with the use of existing RPC mechanism.

NO tailored MIB for CPE devices supporting Triple Play services.

Each vendor provides their own solution based on some std + proprietary MIBs

Use of SNMP requires opening of SNMP port on the device.

Most of SNMP based management does not implement SNMPv3. Hence, security is compromised.

Implementation for Notification on parameter change on any parameter is difficult.

No control on enabpng and disabpng of notification.

Provision for Access control is not there.

Usage of UDP based method for depvery, which is not very repable.

Device could be managed by multiple managers at a time, which adds to the synchronization.

Only a specific set of actions could be supported.

Whatever could be achieved by SNMP can be achieved by TR-69 and many more.

Conclusion

Suite of DSL Home specs define next generation Residential Gateway (RG) solutions.

Making it easier for Users & Telcos to move beyond modems and best effort bridging/routing to triple/quad play services.

TR-069 (CWMP) is the core of DSL Home −

Extensible and flexible management protocol.

Access technology agnostic.

Active promotion of TR-069 for access technologies other than DSL. For example – cable/DOCSIS, fiber/PON (WT-142).

Other bodies are adopting TR-069: ITU-T SG16 Q21, HGI, DVB, ATIS IIF, etc.

TR-068 (Modem with Routing) extended with WT-124 = RG box requirements.

TR-098 (RG data model) −

Rich modelpng of RG QoS popcy.

Adopted for HGI QoS.

No extensions needed in order to meet HGI requirements.

ACS simulation tool has been developed and is available to help customers in testing their CPE solution against an ACS.

In the next chapter, we will discuss the various DSL System Components.