Discovering and Accessing Peer-to-peer Services in ... - IEEE Xplore

810

IEEE Transactions on Consumer Electronics, Vol. 58, No. 3, August 2012

Discovering and Accessing Peer-to-peer Services in UPnP-based Federated Domotic Islands Paolo Bellavista, Senior Member, IEEE, Paolo Gallo, Carlo Giannelli, Member, IEEE, Giorgio Toniolo, and Aldo Zoccola Abstract — The growing availability of low-cost networkenabled consumer equipment is pushing for novel domotic scenarios characterized by a plethora of heterogeneous devices providing services in a peer-to-peer fashion. In particular, UPnP is widely recognized as the most spread and adopted industrial standard to support inter-device discovery and communication in home networks. However, UPnP scope is traditionally limited to domotic islands, i.e., devices communicate only if in direct visibility and deployed in the same subnet. The paper presents a novel approach to easily and efficiently federate UPnP-based domotic islands, supporting seamless interworking of legacy UPnP devices deployed in different networks at multi-hop distance. In addition, the proposed solution supports Internet federation of remote islands, based on user-managed named groups, to allow the secure discovery and fruition of peer-to-peer services only to authorized users. The proposed solution has been implemented, deployed, and thoroughly tested on several platforms, ranging from high-performance desktop PCs to offthe-shelf smartphones and router-like OSGi-enabled equipment. The reported performance results demonstrate that our solution is suitable even for low-end devices with limited hardware capabilities1. Index Terms — UPnP, multi-hop ad-hoc networks, peer-topeer services, domotic islands.

I. INTRODUCTION In the last couple of years, the consumer electronic market has been characterized by the emerging of a wide ecosystem of heterogeneous devices with ever increasing capabilities and supporting the generation and sharing of multimedia content. For instance, smartphones are equipped with highperformance CPUs, wide-bandwidth wireless interfaces, and powerful cameras capable of generating high-quality pictures and videos. Moreover, domotic consumer devices with storage capabilities, e.g., Network Attached Storages (NASs), deployed in home networks provide the capability of sharing huge amounts of multimedia content to devices connected to the same network, e.g., allowing to render users’ pictures on HD IP TVs. In particular, UPnP is rapidly imposing itself as 1 This work is partially supported by Telecom Italia, Working Capital project. P. Bellavista and G. Toniolo are with the Dipartimento di Informatica: Scienze e Ingegneria, Università di Bologna (email: [email protected]). C. Giannelli is with CIRI-ICT, Università di Bologna (email: [email protected]). P. Gallo and A. Zoccola are with Telecom Italia (email: {paolo4.gallo, aldo.zoccola} @telecomitalia.it).

Contributed Paper Manuscript received 05/31/12 Current version published 09/25/12 Electronic version published 09/25/12.

the most and widely adopted industrial standard enabling the discovery, access, and control of devices/services in local area networks, not only facilitating the provisioning of multimedia content, but also allowing the control of generic services, e.g., the management of UPnP-enabled routers based on Internet Gateway Device (IGD) specifications. In this scenario, group-related behaviors and the ever increasing willingness to share rich user-generated contents, also pertaining to the personal sphere, call for users’ cooperation and a user-centric communication paradigm shift, where the seamless interworking of consumer devices plays a central role. On the one hand, users aim to share their multimedia content based on personal relationships, e.g., to show holidays pictures to friends, or interests, e.g., to offer music streaming to people interested in the same genre. On the other hand, users want to control the provisioning of their personal contents, especially when providing access to nodes that are remotely located outside their local home networks, e.g., specifying who can access them and when. Also due to security and privacy concerns, the dynamic sharing of multimedia content is currently widely adopted only in the limited scope of local subnets where interacting devices are in direct visibility, namely domotic islands, e.g., showing pictures stored on a smartphone on an IP TV deployed in the same home network. Instead, commonly there is no easy support for the interworking of devices hosted in different subnets, either interconnected via Internet, e.g., a home network ADSL router and an UMTS-enabled smartphone, or via multi-hop spontaneous networks, based on multi-hop paths composed of ad-hoc links among mobile personal devices (e.g., smartphones, tablets, and laptops) opportunistically established among socially interacting people [1]. Note that spontaneous networks may be composed by heterogeneous paths (heterogeneous radio access technologies, different and possibly conflicting addressing spaces, …): packets are dispatched by exploiting nodes that are willing to share their resources, possibly through subnets with different address spaces and NAT connections. In particular, our Real Ad-hoc Multi-hop Peer-to-peer (RAMP) middleware provides application developers with easy-to-use APIs to support fast prototyping of collaborative applications over spontaneous networks. It supports unicast/broadcast end-to-end communication and operates connectionless, mission-oriented, and application-layer routing: RAMP packets include the ordered set of IP addresses they must traverse to reach their destinations, in a Dynamic

0098 3063/12/$20.00 © 2012 IEEE

P. Bellavista et al.: Discovering and Accessing Peer-to-peer Services in UPnP-based Federated Domotic Islands

Source Routing-like way [2]. Thus, intermediary nodes can dynamically and flexibly forward data among uncoordinated IP subnets, with good performance results and fast packet header evaluation. Finally, working at the application layer simplifies portability and rapid deployment over heterogeneous operating systems and nodes, which is crucial in practical industrial scenarios given the segmentation of consumer electronic deployment environments nowadays. In particular, this paper introduces a novel solution supporting the dynamic and secure federation of remote domotic islands, thus greatly facilitating the remote access to UPnP services and the provisioning of multimedia content to remotely located UPnP-enabled devices. Our novel Multi-hop UPnP Carrier (MUC) and Extended Ramp Network (ERN) solutions, built as relevant extensions of the RAMP middleware, support the transparent dispatching of UPnP messages to remote nodes located at multi-hop distance (either via Internet or through spontaneous networks), with no need of additional hardware/software components on legacy UPnPdevices. In this way, we are able to overcome the traditional UPnP limitation of interconnecting devices only if located in the same subnet. Moreover, remote domotic islands may be securely federated in a group-based way, e.g., allowing the definition of different “home” or “work” groups, and may be interconnected in a peer-to-peer fashion, e.g., for service discovery/provisioning among domotic islands without the need of any centralized support component. We have implemented and extensively validated our solution, which works on any device, including off-the-shelf smartphones, able to support the Java Runtime Environment (JRE) and the OSGi framework. A detailed and general description of our RAMP middleware is out of the scope of the paper and can be found in [3]-[5]; the paper focuses on RAMP extensions to support multi-hop UPnP communication (Section II) and peer-to-peer federation of domotic islands (Section III). Moreover, the paper focus is kept on extensively describing the prototype validation and discussing the achieved performance results (Sections IV and V). II. DISCOVERING AND ACCESSING UPNP SERVICES IN MULTI-HOP SPONTANEOUS NETWORKS The main goal of UPnP is to support the dynamic discovery of devices/services in small IP subnets, typically home networks, to easily support simple domotic scenarios. For instance, common cases range from IGD-based devices allowing the easy modification of home router configurations, to Digital Living Network Alliance (DLNA) AV media servers storing large amounts of multimedia data and streaming it to DLNA AV renderers, and even ovens/refrigerators offering monitoring data about current temperature and energy consumption [6]. An in-depth analysis of UPnP is out of the scope of the paper and can be found in [7]. However, it is worth noting that UPnP considers three main roles:  Control Point (CP), a client invoking remote actions;  Device, physical or virtual component advertising its network location and its embedding services;

811

 Service, software component providing specific functionalities and receiving/processing remote actions. In addition, UPnP supports 6 functionalities (numbered from 0 to 5 in the UPnP specification): 0) Addressing, e.g., based on DHCP or Auto IP, to correctly provide IP addresses in single-hop IP subnets; 1) Discovery based on HTTPU/MU, i.e., HTTP via UDP unicast and multicast, allowing CPs to retrieve the location of remote devices via Simple Service Discovery Protocol (SSDP) and devices to advertise their de/activation via General Event Notification Architecture (GENA); 2) Description based on HTTP and XML; CPs ask to discovered devices the set of available services and to each service its supported features, e.g., methods it is possible to invoke; 3) Control via HTTP and Simple Object Access Protocol (SOAP), allowing CPs to invoke actions on remote services; 4) Eventing based on GENA and HTTP on UDP and TCP, allowing services to dispatch event notifications to CPs subscribed to them; 5) Presentation based on HTTP, to monitor remote devices. It is worth noting that since the Discovery phase is mainly based on IP/UDP multicast, UPnP coverage is limited to single-hop subnets, the typical scope of IP multicast messages. Our novel Multi-hop UPnP Carrier (MUC) solution allows the dynamic discovery and communication of multihop-distant UPnP CPs/devices/services as if they were located in the same IP subnet. Let us stress from the beginning that our solution is compliant with legacy UPnP CPs/devices/services, thus enabling already deployed UPnP components to transparently interact at multi-hop distance. In other words, from the architecture perspective and at a high level of abstraction, MUC performs as a proxy between UPnP and RAMP, e.g., by encapsulating multicast UPnP messages in broadcast RAMP packets to enable their seamless delivery at multi-hop distance. Delving into finer details, the main MUC components are:  MUC Discovery Manager (MDM), in charge of managing the discovery phase listening on the standard UPnP port (UDP 1900), receiving UPnP M-SEARCH and ALIVE/BYEBYE messages sent by CPs and devices in the same subnet, appropriately dispatching them to multi-hop distance and sending replies to senders. To avoid multiple delivery of the same UPnP messages, there must be only one active MDM in each subnet. MUC adopts an election mechanism that ensures only one MDM actually dispatches packets in each subnet (details omitted due to space constraints);  MUC Description and Control Manager (MDCM), in charge of managing both the description and the control phase, dispatching UPnP messages among CPs and devices as if they were located in the same subnet. MDCM is based on a double-proxy architecture: o a Local MDCM activated in the same subnet of actual devices/services and directly communicating with them; o a Remote MDCM activated in the same subnet of actual CPs in charge of sending messages sent by remote CPs

812

to the corresponding Local MDCM. Note that CPs interact with Remote MDCMs as if they were the actual devices/services, independently on their mutual location. Moreover, MUC contains also a MUC Eventing Manager (MEM) in charge of dispatching GENA messages, not presented here because very similar to MDCM. Finally, a MUC HTTP Manager (MHM) is in charge of dispatching HTTP requests and responses acting as a double HTTP proxy [5] among CPs/devices/services at multi-hop distance, both to support the presentation phase and to access multimedia content (see the following). To better understand how our MUC solution works, let us describe the case of a CP that is willing to discover remote devices at multi-hop distance (Fig. 1): 1) CP sends the following M-SEARCH SSDP message via multicast to discover every available device; M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: ssdp:discover MX: 10 ST: ssdp:all

2) the MDM in the same subnet encapsulates the M-SEARCH SSDP message in a RAMP broadcast packet and sends it to remote MDMs on nodes at a maximum TTL distance (default TTL value is 6, easily configurable at provisioning time); 3) remote MDMs receiving the broadcast packet de-capsulate the M-SEARCH SSDP message and send it via IP multicast to UPnP devices located in the same subnet; 4) devices receiving the M-SEARCH SSDP message reply providing via the Location header the URL they are waiting for requests according to UPnP specifications. For instance: HTTP/1.1 200 OK ST: upnp:rootdevice CACHE-CONTROL: max-age=900 EXT: USN: uuid:8310048c-4b2e-4e46-a8f9-0f8188b0 b723 ::upnp:rootdevice SERVER: Windows NT/5.0, UPnP/1.0 LOCATION: http://192.168.56.1:50449/ Content-Length: 0

5) for each existing device the remote MDM gets a reply from, a. it activates a new Local MDCM, in charge of storing IP address, port and Universally Unique IDentifier (UUID) related to the actual UPnP device; b. it encapsulates the UPnP reply in a RAMP unicast packet and sends it to the MDM co-located with CP; 6) for each reply received from remote MDMs and related to newly discovered devices uniquely identified by UUIDs, the MDM co-located with CP a. activates a Remote MDCM storing the RAMP location of the corresponding Local MDCM (RAMP location based on IP address sequence and port); b. decapsulates the UPnP message from the unicast RAMP packet, modifies the Location header (additional details in the following), and sends it to the original sender CP. In the case of ALIVE/BYEBYE messages, MDM activates/deactivates Local and Remote MDCMs in charge of

IEEE Transactions on Consumer Electronics, Vol. 58, No. 3, August 2012

managing UPnP messages for that specific service/device, uniquely identified by its UUID. RAMP‐enabled node MDM

1)

2)

2)

UPnP

UPnP device  (without RAMP) MDM

3)

D1

CP RAMP Broadcast

3)

2)

D2

UPnP M‐SEARCH

6)

MDM

Remote MDCM1/2

5)

5)

Local  MDCM1

CP RAMP Unicast

4)

D1 5)

4)

D2

UPnP Reply Local  MDCM2

Fig. 1. MUC-based discovery of multi-hop distance UPnP devices.

Let us stress that the CP-colocated MDM modifies the Location header, by specifying the IP address and port which the Remote MDCM is waiting for UPnP requests, thus mimicking the actual device D. Then, CP will interact with Remote MDCM to discover the set of available services in device D or perform control actions as if it were the actual device. At each following request sent by CP, Remote MDCM forwards requests via unicast RAMP packets to the corresponding Local MDCM, which sends the UPnP message to the actual UPnP device/service; finally, the reply flows from the actual service towards Local/Remote MDCM and to CP. Our MUC solution activates a Remote MDCM for each discovered device, with the risk of imposing not negligible computing/traffic overhead in dense multi-hop networks with many UPnP devices. However, we are carefully considering these scalability issues and are integrating several related mechanisms in the next version of the prototype. First of all, we are considering autonomous mechanisms to lower the TTL value, thus further limiting the scope of discovery messages. Moreover, we are integrating mechanisms to filter discovered UPnP devices based on Search Target (ST) header, e.g., not delivering UPnP messages with ST: ssdp:all value or allowing discovery of only DLNA AV Media Servers with ST: urn:schemas-upnp-org:device:MediaServer:1. Moreover, discovery messages can be forwarded only to specific remote RAMP locations, thus interconnecting two domotic islands by deliberately neglecting UPnP devices located in intermediate subnets. Finally, note that MDM and MDCM support the discovery and control of UPnP devices/services. For instance, it is possible to modify IGD-based router configuration by invoking appropriate remote UPnP actions. Similarly, MDM and MDCM support the discovery and browsing of DLNA AV Media Servers, by allowing remote DLNA AV Control Points

P. Bellavista et al.: Discovering and Accessing Peer-to-peer Services in UPnP-based Federated Domotic Islands

to find multimedia contents and send them to DLNA AV Renderers. However, the DLNA standard specifies that the transmission of multimedia data must be performed out-ofband, directly from DLNA AV Media Servers to DLNA AV Renderers exploiting HTTP (the UPnP standard considers even RTP, but DLNA AV Media Servers typically support HTTP only), via the access to a specific URL provided during the multimedia browsing procedure. To this purpose, our MUC solution exploits the MHM component also to provide multimedia content via HTTP. In particular, Local MDCM parses messages received from DLNA AV Media Servers and activates Local MHMs whenever a multimedia resource is discovered. Then, the Local MDCM sends Local MHM location to the Remote MDCM, which activates a Remote MHM listening on a given IP address and port, and finally provides the DLNA AV Control Point with modified browsing information with the IP address and port of the Remote MHM instead of the IP address and port of the original DLNA AV Media Server. In this way, the DLNA AV Renderer requires the multimedia resource to the Remote MHM located in the same subnet, which forwards the request via RAMP unicast packets to the corresponding Local MHM in charge of contacting the actual DLNA AV Media Server and providing the reply, e.g., an audio or video stream, to the DLNA AV Renderer through the Remote MHM. III. SECURE FEDERATION OF REMOTE MULTI-HOP SPONTANEOUS NETWORKS The RAMP middleware supports packet dispatching via multi-hop paths only if a RAMP instance is active on each intermediate subnet between source and destination. Instead, RAMP nodes located in different spontaneous networks are not able to interact, even if both connected to the Internet. Our novel Extended RAMP Network (ERN) solution overcomes this limitation. It provides a mechanism to federate disjoint spontaneous networks based on peer-to-peer communication, supporting the secure and efficient dispatching of packets among RAMP nodes deployed in remote Internet locations. In particular, RAMP nodes with direct Internet connectivity cooperate with similar nodes belonging to different spontaneous networks to dispatch packets among RAMP nodes without direct Internet connectivity. To clarify the targeted application scenario with an example, consider the case of Alice willing to show last holidays pictures stored on her NAS at home and last week party videos stored on her desktop at work on Bob’s IP TV while visiting Bob’s home. To this purpose, Alice provides access to Bob only for three hours (the time she will spend with Bob) to both her NAS and her desktop. The design and implementation of our ERN solution is based on the following main guidelines: 1) named federations, differentiating among available spontaneous networks based on logical names, e.g., “work” or “friends”; 2) role-based access control, to specify the set of remote users allowed to join a named federation in a fine-grained manner,

813

e.g., “Alice” can always access “work” and “friends” while “Bob” only “friends” and only for the following 3 hours; 3) secure and efficient peer-to-peer communication, dispatching either ciphered or authenticated packets among RAMP nodes connected to the Internet without any thirdparty support, with a proper trade-off among guaranteed security levels and limited costs. The main ERN components are:  RAMP Internet Node (RIN), a RAMP node with direct Internet connectivity dispatching packets among RAMP nodes of the same spontaneous network and other remote RINs belonging to different spontaneous networks;  ERN Manager, managing one or more federations, supporting the join procedure of remote RINs and storing/distributing the set of RINs belonging to each managed federation. Only one RIN should be present in each spontaneous network; exploiting that RIN, other RAMP nodes without any direct Internet connectivity can dispatch packets to remote RAMP nodes belonging to other spontaneous networks. For instance, node X in Fig. 2 can send packets to node Y by exploiting RINs of spontaneous networks 1 and 3.

X

2

1

W

ERN Manager A & B

RINA

Internet RINB

RINAB 3

4 Z

Y Fig. 2. ERN-based topology of named federations.

RINs exploit a symmetric key ERN Shared Key (ESK) to cipher/authenticate and decipher/verify packets transmitted to/from different spontaneous networks. ERN Managers are in charge of creating a different ESK for each named federation and providing it to RINs belonging to it. In this manner, only RINs previously joined to a federation can actually send/receive packets to/from other nodes belonging to the same federation. Moreover, ERN Managers periodically renew and securely distribute the ESK to nodes belonging to the federation based on up-to-date credentials (default period = 5 minutes, configurable at federation creation time). In this way, in the case an account has been revoked or its validity has expired (ERN supports also temporary credentials), that RIN will rapidly be denied to work with RINs in the federation. Finally, to achieve a proper trade-off between security levels and associated costs, at federation creation time it is

814

possible to enable encryption and/or authentication, and also to specify the “extent” to which each packet should be either encrypted or authenticated. In fact, to improve transmission performance, RAMP splits packets in chunks of 51200B each (default value) [4]. Our ERN solution encrypts/authenticates each chunk independently, supporting the specification of how many bytes of each chunk should be either encrypted or authenticated. For instance, it is possible to specify that only 10240B should be processed for each chunk, thus encrypting/authenticating only 20% of packet content. Therefore, it is possible to finely tune the imposed overhead due to packet processing, and this makes our proposal suitable even for devices with limited resources and performance, such as entry-level routers (see the quantitative performance results in Section V). At the same time, partial packet encryption/ authentication can be considered as sufficient for many widely spread Internet-based applications, e.g., peer-to-peer file sharing and multimedia streaming, usually based on plaintext packets. In order to communicate with nodes of a named federation, RINs have to perform a join procedure. This procedure has the two-fold objective of providing new RINs with the information required to interact with other RINs, i.e., the RIN list and the ESK, and to check that new RINs support peer-topeer interworking, i.e., they can receive UDP packets and accept incoming TCP connections. The main steps of the join procedure are (see Fig. 3): 1) RIN performs a secure HTTPS connection with the ERN Manager and provides username, password, federation name and UDP/TCP ports it will listen on for incoming packets; 2) ERN Manager checks the credentials and provides salt/IV A [8] used to encrypt the following packet; 3) ERN Manager sends salt/IV B at the RIN UDP port, encrypted exploiting salt/IV A together with the user password; 4) ERN Manager sends ESK, RIN list and a random integer through the RIN TCP port encrypted exploiting salt/IV B together with the user password. Finally, the new RIN sends to ERN Manager the hash of the received random integer. Note that encrypting salt/IV B with salt/IV A allows securely sending it because only the new RIN knows salt/IV A (securely sent via HTTPS). Moreover, when the ERN Manager receives the hash of the random integer, it is sure that the new RIN can receive packets on both UDP and TCP ports, the former to receive salt/IV B, the latter the random integer encrypted with salt/IV B. Only after correctly receiving the random integer hash, the ERN Manager adds the new RIN to the set of joined RINs. Once the join procedure is successfully completed, interRIN communication is performed peer-to-peer, by either encrypting or authenticating messages with the ESK, without any additional involvement of the ERN Manager. Moreover, the ERN Manager provides the RIN list anytime a new RIN joins and also periodically generates a new ESK by providing it to every RIN with valid credentials.

IEEE Transactions on Consumer Electronics, Vol. 58, No. 3, August 2012 1) username, password, federation name, RIN UDP/TCP port

RIN

HTTPS

ERN Manager

2) salt/IV A 3) salt/IV B via UDP

RIN

ciphered with salt/IV A and  password ciphered with salt/IV B and password

ERN Manager

4) ESK, RIN list and random integer via TCP, replying with random integer hash

Fig. 3. Join procedure of new RIN nodes.

IV. IMPLEMENTATION INSIGHTS We have implemented and thoroughly tested our RAMP middleware with MUC and ERN capabilities on several devices, ranging from high-level desktops to smartphones and router-like equipment. The RAMP middleware is Java-based and thus easily portable on many platforms. In particular, we have specialized our RAMP/MUC/ERN solutions for standard JRE, OSGi framework, and most widespread smartphone platforms. Different versions of our middleware not only take into account that each platform supports software component management and user interfaces differently, but also that different platforms target devices with heterogeneous capabilities, requiring to finely tune our solutions in relation to memory and computational resources. The standard JRE version is available as a stand-alone application, tested on major desktop OS, and the graphical interface is based on JFrame (jar size 13.4MB, most of them for Jetty Web container libraries required by ERN Manager; RAMP footprint 104MB, +63MB for ERN, +4MB for MUC). Moreover, in order to make our solution easily available on low-end devices such as OSGi-enabled routers and NASs, we have also developed a version based on the OSGi framework. While an in-depth analysis of the OSGi framework is out of the scope of the paper, note that OSGi allows the remote and dynamic deployment and de/activation of software components, namely bundles. In addition, bundles can be registered, discovered and accessed as services by other bundles, thus making easier the development of applications based on the interconnection of different bundles. The current OSGi porting of the RAMP middleware is composed of a core bundle supporting RAMP primitives for multi-hop unicast and broadcast communication plus other bundles to dynamically add/remove additional features. In particular, our ERN solution is integrated into the core bundle, since its implementation is tightly coupled with low-level RAMP features such as forwarding packets to other nodes, either in the same subnet or remotely located and reachable

P. Bellavista et al.: Discovering and Accessing Peer-to-peer Services in UPnP-based Federated Domotic Islands

via Internet. Instead, the MUC solution is implemented in a different bundle, deployable only if users actually desire to activate it. Moreover, other bundles provide additional services such as file sharing and on-demand multimedia streaming (see [3]). Each bundle provides both a JFramebased interface for devices equipped with a display and a servlet-based Web interface for headless devices, the latter useful also to remotely control features/services (OSGi footprint without RAMP 56MB, core bundle jar size 5.9MB, headless RAMP footprint +30MB, +43MB with ERN; UPnP bundle jar size 82KB, headless footprint +1MB). Finally, the implementation ported over most widespread smartphone platforms keeps the RAMP middleware active also in case the user is not having an explicit direct interaction with the associated application, thus enabling transparent background communications with neighbor nodes (background service, which can be killed only in case of extreme low memory situations). The application package size is 1.72MB, with a basic footprint of 8.23MB, +3.87MB for MUC, +8.80MB for RIN). Moreover, let us notice that, given the nature of their typical connectivity, smartphones are expected to behave as RINs and not as ERN Managers. V. PERFORMANCE RESULTS AND DISCUSSION We have tested our MUC and ERN solutions in real-world test-beds consisting of off-the-shelf consumer devices with very heterogeneous capabilities. In particular, we have used a high-performance desktop DE (Quad-Core 2.80GHz, 8 GB RAM), a medium-performance laptop LA (Core2 2.6GHz, 2 GB RAM), a smartphone AN (1.0 GHz, 512 MB RAM), and a low-performance headless device GP with capabilities similar to available routers and lower than many off-the-shelf smartphones (1.2GHz, 16-bit bus, 512 MB RAM). First of all, we have evaluated CPU consumption due to RAMP packet de/serialization. Our current RAMP prototype supports three types of serialization: the default JRE Serialization mechanism based on object reflection/introspection, the Externalizable JRE mechanism requiring developers to provide methods for object de/serialization, and Protocol Buffer (ProtoBuf) supporting the cross-language serialization of data similarly to Externalizable. As benchmark, CPU consumption is monitored also in the case of performing multi-hop paths at the operating system level (thus without RAMP), by exploiting the Iptables command to modify routing tables. In particular, we have monitored CPU consumption on GP when behaving as intermediary node, i.e., both receiving and forwarding packets. The objective is to test en/decapsulation performance in a router-like device, since routers in home gateways will be likely the most common consumer electronic devices receiving and transmitting large amounts of data, e.g., behaving as RINs. To this purpose, we have considered the challenging case of both medium quality stream (MPEG2 video coding, 25 frames per second, 610x340 resolution, 128Kbit/s audio, 832 Kbit/s throughput) and high quality stream (H.264 video coding, 25 frames per second, 1280x720 resolution, 128Kbit/s audio, 4.13Mbit maximum throughput),

815

sent either as raw RTP packets (Iptables) or as RAMP packets encapsulating RTP content (Serializable, Externalizable, and ProtoBuf). TABLE I AVERAGE CPU CONSUMPTION (%) Quality

Iptables

Serializable

Externalizable

ProtoBuf

Standard High

9.3 19.7

21.1 48.3

10.2 21.3

10.6 25.6

TABLE I shows that the Externalizable and ProtoBuf mechanisms relevantly decrease CPU consumption (no object reflection/introspection) and achieve performance results comparable with traditional Iptables scenarios. In other words, our RAMP middleware easily supports packet dispatching in multi-hop spontaneous networks without imposing notable additional overhead on intermediary nodes. Moreover, note that while Externalizable achieves slightly better performance than ProtoBuf, we selected the latter as our default serialization because it provides the notable benefit of making easier data transmission among heterogeneous platforms. Secondly, to test the overhead imposed on RIN nodes by packet encryption/decryption and authentication/verification, we have monitored the CPU consumption on GP when transmitting a file of about 20MB. The goal is to compare our ERN solution with a traditional VPN one, both encrypting whole packets (AES-128-CBC for encryption, HmacSHA1160 for authentication), exploiting either standard SAMBA or RAMP-based file sharing services. GP acts as router among DE (connected via ADSL and hosting the file sharing server) and LA1 (connected via IEEE 802.11g and behaving as file sharing client), 7 Mbit/s bandwidth from GP to DE, 500 Kbit/s from DE to GP (see Fig. 5). VPN performance does not relevantly vary when exploiting the standard SAMBA protocol or our RAMP-based file sharing solution (see TABLE II): in fact, while SAMBA achieves slightly higher throughput, it also increases CPU consumption, (CPU/Throughput ratio is almost the same, i.e., 92.9 and 92.3). By exploiting our ERN solution (DE acts as ERN Manager, GP as RIN), throughput considerably increases to 1.52 Mbit/s; however, since GP processes much more traffic, even CPU consumption grows, thus making harder a clear performance comparison; in any case CPU/Throughput ratio is considerably lower, i.e., 65.8 in place of 92.3. In addition, we have tested our ERN solution limiting the ADSL bandwidth to 1 Mbit/s: lower throughput imposes less packet processing and thus lower CPU consumption (CPU/Throughput ratio is almost the same, i.e., 65.8 and 66.3). It is worth noting that our ERN solution achieves higher throughput than VPN (1.01 Mbit/s instead of 0.78/0.74 Mbit/s) consuming less CPU resources (67.0% instead of 72.5/68.3%). In other words, our ERN solution supports multi-hop packet dispatching very easily (effortless ERN/RIN configuration compared with VPN), does not impose additional computing overhead, and even increases the overall experienced throughput.

816

IEEE Transactions on Consumer Electronics, Vol. 58, No. 3, August 2012 TABLE II VPN AND ERN PERFORMANCE COMPARISON

Remote File Bandwidth Throughput CPU link Sharing limitation (Mbit/s) (%) VPN VPN ERN ERN

SAMBA RAMP RAMP RAMP

no no no 1 Mbit/s

0.78 0.74 1.52 1.01

CPU / Throughput

72.5 68.3 100.0 67.0

92.9 92.3 65.8 66.3

Furthermore, we have evaluated CPU consumption when changing the size of the packet under processing, for either ciphering or authentication. In particular, packets are split in 51200B chunks, each chunk separately ciphered/authenticated and transmitted sequentially (bandwidth limitation to 2 Mbit/s). As Fig. 4 shows, in case the whole traffic is encrypted (51200B processed per chunk), the CPU saturates to 100%, while CPU consumption drops to 75% in case of authentication. Moreover, CPU consumption relevantly goes down in case only 50% traffic is processed (first 25600B per chunk), achieving 68% with encryption and 55% with authentication. In addition, CPU consumption is lower than 40% for both encryption and authentication if only 10% traffic is processed (5120B per chunk). Let us stress that the usual header size is much lower than 5120B: encrypting/ authenticating the first 5120B ensures header information confidentiality/integrity; only part of the payload is unprocessed in our solution, which is considered sufficiently secure for all the targeted application scenarios.

CPU consumption (%)

100 80

Encryption

60

Authentication

hop scenarios based on bare UPnP. Dispatching time mostly increases in relation to path length due to inter-node transmission delay. For instance, device discovery is performed in 1497ms in two-hop paths while it increases to 2110ms in case of 4-hop path with also ADSL-based Internet connectivity. Also the access to high quality video is performed very efficiently: it takes only 1717ms from UPnPlay video request to first byte reception (note that smartphones typically start actual video rendering later, depending on buffer size of video renderer application). IEEE 802.11g AP

MUC‐enabled interface

client

Ethernet

Internet (ADSL)

AN

LA1

LA2

DE

GP

Fig. 5. MUC solution test-bed environment. TABLE III MUC PERFORMANCE (MS) Path length (#hops)

1 (no MUC)

2

3

4 (also ERN)

Discovery Description Invocation Play Video

1402 20 23 793

1497 54 267 947

1583 92 301 1132

2110 327 619 1717

Finally, we have also successfully tested scenarios in which smartphones behave as RIN while connected to UMTS/HSDPA. Anyway, for the sake of briefness, we have decided not to report those results in the paper because they have demonstrated to mostly depend on cell link capabilities (highly varying from 150 Kbit/s to 6.5 Mbit/s) rather than on the effectiveness of our MUC/ERN solution.

40

VI. RELATED WORK

20

Extending UPnP scope boundaries to maximize the set of available services has gained growing attention in the last years, also pushed by increased industrial interest in interconnecting heterogeneous devices more and more deployed in home networks. On the one hand, by considering inter-protocol enhancements, several proposals aim to interconnect UPnP devices with services based on other technologies [9]-[17]. For instance, [9] proposes a software bridge allowing communication among UPnP and Bluetooth devices. The proposed solution activates a Virtual UPnP Device for each detected Bluetooth device, e.g., mapping Bluetooth Service Discovery Protocol (SDP) messages to UPnP SSDP ones. Instead, the solution proposed by [10] is based on a Bluetooth Virtual Service component offering UPnP services to Bluetooth devices as if they were provided via Bluetooth. [11], [12] focus on ZigBee, with the objective of accessing ZigBee devices at multi-hop distance as if they were local UPnP devices. In particular, the UPnP-ZigBee Gateway (UZG) component creates virtual UPnP proxies for discovered ZigBee devices [11]. The proposed solution takes into consideration that ZigBee devices can freely move,

0 51200 25600

5120 512 100 0 Processed bytes Fig. 4. CPU consumption in relation to processed bytes per 50KB chunk.

Finally, we have tested our MUC solution in spontaneous networking scenarios characterized by heterogeneous devices, variable path length, and also different inter-node connectivity protocols (see Fig. 5). In particular, TABLE III shows performance results for the most important UPnP phases. Discovery, Description, and Invocation are performed while accessing, from a smartphone AN, to remote DLNA AV Media Servers deployed on other nodes (Invocation corresponds to media server content browsing). Moreover, Play Video considers time elapsed between video request and first data chunk received by the application (TABLE I high quality video). In case of 4-hop path, the last hop is based on our ERN solution. The reported performance results show that our solution supports UPnP message dispatching very efficiently, by achieving dispatching times that are similar to traditional 1-

P. Bellavista et al.: Discovering and Accessing Peer-to-peer Services in UPnP-based Federated Domotic Islands

monitoring the ZigBee topology and eventually reconfiguring UZGs. [13] is specifically designed to bridge IPv4 and IPv6 UPnP devices, e.g., to stream multimedia content from IPv6 DLNA AV Media Servers to IPv4 DLNA AV Renderers. [14] provides traditional UPnP-based devices deployed in home networks with Torrent-based file sharing features. [15] proposes an OSGi-based solution to access, from DLNA AV Renderers deployed in home networks, multimedia sources in the Internet as if they were provided by DLNA AV Media Servers running on the home gateway. [16] bridges UPnP and CWMP, allowing to use CWMP to manage UPnP devices deployed in remote locations. Finally, [17] supports provisioning of content stored in UPnP DLNA AV Media Servers to remote clients via feeds and syndication based on the Atom protocol. Our MUC solution is complementary to the above contributions. For instance, MUC can be coupled with [9] and [11] to access Bluetooth and ZigBee devices at multi-hop distance, possibly by enabling multiple hop-paths composed of Bluetooth/ZigBee links and traversing different IP subnets. On the other hand, only a few recent proposals have suggested interconnecting remote domotic islands, enabling the interworking of remotely located UPnP resources. In [18], a UPnP Network Bridge integrates two home networks at a time, forwarding specific bridge/UPnP messages among gateways. To interconnect multiple home networks, it is required to deploy multiple bridges in a chain fashion. [19] adopts JXTA to create an overlay peer-to-peer network among different home gateways. In this way it easily supports message relay among UPnP devices deployed in different locations. Instead, [20] is based on XMPP, exploiting an XMPP server to relay messages among XMPP clients to interconnect remote UPnP devices and services. [21] focuses on distribution of DLNA UPnP messages and data among several remote locations connected to the Internet. Similarly to our MUC solution, [21] forwards SSDP messages to/from remote locations and modify them to hide the actual location of remote UPnP Services. [22] couples IMS and an UPnP Reverse Proxy to access and control UPnP devices from remote locations. The above contributions have provided interesting solutions to interconnect remote UPnP devices and services, but they only support very specific and limited scopes: in particular, in all the above solutions UPnP devices must have direct visibility of home Internet gateways. Finally, only a very few literature contributions have proposed solutions to discover and access UPnP devices and services at multi-hop distance, without any path length constraint. [23] is based on generic un/structured peer-to-peer solutions such as Gnutella/Chord. Multicast and unicast UPnP messages are sent to other nodes via broadcast and unicast primitives provided by underlying middleware. Instead, [24] takes into consideration Mobile Ad-hoc Networks (MANETs), providing a homogeneous address space and supporting multi-hop communication via ad-hoc routing. The proposed solution

817

extends SSDP: ALIVE/BYEBYE/M-SEARCH messages are modified to specify that the underlying routing should dispatch them at multi-hop distance. It is important to note that [23] and [24] delineate solutions to support multi-hop dispatching of UPnP messages similar to our MUC solutions, e.g., by sending UPnP multicast packets via multi-hop broadcast. However, [23] and [24] only delineate first solution guidelines, based on generic middleware solutions to dispatch packets at multi-hop distance, without providing any actual prototype implementation and performance analysis. Moreover, they do not specify how legacy UPnP devices and services actually interact at multi-hop distance, since [24] only addresses the Discovery phase, while [23] does not specify how multi-hop TCP connections of Description and Control phases are performed. In conclusion, at the best of our knowledge, there is no prototype implementation actually allowing the efficient discovery/invocation of UPnP services in federated multi-hop spontaneous networks, as our MUC/ERN solutions do. VII. CONCLUSION This paper aims to show the suitability of middleware-level solutions for the dynamic federation of UPnP domotic islands. In particular, we propose MUC and ERN solutions, coupled with our RAMP middleware, to widen domotic island boundaries and support the interaction of remote UPnP devices and services. Deployment simplicity, together with limited memory and computing overhead, make our approach attractive for consumer electronics based on a wide range of heterogeneous platforms, with highly differentiated sets of available resources (computing power, memory size, …). The encouraging results already achieved are stimulating our further research in the field, primarily along the guideline of exploiting social relationships to guide the interconnection of remote RAMP nodes based on users’ social interactions. In addition, we are planning to extend MUC to support also UPnP Telephony and SIP/RTP communications, thus widening the set of supported protocols and available legacy applications. REFERENCES [1] [2]

[3] [4]

[5]

[6]

L. M. Feeney, B. Ahlgren, and A. Westerlund, "Spontaneous networking: an application oriented approach to ad hoc networking", IEEE Comm. Mag., vol.39, no.6, pp.176-181, Jun 2001. D. B. Johnson, D.A. Maltz, and J. Broch, "DSR: The Dynamic Source Routing protocol for multi-hop wireless ad hoc networks", Ad Hoc Networking, edited by Charles E. Perkins, Chapter 5, pp. 139-172, Addison-Wesley, 2001. P. Bellavista, A. Corradi, and C. Giannelli, “Middleware for differentiated quality in spontaneous networks”, IEEE Pervasive Computing (in press, DOI 10.1109/MPRV.2011.59). P. Bellavista, A. Corradi, and C. Giannelli, "The Real Ad-hoc Multi-hop Peer-to-peer (RAMP) middleware: an easy-to-use support for spontaneous networking", 15th IEEE Symp. on Computers and Communications (ISCC'10), Riccione, Italy, June 2010. P. Bellavista and C. Giannelli, "Internet connectivity sharing in multipath spontaneous networks: comparing and integrating network- and application-layer approaches", 3rd Int. Conf. on MOBILe Wireless MiddleWARE, Operating Systems, and Applications (Mobilware 2010), Chicago, USA, July 2010. UPnP Forum, “UPnP AV MediaRenderer v3 device and UPnP AV MediaServer v4 device”, Dec. 2010.

818 [7] [8] [9]

[10]

[11]

[12]

[13] [14]

[15]

[16]

[17]

[18]

[19] [20] [21]

IEEE Transactions on Consumer Electronics, Vol. 58, No. 3, August 2012 UPnP Forum, “UPnP device architecture 1.1”, document revision date 15 October 2008. A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of applied cryptography, CRC Press, Oct. 1996. Tae-Wook Jo, Yong-Duck You, Hoon Choi, and Hyong-Shik Kim, "A bluetooth-UPnP bridge for the wearable computing environment", IEEE Trans. on Consumer Electronics, vol.54, no.3, pp.1200-1205, Aug. 2008. A. Delphinanto, A. M. J. Koonen, M. E. Peeters, and F. T. H. den Hartog, "Proxying UPnP service discovery and access to a non-IP Bluetooth network on a mobile phone", IEEE Symp. on Communications and Vehicular Technology in the Benelux, pp.1-5, 15-15 Nov. 2007. Seong Hoon Kim, Jeong Seok Kang, Hong Seong Park, Daeyoung Kim, and Young-joo Kim, "UPnP-ZigBee internetworking architecture mirroring a multi-hop ZigBee network topology", IEEE Trans. on Consumer Electronics, vol.55, no.3, pp.1286-1294, August 2009. Wen-Wei Lin and Yu-Hsiang Sheng, "Using OSGi UPnP and Zigbee to provide a wireless ubiquitous home healthcare environment", Int. Conf. on Mobile Ubiquitous Computing, Systems, Services and Technologies, pp.268-273, Sept. 29 2008-Oct. 4 2008. Chung-Sheng Li, Yueh-Min Huang, and Han-Chieh Chao, "UPnP IPv4/IPv6 bridge for home networking environment”, IEEE Trans. on Consumer Electronics, vol.54, no.4, pp.1651-1655, Nov. 2008. Chih-Lin Hu, Hsin-Cheng Lin, Bing-Jung Hsieh, and Yu-Feng Hsu, "Integrated home gateway design for enabling P2P content sharing in UPnP-based home networks", IEEE Int. Conf. on Consumer Electronics (ICCE), pp.229-230, 9-12 Jan. 2011. Dong-Oh Kang, Kyuchang Kang, Sunggi Choi, and Jeunwoo Lee, "UPnP AV architectural multimedia system with a home gateway powered by the OSGi platform", IEEE Trans. on Consumer Electronics, vol.51, no.1, pp. 87- 93, Feb. 2005. A. E. Nikolaidis, S. Papastefanos, G. A. Doumenis, G. I. Stassinopoulos, and M. P. K. Drakos, "Local and remote management integration for flexible service provisioning to the home", IEEE Comm. Mag., vol.45, no.10, pp.130-138, Oct. 2007. P. Belimpasakis, S. Moloney, V. Stirbu, and J. Costa-Requena, "Home media atomizer: remote sharing of home content - without semi-trusted proxies", IEEE Trans. on Consumer Electronics, vol.54, no.3, pp.11141122, August 2008. Young Min Baek, Sang Chul Ahn, and Yong-Moo Kwon, "UPnP network bridge for supporting interoperability through non-IP channels", IEEE Trans. on Consumer Electronics, vol.56, no.4, pp.2226-2232, Nov. 2010. Taein Hwang, Hojin Park, and Jinwook Chung, "Personal Mobile A/V Control Point for Home-to-Home Media Streaming,", IEEE Trans. on Consumer Electronics, vol.54, no.1, pp.87-92, Feb. 2008. Z. Etzioni, K. Feeney, J. Keeney, and D. O'Sullivan, "Federated homes: secure sharing of home services", IEEE Consumer Communications and Networking Conf. (CCNC), pp.989-994, 9-12 Jan. 2011. Hyun Yong Lee and Jong Won Kim, "An approach for content sharing among UPnP devices in different home networks", IEEE Trans. on Consumer Electronics, vol.53, no.4, pp.1419-1426, Nov. 2007.

[22] M. Mahdi, O. Dugeon, R. Bars, and B. Lamer, "New UPnP service for multimedia remote sharing with IMS framework", Int. Conf on Intelligence in Next Generation Networks, pp.1-6, 11-14 Oct. 2010. [23] Chuan-Feng Chiu, S. J. Hsu, and Sen-Ren Jan, "The design of UPnPbased home environment over peer-to-peer overlay network", IEEE Int. Conf. on Ubi-Media Computing, pp.508-512, July 31 2008-Aug. 1 2008. [24] J. M. S. Santana, M. Petrova, and P. Mahonen, "UPNP service discovery for heterogeneous networks", IEEE Int. Symp. on Personal, Indoor and Mobile Radio Communications, pp.1-5, 11-14 Sept. 2006. BIOGRAPHIES Paolo Bellavista (M’97-SM’06) graduated from the University of Bologna, Italy, where he received a Ph.D. in computer science engineering in 2001. He is now an associate professor of computer engineering at the same university. His research activities span from middleware for mobile computing in general to location/context-aware services, from adaptive multimedia in wired/wireless integrated networks to smart space management, from opportunistic vehicular sensing to mobile agent technologies. He serves on the Editorial Boards of IEEE Communications Magazine, IEEE Transactions on Computers, IEEE Transactions on Services Computing, IEEE Transactions on Network and Service Management, and Elsevier Pervasive and Mobile Computing Journal. He is a senior member of IEEE and ACM. Paolo Gallo received the degree in telecommunications engineering from Politecnico di Torino, Italy, in 2001. In the same year he joined Telecom Italia and was involved in activities related to the study and simulation of Wi-Fi standards, specification and coding of embedded software for residential gateway platforms and scouting of home networking technologies with focus on video distribution inside the home network. Carlo Giannelli (M’05) graduated from the University of Bologna, where he received a Ph.D. in computer science engineering in 2008. He is now a postdoctoral researcher in computer engineering at the same university. His primary research activities focus on positioning systems management and heterogeneous wireless interface integration, in particular considering hybrid infrastructure/ad hoc and spontaneous multi-hop networking environments. He is a member of IEEE and ICST. Giorgio Toniolo graduated from the University of Bologna in computer engineering in 2009. He collaborated with Telecom Italia for one year funded under the Working Capital project for the development of UPnP-based spontaneous networks. He currently works with Exprivia SpA on the development of radiological medical products. Aldo Zoccola graduated in electronic engineering from the Polytechnic of Turin, Italy, in 1991. He worked at Digital Equipment Corporation becoming a senior software engineer. Then he joined Telecom Italia, holding technical managing positions on E-Commerce, IPTV, Fixed-Mobile Convergence in the Digital Home. He is now managing developments focusing on VoIP, Messaging and Video on mobile devices.