JAVA SOFTWARE DEVELOPMENT KIT (SDK) FOR UPnP CONTROL POINT Hicham El Akkaoui, Tajje-eddine Rachidi, Wadie Mernissi, Khalid Loudiyi, and Ibrahim Al-Bahadly Al Akhawayn University in Ifrane, PO.BOX 1881, Ifrane 53000 Morocco Abstract 2. UPnP Universal Plug and Play (UPnP) is a protocol proposed by Microsoft to take over the growing market of home networks. UPnP enlarges the scope of the well-known Plug and Play (PnP) protocol for peripherals to include home appliances, devices, and anything that can be connected to a network. Unlike most of its competitors, UPnP achieves real language and platform independence by leveraging of well established technologies such IP and Web services (XML/SOAP and XML/GENA) for transporting messages between devices and controllers around home networks. To date there are no Java Software Development Kits (SDKs) available for developers of Smarthome and home automation applications based on UPnP. This paper describes the design and architecture patterns for a UPnP Control Point SDK implementation in Java intended to compensate for this lack. The SDK is UPnP compliant, and offers the necessary services for Java developers of UPnP compliant applications. The paper also describes implementation details as well as verification and validation tests. Key Words: UPnP, Home automation, Java SDK, Smarthomes Universal Plug and Play is an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all kinds[5]. It has been designed to support zero-configuration networking. That is devices and controllers, called Control Points1 in the terminology of UPnP, can join the network, get an IP address, communicate with each other, then leave the network without the risk of having side effects or unwanted states. The UPnP protocol gets its strength from reusing well-known and deployed protocols in the Internet world; namely UDP/TCP/IP, HTTP, XML, and SOAP commonly known as Web services. This choice enables UPnP to be media-independent, since IP networks are nowadays running on almost all media types (twisted pair, power-line, radio frequencies, infrared, etc.). It also allows UPnP to be language and platform independent contrary to most of its competitors. The UPnP interaction process between devices and Control Points consists of five phases [1]. Each device or Control Point compliant with the protocol must implement at least the four lower phases which are Discovery, Description, Control, Eventing, and Presentation. 1. Introduction Universal Plus and Play [1] is a new lightweight protocol, proposed by Microsoft, to extend the well known concept of Plug and Play to cover wide variety of devices, appliances and services, such as cameras, VCRs, alarm clocks, DVD Players, dish washers, fridges etc (see Figure 1). By proposing this new protocol, Microsoft tries to invade the growing market of home networking. Microsoft is not the only player in this market, X10 Corporation [2], with its X-10 propriety technology has been the leader for mo re than two decades by proposing low-price and easy to install products. Echelon, through its LonWork [3] technology has been targeting automation in industrial plants. Finally, Sun through Jini technology [4], which showed almost at the same time as UPnP, is also a serious competitor to UPnP technology. UPnP uses open standard protocols. Other technologies can too participate in the UPnP network through a UPnP bridge or proxy. Wireless Access Point TP cable or power lines 802.11x Wireless Access Point Figure 1. Typical UPnP home network. During Discovery, the devices on the UPnP network advertise themselves and their services. 1 These could be standard PCs, PDAs, and/or Remotre controls These are picked up by Control Points present on the same network 2 . Devices regularly send Simple Service Discovery Protocol (SSDP) messages on the multicast address 239.255.255.250 and on port 1900. Control Points listen on this address/port to detect the presence of active devices. A Control Point can also discover devices by sending search requests on the same address/port. Devices present on the network must reply to the specific search request sent by a Control Point. To minimize network traffic during the Discovery phase, devices do not advertise the details of their capabilities: SSDP messages are lightweight, and do not contain details of the services embedded in a particular device. During Description phase, Control Points fetch detailed device descriptions from the URLs specified in Discovery messages. Device descriptions are expressed in XML, and contain detailed information about the device, its services and any other embedded device, it may contain. A Control Point can then fetch descriptions, also in XML, of the different services of a device (and of any embedded device) in order to get all the information needed to interact with/control this device. During Control phase, a UPnP Control point uses control messages expressed in XML using the Simple Object Access Protocol (SOAP) to request service/action from a particular device. The device, then, returns the result of the action performed or replies with an error message, also expressed in XML. The fourth phase is Eventing. In this phase, a Control Point can subscribe to evented services of a device so that when the state of the device changes, the later notifies all subscribers (Control Points) of the change. Eventing uses XML messages formatted in General Event Notification Protocol (GENA). 3. UPnP Java SDK Design and Implementation The design of the UPnP Control Point SDK is directly derived from UPnP specifications. That is, the SDK consists in Java packages where each package is in charge of a single phase of the protocol. In order to deliver asynchronous responses and messages received from devices, e.g., advertisement, to user application two design options were possible: The first one consists in using Java interfaces. The discovery package, for instance, would define an interface with a method say newAdvertisement. The user would have to implement this interface in his/her classes. When a new advertisement is received the SDK calls this method from the user implementation. This design introduces high coupling between user and SDK classes, as well as forces the use of some specific names for methods. The second design option consists in using Model-View Controller (MVC) [6] design pattern. The user creates Java objects of type Observer [6] and passes them as arguments when initializing the SDK classes. The discovery package, for example, contains an Observable [7] object to which the Observers will be added. Whenever, an advertisement is received, the Observable notifies all subscribing Observers. This approach allows a complete separation (thus a loose coupling) between user and SDK classes , and at the same time provides enough flexibility for the developer, while allowing for enhancements and future UPnP protocol modifications. The user can add as many Observers as needed by the application without any limitation whatsoever. This is the design we adopted for the SDK. Figure 2 shows the package structure as well as SDK/user application interaction for this design. Last is the Presentation phase. This phase is optional, in the sense that a device can have a presentation URL that Control Points present in the network can retrieve and use to control the device. Control Points can also implement their own presentation based on the information they retrieve during previous phases. This paper describes the design, implementation, and validation of a Java based UPnP Control Point SDK that allows developer to quickly build home automation applications, focusing on added value control functionality and on user experience; without having to worry about the underlying end-to-end communication protocols, and formatting of messages between devices and Control Points. The SDK is intended to be used by developers of control applications for Personal Digital Assistants (PDAs), Smartphones, and standard PCs. 2 A separate gateway specification for b ridging UPnP networks exists. This issue is outside the scope of this work. Figure 2. UPnP Control Point SDK package structure. In this design, user application packages are completely separated from SDK packages: The “ui” package represents a generic application built using our SDK. The communication between user package and SDK package goes through a proxy class called controller an instance of which is instantiated by “ui” objects. Calls from the “ui” to the SDK classes follow the traditional function call procedure. For instance to invoke an action on some device, the “ui” calls the controlAction method in the control.ControlAction class3 ; this method will set the OUT variables of the action invoked, which the “ui” will retrieve as results of the action. Due to their inherent function, some parts of the SDK need to run permanently when an instance of the Control Point is lunched (by instantiating a proxy object of class controller). The cleaner object (in utils package), for instance, periodically scans advertisement repository looking for obsolete ones to delete. It is also the case of the callback server, to which event notifications are sent. Those parts are implemented as concurrent Java Threads [8]. Good care has been taken when implementing concurrent objects, to avoid race conditions (between cleaner and discoverer for instance). Moreover, in implementing the design, we have paid careful attention to portability of the SDK to mobile devices such as PDAs, and Smartphone environments. To this end data structures have been designed to minimize the SDK memory footprint. The current me mory footprint of the SDK is 12Mb including the JVM (Java.exe). The current implementation of the SDK is compatible with both Sun’s JSE 1.4 and J2ME. 4. Verification and Validation In order to validate the correctness of the SDK, a sample GUI-based control application was developed using our SDK. This control application was launched on a standard PC running Sun’s JRE 1.4. A battery of tests was conducted using this application and two (2) different devices to check the validity of each of the phases of the UPnP protocol SDK implementation. Both devices attach directly to a LAN. The first device is an emulation of an X-10 lamp from Siemens AG [9] developed using Siemens UPnP Device SDK4 . Tests conducted with this device were intended to verify the compatibility and interoperability of our UPnP Control Point SDK with other device SDKs (Siemens in this instance). The second device is a UPnP enabled security camera, Axis Network Camera 2100 [10-11]. This device gave us the opportunity to perform tests with real third party UPnP-enabled products. Tests with both devices consisted ni verifying all the phases of the UPnP process. Starting with the Discovery 3 Controller class contains all necessary get methods to access the different package objects. 4 Contrary to a Control Point SDK, a Device SDK is for building UPnP enabled devices. phase, the control application successfully found both devices using the asynchronous search. It also successfully detected the presence of either device when newly connected to the network, and announced it self. The control application also successfully fetched descriptions of the devices and their corresponding services. Further tests consisted in performing actions (switch on/off, start stop etc.) retrieving states (On/off, started/stopped) and on receiving notifications upon changes in device states. The Control Point SDK successfully passed all tests with both devices . 5. Conclusions and Future Works Combining the power of UPnP, and the advantages and wide spread of Java technology can lead to the creation of high quality UPnP products that will impose themselves on the market of embedded networking. In this paper we have presented the design and implementation of a Java SDK for developing control applications for smarthomes. Our efforts are now focused towards 1. Developing a Java UPnP Device SDK that will help enable more embedded devices. 2. Porting the current SDK on leading Java enabled PDAs and smartphones such as iPAQ h5455 and Motorola T725. 3. Developing user experiences for these handhelds as well as core rule-based control engine. 4. Developing learning capabilities for user control profile for high added value personalized home control system. References [1] Understanding Universal Plug and Play: A White Paper, Microsoft, 2000. [2] X10 FAQs, http://www.x10.org/x10faq.html. [3] A LonWorks Technology Tutorial, http://www.connect.nl/tutorial/con_tut.htm. [4] Muthaiyan Chitrarasu, Jini by Example, California Software Labs, May 1999, http://www.cswl.com/whiteppr/tutorials/jini.html. [5] Universal Plug and Play Device Architecture, Microsoft, June 2000. [6] Steve Burbeck, Applications Programming in Smalltalk -80(TM): How to use Model-View-Controller (MVC), University of Illinois at Urbana-Champaign, 1992. [7] Java Documentation, Observer/Observable, http://java.sun.com/j2se/1.4.1/docs/api/java/util/Observabl e.html. [8] Java Document, Java Threads, http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Thread.h tml. [9] Siemens SDK for UPnP Devices documentation, http://www.plug-n-play-technologies.com/ . [10] AXIS 2110 Network Camera, http://www.axis.com/products/cam_2110/index.htm. [11] AXIS UPnP test firmware, http://www.axis.com//techsup/cam_servers/dev/upnp/inde x.htm.