An UPnP-based context-aware framework for ubiquitous mesh home ...

An UPnP-based context-aware framework for ubiquitous mesh home networks Shahab Gashti and Guy Pujolle

Julien Rotrou

Laboratoire d’Informatique de Paris 6 – LIP6 Université Pierre et Marie Curie - UPMC Paris, France {Shahab.Gashti, Guy.Pujolle}@lip6.fr

UCOPIA Communications R&D Châtillon, France [email protected]

Abstract— Wireless mesh networks are an appropriate solution for broadband home networks in order to establish a ubiquitous environment. One of the main challenges in ubiquitous networks is context-awareness and personalized service discovery. Many service discovery protocols have been proposed in the literature. The most significant is the Universal Plug and Play (UPnP) technology, based on the Simple Service Discovery Protocol (SSDP) and targeted for home network environment. However, the UPnP technology has some drawbacks and particularly does not consider user context. In this paper we present a framework that provides an extension for the UPnP architecture and employs context-aware concepts to achieve service discovery continuity in evolving environments where devices may move inside the home and change their point of attachment within the wireless mesh network. This extension is carefully designed for wireless mesh controllers, and is compatible with the existing UPnP framework. It keeps the process of service discovery as simple and automatic as possible. Keywords- ubiquitous mesh home networks; Universal Plug and Play (UPnP); context-aware framework; mobility.

I.

INTRODUCTION

In a digital home network, various networked home appliances are interconnected to each other using Ethernet, PLC, or wireless technologies through a home gateway (HG) [1]. The deployment of wireless technologies such as WLAN and WPAN has increased considerably in the home environments in the last years. However, infrastructure-based wireless networks have some limitations. For example, a client must be in the coverage range of the Wireless Access Point (AP) for access network resources. A home usually has many dead zones with inexisting or low quality service coverage, since the deployment of many APs is expensive. Another example, a local traffic is not required to be routed through network infrastructure that is not in the same location. The wireless mesh networks are an appropriate solution for ubiquitous home networks. They provide many advantages such as cost-effectiveness, easy deployment and high performance wireless coverage for the home environments [2]. A wireless mesh network usually consists of mesh clients and mesh routers, where mesh routers can be static or with a limited mobility. They enable mesh clients to access Internet and use network services through the gateway and bridge functionalities.

The fast development of wireless technologies increased the need for service discovery protocols. For example in the domotic environment, equipment does not implement necessarily all the services which it needs but it would be able to discover and use the services offered by other equipment. The industry, manufacturers and standardization organisms studied and proposed automatic service discovery protocols such as Universal Plug and Play (UPnP), Jini, Bonjour, Service Location Protocol (SLP), Universal Description, Discovery and Integration (UDDI) and Salutation. The list is not limited to those quoted above, but they represent essentially the various visions in this domain. However, some approaches like UDDI and SLP are complex for home networking because they involve explicitly administration, deployment, configuration and maintenance of the devices and services that join and leave the network. The UPnP technology, developed by the UPnP Forum [3] and adopted by Digital Living Network Alliance (DLNA), is a widely deployed solution in residential networks and is considered as one of the main service discovery standard for home networking [1]. The UPnP architecture, supported by a strong industry consortium, offers peer-to-peer pervasive network connectivity between all types of devices including network-enabled consumer electronics equipment, intelligent appliances, portable wireless devices, and PCs. UPnP allows a client to discover a network device and its capabilities by multicast flooding, but this protocol is not enough powerful to discover for example the nearest device to the client having high network bandwidth and latency. This protocol, like standard service discovery protocols, does not have the capacity to describe an adapted search depending on real requirements of the client, and does not consider context either. In addition, service discovery in home networks should not be completely automatic. The clients must be able to configure the services they want to share. In this paper we provide an approach to utilize UPnP as a middleware in mesh home networks. Service discovery mechanism and access to services are controlled through an intermediary node considering user profile and context, in a completely transparent way to both clients and service providers. In the mobility case, when the mesh client moves from one wireless mesh attachment point to another, the user context must be re-established in order to maintain context-

aware service discovery. It may significantly impact the performance of each protocol layer. Context transfer is then proposed in order to offer the service discovery continuity, and it can reduce the handover delay. This paper is organized as follows. Section 2 of the paper discusses the related works. Section 3 serves to understand the rest of the paper as it introduces the UPnP technology. Section 4 presents the context-aware framework for ubiquitous mesh home networks. Section 5 shows the context transfer providing seamless mobility and context-aware service discovery continuity. Finally, Section 6 ends the paper with the conclusion and the future work. II.

RELATED WORK

There are many studies related to context-aware systems. [4] defines Context, in ubiquitous computing, as any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves. [5] summarizes the main approaches and aspects of context-aware systems and discusses the strengths and weaknesses of existing implementations. [6] classifies middlewares in two categories: (a) middlewares that promote localized ubiquity and focus in providing and using of context in the chosen domain; and (b) middlewares promoting global ubiquity through the federation of context-aware systems. These studies show that contextaware systems can be implemented in many ways, every system and framework uses its own format to describe context and its own communications mechanisms and there is no standard language or ontology for sensing contextual information from various sources of contextual information. Furthermore, the context-aware systems presented in these surveys are not designed to be used in home network appliances. UPnP, otherwise, is supported by many home and office devices as well as various mobile phones. Thus, an UPnP-based context-aware approach is more attractive and feasible for home networks. [7] adds context-awareness to the Universal Plug and Play Audio Visual (UPnP-AV) and deals with multimedia devices and especially multimedia content. It introduces the notion of context usage for customizing multimedia content to different user and device profiles. This enhancement of UPnP-AV services is targeted to home multimedia environments only and works in a higher layer of UPnP service discovery. Since, our approach specifically deals with context-aware service discovery and delivery in a mesh home network where devices physically move inside the home and changes dynamically their attachment point within the mesh home network. In this paper the goal is to deliver services, any time and any where in the mesh home network, depending on user context. III.

UPNP OVERVIEW

UPnP allows automatic networking management. It simplifies the installation and the administration of network devices and services enabling them to control and to be controlled, to discover and to be discovered. This technology leverages a set of existing standards such as TCP/IP stack together with Web technologies, especially HTTP and XML.

The UPnP solution is platform independent and is built on top of the IP stack and runs over any physical network technology. In addition, the UPnP architecture offers pervasive peer-to-peer network connectivity since it does not require a central server. An UPnP Network is composed of UPnP Devices, UPnP Services and UPnP Control Points. An UPnP Device may provide different sets of services as well as embedded devices. An UPnP Service exposes the device functionalities, represents a set of actions to which the services respond, and consists of state variables. Finally, an UPnP Control Point can discover and control the UPnP services and devices, invoke actions, and subscribe to events. Like many network protocols, the UPnP forces devices to stay fully powered-up, even if they are inactive. This is a real problem for mobile devices where battery lifetime is a limited resource. The UPnP Forum has thus standardized the UPnP Low Power architecture [8] in order to enable power management in UPnP devices. The UPnP Low Power architecture allows UPnP devices implementing power saving mode to enter and remain in a low-power sleep state and thus to conserve energy while still being discoverable. The UPnP Low Power solution is particularly interesting for an implementation on home network environments in order to dynamically control, monitor, and configure home devices. In this case, an UPnP Low Power Control Point would be able to manage UPnP Low Power Devices. Most of all, in an energyoriented approach, such a controller would be able to wake up or put devices into a sleep mode in order to optimize the lifetime of the network, thus reducing energy consumption. IV.

MESH HOME NETWORK ARCHITECTURE AND COMPONENTS

Home connectivity has evolved dramatically over recent times. Wireless mesh networks, with their powerful capabilities, are one of the main technologies that aim to build the next generation of home networking [9]. The wireless mesh home network architecture consists of two kinds of devices. One type of device is the wireless mesh controller (MeshController). The other one is home device (mesh client). MeshControllers establish an ubiquitous heterogeneous network within the house. They integrate APs, in our case UWB, IEEE 802.11, and IEEE 802.16, and can be connected to an IP network and the Internet through router, gateway or bridge functionalities. In addition, RFID readers are installed and associated to the MeshControllers that are in the same location in order to track mobile assets. Consequently, a home device such as a laptop can have more than one radio access interface and RFID tag. Furthermore, the MeshController constraints the access to the wireless mesh home network and allows secure communications by radio link encryption and strong authentication mechanisms. The MeshController interconnects various home appliances, federates all its associated devices, and also performs dynamic packet filtering. The filtering rules should not be removed before user authentication. The user, once authenticated, can access services and applications authorized by its profiles. Another main device of the home network is the home gateway (HG). The HG is a device that acts between the home infrastructure and the broadband network. It can offer, in such

environment potentially with tens of wireless mesh controllers, an easy and centralized management of users. In the rest of the paper, we consider that the home network is composed of fixed MeshControllers as well as mobile users and devices. When a user wants to access home services, it must first connect to a MeshController. Then the MeshController establishes the user context through the HG, where the HG is in charge of the users’ profiles storage and their first authentication. All MeshControllers implement our enhancement of UPnP in order to provide context-aware service discovery for mesh clients. Figure 1 gives an overview of the main components of the MeshController. The context-aware framework presented here is composed of different modules. In the rest of this section we explain in details these modules and their interactions.

MeshController is considered as a root device and all the other devices on the network are seen as the MeshController’s embedded devices in this XML configuration file. B. SSDP Extension The Simple Service Discovery Protocol (SSDP) is a key component in the UPnP architecture. It is a fully distributed discovery protocol and works in a multicast environment. However, the network control becomes complicated in terms of message authenticity, access permission and privacy in such environment. In an UPnP network, devices and services send periodically advertisements and any device on the network that matches the criteria the control point is searching for issues a unicast UDP reply that includes the URL to its description document. As a consequence, any node on the local administrative multicast domain can discover and also control the UPnP devices. The extension to the UPnP architecture presented here is motivated by the lack of a control for multicast environments. This SSDP extension has been developed in the MeshController, does not require any modification on the other UPnP devices and is compatible with the standard SSDP protocol. The general idea of SSDP extension is quite simple. Like in SSDP, SSDP alive messages are sent by the MeshController that hosts services to advertise its presence. SSDP discovery messages are sent out by UPnP Control Points to query UPnP devices and services. These SSDP multicast discovery messages are captured by the MeshController. Upon reception of a SSDP discovery message, the MeshController performs the following operations: if (client is known to the MeshController){ retrieve the URL of the user related description; if(MeshController matches what the control point is searching for in the retrieved XML file) { send a unicast UDP NOTIFY response with the URL of the user related description document; } } else{ ignore the request; }

Figure 1. The proposed context-aware framework with different modules for the MeshController and its relation with the UPnP protocol.

A. UPnP Descriptions Repository In our framework, the MeshController includes two categories of XML descriptions: one category, called UPnP description for the MeshController device, enables the MeshController to advertise its presence. The other category provides user related description. It concerns UPnP description of devices and services that the user can access depending on its context. In each user related XML description,

As a result, if the control point wants more information about all its devices and services on the network, it can download the XML description file with the URL provided by the MeshController. The SSDP extension manages two types of UPnP description document as described above and communicates with other modules to achieve context-aware service discovery in evolving environments. We can adopt static or dynamic approach to manage user related description. In the static approach, at the initial phase, all the different user related descriptions are calculated by the Context Manager Module depending on different user contexts. In the dynamic approach, the Context Manager Module is in charge of adapting this file in real-time depending on context changes.

C. Context Manager Module The Context Manager Module includes the Context Repository, Context Provider, Context Aggregator, Context Event Service and Context-Aware Lookup Service. Each component provides specific and interdependent functionalities which are described in details in the following subsections. 1) Context Repository Context is modeled, basically, as a set of multidimensional attributes (parameters or context atoms) hence each attribute possess a value. Thus, context state depends on the attributes value. Context parameters could be the user’s position, user’s profile, local resources of the device, time, accompanying people, available services around the user and environmental parameters. It is indeed impossible to enumerate all the appropriate attributes for all the situations. Consequently, in this paper we will refer mainly to user context characterizing the user’s state in relation to the MeshController. In addition to two typical states connected/disconnected we can also include the following parameters: user ID, user profile, URL of the user related description, MAC address, IP address, location, power state, time of connection, available services, etc. Due to context changes in time thus it is necessary to have a mechanism to feed the context with appropriate information. 2) Context Provider The Context Provider dynamically captures and processes low-level contextual information such as the location, user status, network connectivity, device power state, etc. Typically, we distinguish different parameters at different levels like: node parameters including local node capacities such as the device power state, spatial parameters that consist of device position and consider the concept of localization and location-awareness, network parameters that control the interaction of devices over the network through number of hops, bandwidth, latency, technologies, etc., and service parameters that relate to service capabilities, load, cost and other service-awareness concepts. Context Providers updates these parameters with best values in real time. Because of a great number of parameters, we restrict the set of Context Provider to gather the position and power state of devices. a) UPnP Low Power Aware Control Point: It relates to a device or an UPnP Control Point that can monitor the sleep state of other nodes in the network. It can also monitor the entry and exit of nodes from the network. An UPnP Low Power Aware Control Point can wake up a device from a sleep state or request a device to go into a low power state. This component collects information about all the devices over the network where devices may connect or disconnect at any time. b) Location Receiver: Localization in wireless networks has been studied for a long time now and many solutions have been proposed in the literature covering infrastructure-based and self-positioning methods. They can be classified from a simple technique using Time-To-Live (TTL) field specifying number of hops from the source and routing information to more sophisticated methods such as distance estimation using signal triangulation, scenes analysis approaches and proximity based technique. Localization by RFID system seems to be the

best method for home networks. RFID is a short range identification technology. RFID tags are very small, very cheap, computationally limited and can be easily applied to or incorporated into a device. Due to these characteristics, RFID systems provide by default accurate proximity localization and limited positioning errors in dense deployments [10]. In addition, [11] proposes a scalable and robust 3-D localization method for heterogeneous RFID systems. Localization by RFID readers can be realized in various manners and various costs, particularly according to RFID tags performances. The accurate and precise localization requires the deployment of many RFID readers. For economic reasons, it is indeed difficult to install a constellation of RFID readers. A pragmatic solution consists in deploying readers in defined passing zones such as doors, inputs/outputs of rooms (or home) and also near to devices, where certain devices have zero or limited mobility, in order to track mobile assets when they enter or exit specified zone. RFID readers read the tags and send a message to the Location Receiver. The Location Receiver, knowing the position of the reader, determines the section in which the device or the terminal was localized. 3) Context Aggregator The Context Aggregator provides consistent and uniform contextual information to the middleware. It retrieves contextual information from Context Providers in order to select more relevant information. Then it communicates with the Context Repository via a context access open API in order to inject these data into the Context Repository. Since, all information about all devices and service within the home network are mapped in the MeshController. 4) Context Event Service This service signals changes in context state. A Control Point interested in receiving event notifications will subscribe to MeshController event service. User description includes a list of variables that model the state of the context, and a control point may subscribe to receive this information. Event messages contain the names of one or more state variables and the current value of those variables. These messages are expressed in XML and formatted using GENA. This is a solution for example to tell applications when they are in a specific room. 5) Context-Aware Lookup Service Our framework provides lookup functionality to locate appropriate services and devices that are relevant to client needs and in accordance with user context. In our approach SOAP, as a web service technology and a standard communication mechanism, is used to help more interoperable context-aware lookup actions. V.

CONTEXT TRANSFER

A mobile device in a mesh home network can have the mobility (handover) possibility such as micro mobility where only layer-2 network association changes. It occurs when the mobile node moves from one MeshController to another. One of the goals of our architecture is to support the context-aware service discovery continuity for micro mobility case as mobile asset IP address does not change.

Due to user mobility, we must re-establish all the user contexts after layer-2 association, security association, authentication and authorization. As the user may have restrictions to use some services, the system must adapt to changes of the context. In the classical approach, it would be necessary to recalculate and retrieve all the properties of the user. In this case, and particularly during the handover phase, the duration of the authentication and more generally the time for the calculation of the user properties and context, is critical to ensure a seamless continuity of service and without user intervention. The handover delays may be incurred at each protocol layer. It is important to reduce this delay during the handover phase in order to support seamless mobility.

Figure 2. Context transfer between MeshControllers

To achieve this goal, we establish the context transfer, necessary for the context-aware service discovery continuity, with respect to the constraints of user usage environment and context. In fact, in a transfer of context between two MeshControllers, as shown in Figure 2, the MeshController having already calculated the properties of the user, transfers the context to another MeshController. The continuity of service is thus ensured by a transfer of context between the MeshControllers in charge of the monitoring of the mobile device. As a result, the second MeshController does not retrieve what was already calculated. It remains only to enforce the user properties. Consequently, we propose an API usable by layer-2 elements. This API allows users to inform the MeshController about the handover. In other words, when a decision algorithm determines that the handover will take place, it informs the MeshController who manages the transfer of the context according to the new associated MeshController. We enhance this mechanism with the deployment of a localization system by RFID. The localization by RFID allows initiating the transfer of context according to the localization of the client that may not be able to inform the MeshController via the API. After the transfer, the second MeshController manages the user related description, assumes the client traffic, service discovery and deliver event notifications to the mobile device. This mobility solution is independent of the equipment manufacturers and network technologies, and avoids

pertinently re-authentication and the recalculation of user profile and his/her properties. VI.

CONCLUSION

We proposed a framework to enable context-aware service discovery in ubiquitous mesh home networks. We first presented the wireless mesh controller (MeshController) as one of the primary components in the home network, main technologies building the home network infrastructure and the UPnP solution, which is used to manage home networked devices. However, standard UPnP does not consider context properties for its service discovery mechanism. To overcome this drawback, an extension to the Service Discovery Protocol (SSDP) has been realized which enables the MeshController UPnP device to respond to service discovery queries depending on user context. Context information related to the user is built by the Context Management Module. This context information is injected and used by different components of the framework. This framework allows the personalization of service discovery and delivery to the needs of the user with respect to the constraints of her/his usage environment and context. In addition, the transfer of user context in a heterogeneous environment between MeshControllers can significantly reduce handover delay and bring transparency and simplicity for context-aware service discovery continuity. This approach is not limited to the MeshController UPnP device and can be adopted by any future UPnP device offering context-aware services. Several challenges arose from our framework and will be part of future work. They concern the context-aware service discovery in global ubiquity, context-aware macro and domain mobility, the scalable conception of the context model. REFERENCES [1]

B. Rose, “Home Networks: A Standards Perspective,” IEEE Communications Magazine, Vol. 39. Issue 12. December 2001. [2] I. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey,” Elsevier Computer Networks, 2005. [3] “The Universal Plug and Play (UPnP) Forum,” http://www.upnp.org [4] K. Anind, Dey, “Understanding and Using Context,” Personal and Ubiquitous Computing, Vol. 5, Issue 1, 2001. [5] M. Baldauf, S. Dustdar, F. Rosenberg, “A survey on context-aware systems,” International Journal of Ad Hoc and Ubiquitous Computing. Vol. 2, Issue 4, 2007. [6] R. Couto A. da Rocha, M. Endler, T. Senador de Siqueira, “Middleware for ubiquitous context-awareness,” MPAC, 2008. [7] R. Tusch, et al., “Context-Aware UPnP-AV Services for Adaptive Home Multimedia Systems,” International Journal of Digital Multimedia Broadcasting. Vol. 2008. Article ID 835438, 2008. [8] UPnP Design Complete, “UPnP Low Power Architecture V1.0,” UPnP Forum, August 2007. [9] B-N. Park, W. Lee, S. Ahn, “QoS-driven wireless broadband home networking based on multihop wireless mesh networks,” IEEE Transactions on Consumer Electronics, Vol. 52, Issue 4, Nov. 2006. [10] R. Want, “An introduction to RFID technology,” IEEE Pervasive Computing. Vol. 5, Issue 1, January-March 2006. [11] M. Bouet, G. Pujolle, “A range-free 3-D localization method for RFID tags based on virtual landmarks,” IEEE PIMRC, 2008.