You are on page 1of 2

Remote management of non-TR-069 UPnP end-user devices in a private network

B.A.G. Hillen, I. Passchier, B.H.A. van Schoonhoven, F.T.H. den Hartog


TNO Delft, The Netherlands Frank.denHartog@tno.nl
Abstract End-to-end broadband service delivery requires remote management of devices in the home network, beyond the home gateway (HG). The service provider can only put limited requirements to these of-the-shelf devices, and therefore has to make intelligent use of their given control and management protocols. We developed a demonstrator for the remote management of Universal Plug and Play (UPnP) devices in the home with a simple TR-069/UPnP proxy on the HG. It shows how UPnP devices can be discovered, configured, controlled and monitored with a legacy TR-069 auto-configuration server. Keywords: distributed network protocols for multimedia, home gateways, device discovery, auto-configuration, remote management, TR-069, UPnP.

with service providers. Its primary capabilities are secure autoconfiguration and dynamic service provisioning, software/firmware image management, status and performance monitoring, and diagnostics. TR-069 defines Remote Procedure Calls (RPCs) and, importantly, also standardizes the data model of the HG in TR-098 [4]. Another advantage of CWMP is that the management server as well as the managed devices may initiate a TR-069 management session. Until recently, management of end devices behind the HG was mainly local, and based on the use of control protocols such as UPnP. Although these control protocols are meant for real-time functions such as connection control, session control, service control, signalling, resource discovery and resource management, they are sometimes also used for typical nonreal-time management functions, such as fault management, configuration management and security management. Other end-device management is often based on vendor-specific web services and a pull model: the end device must initiate the management session. Since a couple of years, Broadband Forum investigates the use of CWMP for remote management of end devices behind the HG, in the private network. However, vendors of UPnP devices (mostly consumer electronics) have relatively low margins per device and are therefore not interested in adding another web-services protocol stack like TR-069 just for the sake of remote management. They rather extend UPnP with more advanced remote management services. III. REMOTE MANAGEMENT OF UPNP DEVICES WITH CWMP

I.

INTRODUCTION

Broadband modems are becoming more intelligent, and are now often called Home Gateways (HGs). Despite the increasing complexity, service providers want to guarantee end-to-end service quality, not only for services delivered to officially provider-supported HGs and end devices in the home, but also to devices that the customer buys of the shelf, and preferably without extra help-desk calls or truck rolls. This is not an easy task, because the home network will remain as technically heterogeneous as it is today, or worse. This does also concern a manifold of control and management protocols. Many standard development bodies are currently initiating the first working groups tackling this topic, for instance Home Gateway Initiative, Broadband Forum, Universal Plug and Play (UPnP) Forum and the European Telecommunications Standards Institutes Telecoms & Internet converged Services & Protocols for Advanced Network (ETSI TISPAN). The demonstrator proposed in this paper shows how end devices supporting the ever more ubiquitous UPnP control protocol [1] can be remotely managed by a service provider with Broadband Forums Customer premises equipment Wide area network Management Protocol (CWMP, often just called TR-069) [2], without requiring major changes to the end device. This demonstrator has been mentioned in a paper to be presented at the IEEE CCNC 2009 [3], and will also be shown during the CCNC 2009 tutorial on Remote Management. II. REMOTE MANAGEMENT OF CPE

UPnP and CWMP are based on similar architectures. Both use Simple Object Access Protocol (SOAP) for control. CWMP uses a single SOAP message for discovery and description. In UPnP this is a two-step process, involving Simple Service Discovery Protocol (SSDP) multicast messages for the discovery and SOAP for the description. For eventing, UPnP uses Generic Event Notification Architecture (GENA) instead of SOAP. But the most important difference is the fact that, on the whole, UPnP standardizes control actions, whereas the TR-069 data models deal with management actions. For remotely managing UPnP devices there are three basic architectures to choose from. The first one assumes all intelligence in the public network and requires no or little changes to the end user devices and the HG, for instance by tunneling all UPnP messages through the HG directly to the Auto-Configuration Server (ACS). However, this architecture

For remote management of HGs, web-services based management with CWMP is currently gaining wide acceptance

978-1-4244-2309-5/09/$25.00 2009 IEEE

causes a lot of overhead traffic in the access network. It also needs a permanent management tunnel to be maintained, a UPnP interface to be implemented on the ACS, and it only provides the service provider with the limited management features that UPnP defines today. Last, but not least, the service provider will receive many messages, and therefore the responsibility to act upon them. A second approach assumes the availability of powerful HGs running a complete CWMP/UPnP bridge. It does not need a tunnel to be maintained and reduces the overhead traffic slightly, but does not relieve the service provider of his undesired extra responsibilities, nor provide him with extra management functionalities. Furthermore, the ACS needs to be extended with a UPnP management operations module and, because of the heavy requirements on the HG, this architecture cannot easily be applied to other HG protocols also. The architecture we propose consists of a much simpler CWMP/UPnP bridge on the HG, and an extension of the UPnP Device with a, to be defined, UPnP Configuration Management Service (CMS). The bridge only translates the CMS related messages into CWMP. The advantages are clear: the resource requirements on the HG are small, the overhead traffic on the access network is limited to the bare minimum, the provider only receives the messages he is interested in, the end devices can be managed as if they were CWMP devices, and the ACS needs only minimal extension. The only disadvantage is the need for a UPnP CMS on the end device. However, for the manufacturers this is a much lesser requirement than having to implement a double protocol stack. To validate our architecture, we built a proof-of-concept demonstrator containing three Pentium IV PCs running Linux OS. The ACS (PC1, with Dimark ACS software) is connected via the Internet, the HG (PC2), and an Ethernet LAN to a UPnP end device (PC3). The HG contains a Dimark CWMP client and a Philips UPnP Control Point (CP), with a bidirectional API as shown in Fig. 1a. The UPnP end device is running the standard UPnP Basic Device exposing a CMS containing two configurable parameters mimicking set-top-box functionality. Other parts of the implementation concern the protocol transversion of UPnP GENA event messages into CWMP SOAP eventing, and the transformation of the two-step UPnP discovery and description process into a single CWMP description. The latter is shown in Fig. 1b. With steps 1-3, the UPnP device announces his presence to the HG using SSDP. The HG then asks the device for its parameters (4-5), turns the received parameters (6-7) into a data model object (8), and communicates it to the ACS (9-10). The demonstrator consists of two laptops interconnected with an Ethernet cable. One laptop represents the HG and the other a UPnP set-top box. The ACS is at the premises of TNO in the Netherlands, and the HG communicates with it via Internet. The web interface of the ACS runs on a third laptop. The first step of the demonstration is turning on the CWMP client on the HG. It results in the ACS discovering the HG and correctly showing its data model in the ACS web interface. This is normal TR-069 functionality. Then we turn on the UPnP client on the set-top-box. This results in the HG discovering the device and showing the discovered information

about the set-top-box in a command-line screen on the HG. This is normal UPnP functionality. Additionally, thanks to the TR-069/UPnP bridge on the HG, also a new set-top-box object and its two parameters appear correctly in the web interface of the ACS, proving correct bridging of discovery and description functionality of the bridge. Modifying a parameter value of the set-top box in the ACS then leads to an automatic change of the corresponding parameter value as shown in the command-line interface of the set-top box. This proves correct control functionality of the bridge. Changing a parameter value directly in the interface of the set-top box results in a corresponding change in the ACS, and stopping the UPnP client on the set-top box automatically removes the corresponding data model object from the HG and the ACS, proving correct eventing.
GetDataModel() GetParameterValues() SetParameterValues() AnnounceDevice() CWMP client UnAnnounceDevice() ValueChanged() Subscribe() UnSubscribe() HG UPnP CP

3
CWMP

2
UPnP

1
UPnP End Device with Remote Management Service

ACS 10 9

CWMP client 8

4 7

UPnP CP

5 6

HG

a)

b)

Figure 1. a) Application Programming Interface (API) between the HGs UPnP CP and CWMP client b) Turning the 2-step UPnP discovery and description process into a single CWMP description.

For the demonstration, we need space and powering for three laptops and an Internet connection with public IP address. IV. CONCLUSIONS

We described a proof-of-concept for the remote management of UPnP devices with a TR-069/UPnP proxy on the HG. The main advantage of the chosen architecture is the spread of intelligence over the system. The ACS only needs limited extensions and does not need to function as a control server. The proxy implementation is very simple. The end devices may need an extra remote management service to be added, but not another protocol suite. ACKNOWLEDGMENT We thank the Technische Universiteit Eindhoven and Philips Consumer Lifestyle Innovation Laboratory, also in Eindhoven, for their help in analyzing the concept and building the demonstrator. We acknowledge Dimark for providing the TR-069 server and client software. REFERENCES
[1] [2] [3] UPnP Device Architecture 1.0; www.upnp.org, July 2006. CPE WAN Management Protocol v1.1, TR-069 Amendment 2, www.broadband-forum.org, December 2007. A. Delphinanto, T. Suters, B.A.G. Hillen, I. Passchier, B.H.A van Schoonhoven, and F.T.H. den Hartog, Remote discovery and management of end-user devices in heterogeneous private networks, Proc. of the 6th Annual IEEE Consumer Communications and Networking Conference (CCNC 2009), Las Vegas, January 2009. Internet Gateway Device Data Model for TR-069, TR-098 Amendment 2, www.broadband-forum.org, September 2008.

[4]