upnp-zigbee_internetworking_architecture_mirroring_a_multi-hop_zigbee_network_topology-tfr

7/30/2019 UPnP-ZigBee_internetworking_architecture_mirroring_a_multi-hop_ZigBee_network_topology-tfr

1/9

IEEE Transactions on Consumer Electronics, Vol. 55, No. 3, AUGUST 2009

Contributed PaperManuscript received July 12, 2009 0098 3063/09/$20.00 2009 IEEE

1286

UPnP-ZigBee Internetworking Architecture Mirroring

a Multi-hop ZigBee Network Topology

Seong Hoon Kim, Jeong Seok Kang, Hong Seong Park,Member, IEEE, Daeyoung Kim,Member, IEEE,and Young-Joo Kim, Member, IEEE

Abstract

In this paper, we present a UPnP-ZigBee

internetworking architecture. Different from traditional

internetworking architectures which focus on integratingeither wired networks or single-hop wireless networks into

UPnP networks, integrating ZigBee with UPnP is moredifficult because ZigBee nodes communicate over multi-hop

wireless network, and further their short addresses can be

changed due to mobility of ZigBee nodes. To cope with it, we

combine UPnP-ZigBee gateway with ZigBee network

topology monitoring functions. A UPnP-ZigBee gatewaymirrors ZigBee network topology; therefore, it creates,

terminates, and updates virtual UPnP proxies according to

ZigBee topology changes. Thus, the proposed

internetworking architecture dynamically and automaticallyintegrates ZigBee devices into the UPnP network and

provides seamless internetworking between a multi-hop

ZigBee network and the UPnP network. We havedemonstrated the proposed architecture by implementing

both the UPnP-ZigBee gateway and network monitoring

functions and integrating them together. By conducting

experiments on physical testbed, we have shown that the

proposed architecture provides dynamic integration andseamless internetworking1.

Index Terms UPnP-ZigBee gateway, ZigBee network

topology monitoring, multi-hop networks.

I. INTRODUCTION

ZigBee [1] is a wireless standard whose goals are to support

low power, low cost, and low data rate communication. Due to

such unique characteristics of ZigBee, many researchers in

academy and industry pay more attention to development of

ZigBee compliant applications [3], [11], [12], [16] such as

aware-home [4]. In such applications several types of

numerous consumer devices [4] like door lock [5] can be

deployed.

In applying and deploying ZigBee-enabled devices into the

home or building environments, it is difficult to install and

configure a number of ZigBee devices. This is because the

number of devices tends to be scaled up to tens or hundreds of

ZigBee nodes. Furthermore, ZigBee devices should be

ultimately interconnected with other software, middleware,

1This work was supported by Korea Science & Engineering Foundationthrough the NRL Program

Seong Hoon Kim, Daeyoung Kim, and Young-Joo Kim are with KoreaAdvanced Institute of Science and Technology, Daejeon, Rep. of Korea(email: {shkim08, kimd, yjkim} @kaist.ac.kr).

Jeong Seok Kang and Hong Seong Park are with Department of Electronicand Telecommunication Engineering, Kangwon National University, 200-701,Korea (e-mail: [email protected] and [email protected]).

and networks like Internet in order to enable users to easily

access and to be provided with ZigBee services [6].

From this point of view, UPnP [2] is a good solution for

integrating ZigBee networks with Internet and for easily

configuring ZigBee devices. UPnP is a distributed open

networking architecture that leverages TCP/IP and Web

technologies to enable seamless proximity networking among

networked devices in the home, office, and everywhere in

between. In addition, UPnP supports zero-configuration

networking and automatic discovery of devices while

providing presentation functions through HTTP.

Due to the advantages, UPnP has been widely used for

those purposes. Existing integration approaches betweenUPnP and non-IP-based devices are [7], [8], [9], [10]. These

approaches employ virtual entities acting as proxies, which

perform general UPnP operations instead of non-IP-based

devices connected through wired (i.e., IEEE 1394) or one-hop

wireless communication (i.e., Bluetooth).

However, integration of ZigBee and UPnP is different from

the approaches above. This is because a ZigBee network

basically forms multi-hop network and supports limited

mobility of nodes. In case of former, for example, topology

changes such as join or leave of a ZigBee node should be

delivered to the gateway over multi-hop network, and then the

gateway represents it as a virtual UPnP proxy while keeping

consistency between them. In the latter case, since a mobilenodes short address is changed when it changes its parent

node, Internet hosts may send messages to the node with the

invalid short address. Consequently, the gateway translates

and forwards the packets to them. This results in unnecessary

processing overheads of the gateway and increases network

traffic and power consumption in ZigBee networks.

To cope with the problems above, we propose UPnP-

ZigBee internetworking architecture. To provide transparent

interoperation, a UPnP-ZigBee gateway (UZG)

creates/terminates virtual UPnP proxies acting as generic

UPnP devices by synchronizing UZG with connected ZigBee

network topology. This is enabled by injecting network

monitoring functions into the ZigBee network and combining

them into UZG. That is, when nodes join and leave a ZigBee

network, and even when nodes short address are changed due

to movement, the proposed internetworking architecture

provides seamless interaction between both networks.

Additionally, UZG enables ZigBee devices to use zero-

configuration facilities of UPnP. As a result, UZG can

dynamically and automatically integrates the ZigBee devices

into the UPnP network and provides seamless internetworking

between multi-hop ZigBee networks and UPnP networks.

AlultIXDoM1a1UfIX Ra


2/9

S. H. Kim et al.: UPnP-ZigBee Internetworking Architecture Mirroring a Multi-hop ZigBee Network Topology 1287

From the implementation and measurement on a physical

testbed, we demonstrate that the proposed internetworking

architecture is suitable for integrating ZigBee networks with

UPnP networks.

This paper is organized as follows: Section 2 illustrates

related works and design considerations. Then, Section 3

describes the proposed UPnP-ZigBee internetworking

architecture together with ZigBee network monitoring scheme.

In Section 4, data and management flows between UPnP and

ZigBee are described. Section 5 shows the implementation of

the proposed architecture and experimental results. Finally, we

end this paper with conclusion in Section 6.

II. RELATED WORK AND DESIGN CONSIDERATIONS

A. Related WorkDue to the advantages of UPnP, there have been several

works for bridging UPnP with non-IP-based networks. D. Kim

et al proposed UPnP-IEEE 1394 Software Bridge representing

legacy IEEE1394 devices to UPnP devices [7]. J. Nakazawa et

al. [8] proposed a bridging framework of universal

interoperability between UPnP and Bluetooth in pervasivesystems. Y. Gsottberger et al. [9] also proposed a system

architecture called Sindrion integrating UPnP with Bluetooth.

The former [7] built a bridge for UPnP with wired IEEE 1394

whereas latter two works only consider single-hop wireless

communication. Shaman [10] is a Java-based service gateway,

which integrate sensor -actuator module (SAM) with Jini and

UPnP, and each gateway service is a process (running in its

own Java VM) that belongs to only one. Following the leasing

concept, the service manager boots gateway services on

demand and shuts them down when they are no longer needed.

Even though Shaman provides dynamic integration, it does not

consider multi-hop communication. Moreover, it requiresShaman gateways as many as the number of SAMs in a

wireless network.

There are some researches for integration of ZigBee and

Internet [11], [12], [13], [14]. ArcWay [11] is a platform that

manufacturers can leverage as they build products that need to

connect and interact with other devices on a home network.

Based on Devices Profile for Web Services (DPWS)

specification [15], ArcWay is capable of translating the

ZigBee profile-based messages into XML schema-based

messages compatible with Web Services for Devices. Atlas

[12] is a service-oriented sensor and actor platform based on

the OSGi framework. The Atlas platform allows sensors and

actors to expose themselves as services to other componentsby combining hardware and software elements. In [13], R

Wang et al. proposed internetworking architecture for ZigBee

networks and IPv6 networks by adopting UPnP. They use

UPnP to easily discover services in ZigBee networks.

Analogously, in [14], the authors proposed UPnP-ZigBee

gateway based on Digital Living Network Alliance (DLNA)

architecture [16]. This is similar to ours in that they create

virtual entities performing general UPnP operations on behalf

of actual ZigBee devices. However, it is different in that

DLNA-ZigBee gateway frequently broadcasts several

discovery messages into ZigBee networks in order to collect

ZigBee devices and services information and to create virtual

UPnP proxies whereas the proposed UZG does not broadcast

the discovery messages by proactively maintaining ZigBee

devices and services information.

Even though the approaches [11], [12], [13], [14] integrate

ZigBee networks with middleware like DPWS, OSGi, and

UPnP and support dynamic integration of ZigBee devices

based on plug-and-play services provided by middleware, they

do not take network topology changes at runtime into account.Therefore, when certain nodes are moved or removed from a

ZigBee network and, as a consequence, becomes unavailable

due to short address changes, packets from Internet host to the

node cannot be delivered to the destined ZigBee node. Thus, it

incurs bandwidth and energy consumption and results in

invalid operations in the ZigBee network.

B. Design ConsiderationsUPnP is designed for the network with at least 10 Mbps and

relatively high computing power capable of processing XML-

based messages. On the other hand, ZigBee aims at supports

for low-cost, low-data rate, and low power consumption. Due

to such gaps between two standards, there are the followingdesign considerations for integration of ZigBee and UPnP.

Translating data format - data format in UPnP is based on

TEXT/XML. On the other hand, data format in ZigBee is

binary. Therefore, translation of data format between UPnP

and ZigBee is required.

Translating device description - application model in

UPnP and ZigBee differs from one another. UPnP defines

descriptions based on XML and discovers target devices using

Simple Service Discovery Protocol (SSDP). On the other

hand, ZigBee defines profiles, which includes a set of device

TABLE 1. COMPARISON OF ZIGBEE AND UPNP FEATURES OF

SERVICE DISCOVERY PROTOCOLS BASED ON MAJOR COMPONENT

CATEGORIES APPEARED IN [17](N/A: NOT AVAILABLE).

Feature ZigBee UPnP

Service andattribute naming

Profile ID and in-out clusters(binary)

Template-based namingand predefined

Initialcommunicationmethod

Unicast andbroadcast

Unicast and multicast

Discovery andregistration

Query-basedQuery-and announcement-

based

Service discoveryinfrastructure

Nondirectory-based Nondirectory-based

ServiceInformation state

Hard state soft state

Discovery scopeNetwork topology(multi-hop ad-hocnetwork)

Network topology (LAN)

Service selection Manual Manual

Service invocation Service location

Service location,communication mechanism(XML, SOAP, and HTTP),and application operations

Service usage N/A explicitly released

Service statusinquiry

N/A Notification and poll ing



3/9


description. Device discovery is performed by using in/out

cluster lists and a profile ID defined in the profile. Hence, it is

necessary to translate device descriptions of each standard.

Translating message format - formats of messages such as

control and event are differently standardized in UPnP and

ZigBee. Therefore, message formats between UPnP and

ZigBee must be translated.

Integrating different features of service discovery -

Interoperability of both service discovery protocols should be

provided by UZG. For that reason, we compare two standards,

ZigBee and UPnP, based on major component categories

appeared in [17]. Table 1 shows comparison of the service

discovery protocols. As shown in Table 1, their service

discovery protocols are quite different from one another.

Therefore, the different features of service discovery should be

dealt with.

Mirroring address changes in a ZigBee network In

ZigBee, when a node moves from one parent to another, the

short address of a node can be changed. Since most of

communication in ZigBee is based on the short address, the

gateway must be always aware of the changes of short address.Otherwise, transmissions to nodes with invalid short address

might be occurred and result in unnecessary processing

overhead and power consumption.

In the following section, we describe a proposed UPnP-

ZigBee Internetworking Architecture which enables dynamic

integration of ZigBee devices into UPnP network and

consistency between ZigBee devices and virtual UPnP proxies

at a UZG.

III. UPNP-ZIGBEE INTERNETWORKING ARCHITECTURE

The proposed internetworking architecture, which is

depicted in Fig. 1, is comprised of UPnP-ZigBee gateway and

ZigBee network topology monitoring. In this Section, we firstexplain ZigBee network topology monitoring schemes. Then,

we describe UPnP-ZigBee gateway architecture together with

mapping framework between UPnP and ZigBee.

A. Monitoring ZigBee Network TopologyMonitoring ZigBee network topology is an important

function in the proposed internetworking architecture. This

subsection describes ZigBee network monitoring schemes

which are divided into reactive monitoring, proactive

centralized monitoring, and proactive cluster-based

monitoring.

1) Reactive monitoringReactive monitoring is to discover devices and services in

an on-demand manner. That is, when control points in UPnP

networks sends a SSDP message, UZG translates it into a

ZigBees Match_desc_req message (service discovery) and

broadcast it over a ZigBee network. When a service

invocation is requested, UZG need to send IEEE_addr_req

(device discovery) to translate IEEE address into 16 bits short

address, which increases latency, network traffic and power

consumption. To reduce the overhead, cache mechanism can

be employed. The DLNA-ZigBee gateway [14] optionally

supports this approach. However, a main problem of this is

that if nodes moves and their short addresses are changed

before the expiry of cache timeout, it is possible that there is

inconsistency between UZG and the connected ZigBee

network. Accordingly, packets destined to the nodes cannot be

delivered until next device discovery.

2) Proactive centralized monitoringProactive centralized monitoring can be carried out in two

ways without modification to ZigBee stack. One way is that a

ZigBee PAN coordinator periodically broadcasts a

management neighbor request message (Mgmt_Lqi_req or

IEEE_addr_req in ZDO) to receive neighbor information

(Mgmt_Lqi_ rsp or IEEE_addr_rsp in ZDO). This approach

causes a broadcast storm problem [18] and a response

implosion problem [19], and hence it results in loss of some

necessary neighbor response messages. Another way is that a

PAN coordinator periodically sends a unicast message to each

ZigBee router in a width first traversal manner along ZigBee

tree address hierarchy. It is able to avoid the broadcast storm

and response impulsion problem but still suffers from longdelay. In [20] and [21], they employ the latter approach.

Even though both ways have such drawbacks, they do not

need to broadcast the device discovery message to the ZigBee

networks before sending application messages because the

UZG proactively maintains synchronization between actual

ZigBee devices with VUPs.

3) Proactive cluster-based monitoringDifferently from the preceding approach, cluster-based

approach is router-oriented local continuous monitoring.

When a new node joins a ZigBee network, the parent node of

the new node informs the PAN coordinator of the join. Once

the node is associated with the parent node, the parent node

locally monitors its child nodes by periodically sending hellomessages. When a certain child node does not reply to the

hello message, the parent node regards it as leave of the

neighbor node. Then, the parent node notifies the PAN

coordinator of the node leave. Accordingly, the PAN

coordinator can synchronize itself with the ZigBee network.

This approach removes the drawbacks of the previous two

approaches. For this reason, this approach is the most

commonly used in general ad hoc network management

architecture such as ANMP [22] and MANNA [23].

In our architecture we choose cluster-based monitoring.

However, since ZigBee does not support this type of

monitoring, we defined the following two network entities

called agent and local manager at application layer. Agentslocated in all nodes except for a PAN coordinator respond to

requests for information from a local manager. Local

managers located in a PAN coordinator and routers are

responsible for monitoring their child nodes by periodically

sending hello messages. When child nodes join or leave its

network, local managers notify UZG of the changes.

It is worth noting that the cost of monitoring is not

negligible. Nonetheless, the reason that we employ the



4/9


network monitoring scheme is that these days the network

management including topology management is basic

functions and such functions are maintained at the Internetside through gateways [22], [23]. In this view, our architecture

is nothing more than integration of the partial functions of

management facility and gateway functions.

B. UPnP-ZigBee GatewayIn this subsection we illustrate system components of a UPnP-ZigBee gateway as depicted in Fig. 1 and a mapping frameworkbetween UPnP and ZigBee.1) System Components

ZigBee device manager (ZDM) is primarily responsible to mirror

an actual ZigBee network. Mirroring the ZigBee network is

achieved by maintaining a mirror registry containing device (short

and extended address) and service (simple descriptors dependingon the number of active endpoints, a power, a node, a complex, and

a user descriptor) information of all ZigBee devices. To do this,

ZDM contiguously keep track of the ZigBee network changes by

collaborating with local managers and agents. Additionally, ZDM

is in charge of reporting the changes to virtual UPnP proxy

manager in order to keep synchronizing the virtual UPnP proxies

with the actual ZigBee devices.

Application object manager (AOM) manages application objects

(APOs) and assigns an end point number to each APO. APOs

within the gateway are discerned via a simple descriptor containing

an end point number and a corresponding name. These APOs are

capable of processing ZigBee application messages; therefore, they

can communicate with APOs in the actual ZigBee network. Alongwith it, every APO has a stringy device description (SDD) and a

message converter (MC). The SDD is used for generating UPnP

description and creating virtual UPnP proxies, which will be

described in next subsection. The MC is used for translating

ZigBee application message into UPnP messages and vice versa.

Virtual UPnP proxy (VUP) plays a role of a general UPnP

device, which performs advertisement, control, and eventing

on behalf of a ZigBee device. A VUP is a dynamic proxy that

automatically begins and shuts down according to whether the

corresponding ZigBee device exists on the network or not.

Virtual UPnP Proxy Manager (VUPM) is primarily

responsible for creating VUPs and manages the life cycle of

virtual UPnP devices in accordance with presence ofcorresponding actual ZigBee devices. The VUPM generate

UPnP description to create VUPs by using the SDD delivered

from ZDM and also register the VUPs into UPnP middleware

to execute them. It is important to note that VUPM only keep

track of the mirror registry in ZDM which continuously

maintains synchronization between mirror registry and the

connected ZigBee network.

2) Mapping different features between UPnP and ZigBeeAs discussed in subsection II.B, to internetwork UPnP and

ZigBee, data format, device description, and message format

in ZigBee must be translated. Enabling these in our

architecture is to use the SDD. The SDD is a stringy devicedescription translated from binary-based ZigBee device

description. As depicted in Table 2, it includes device Id,

service list, variable list and other information needed for

internetworking in between. Mappings between SDD and

UPnP description are shown in Table 3. Here, we describe

device Id, service list, and variable list.

Device Id (DevId_M) composed of end point number (8

bits) and long addresses (64 bits) is to identify a unique

service in a ZigBee node and is used as unique device name

(UDN) in UPnP as well. That is, the device Id is used to

TABLE 2.DATA STRUCTURE OF STRINGY DEVICE DESCRIPTION

(OPTIONAL AND RECOMMENDED ARE OMITTED)

Field name (String

type)Description

DeviceType_M Type of device

FriendlyName_M User friendly name

Manufacturer_M Manufacturer

ModelName_M Name of model

DevId_MDevice Id [end point number :Long

address] (9 bytes)

ServiceList_M

A set of services. Each service consists of a

set of function pointer and corresponding

string-based function prototype pair.

VariableList_M A set of stringy variables that devices use.

Fig. 1. A UPnP-ZigBee internetworking architecture integrated with ZigBee network monitoring functions.



5/9


identify a unique ZigBee service in both UPnP networks and

ZigBee networks. This is the address translation. A service is

an element corresponding to a service in UPnP. Each service

consists of a list of a pair of function pointer and the

corresponding stringy function prototype implemented by

APO based on ZigBee profiles. It is used to generate UPnP

description and translate messages. Finally, variable list is aset of variable names used in ZigBee profile and some of them

are state-related variables, which are translated into service

state variables and used for indicating state changes in UPnP.

Along with translations, it is necessary to integrate service

discovery between UPnP and ZigBee. However, due to the gaps

like different behavior of service discovery, bandwidth

requirements and processing capability between UPnP and

ZigBee operating environments, directly embedding the different

service discovery features into one another is not suitable. For

instance, if announcement function in UPnP is embedded into

each ZigBee device, it would increase multi-hop ZigBee network

traffic and power consumption. Furthermore, since a ZigBee

network scales up to tens or hundreds of nodes, the problemwould be even more worsen.

Considering the problems above, we do not translate UPnP

service discovery protocols and do not embed announcement

functions into ZigBee devices. Rather, we completely separate the

concerns of each standard. By combining UPnP-ZigBee gateway

with ZigBee network topology monitoring, we solve the

problems. Namely, ZDM continuously monitors and updates its

mirror registry by collaborating with a connected ZigBee network

and informs VUPM of changes in the ZigBee network; as a

consequence, VUPM creates, terminates, and updates any

correspondent VUPs according to the mirror registry, which is

shown in Fig. 2. As a result of it, control points (CPs) in UPnP

networks can access remote ZigBee devices as if they control

general UPnP devices located in the same network.

IV. MANAGEMENT AND DATA FLOW BETWEEN UPNP ANDZIGBEE

Internetworking UPnP and ZigBee involves two types of

message flows: management flow and data flow. The former is

for starting, shutting down, and updating VUPs according to

varying ZigBee network topology, and the latter includes action

invocation and event subscription/notification.

A. Management Flow1) Startup phase

A startup phase includes the procedures from ZigBee node

join to a corresponding VUP creation. The procedure is shown

in Fig.3 (1). On receipt of a message indicating a new node join,

the ZDM collects device and service information (i.e., long and

short address, and descriptors) of the new node. The collection

procedure is as follows. The ZDM first sends an Active_EP_req

message. On receipt of Active_EP_rsp, it sends

Simple_Desc_req according to the number of active endpoints

in the node. Finally, from the received Simple_Desc_rsp, the

ZDM learns what kinds of services are provided by the ZigBee

node. Then, the ZDM finds APO(s) matched to discovered

simple descriptor(s) through the AOM. If the AOM has

corresponding APO(s), the AOM returns SDD(s) with message

converter(s) to ZDM. Next, the ZDM indicates the addition of

new devices with device id, SDD and message converter to the

VUPM.Subsequently, the VUPM generates UPnP descriptions

by using the SDD. The VUPM in turn creates a VUP by using

the generated UPnP description, registers it to UPnPmiddleware and starts it. From this time, control points are able

to discover the ZigBee devices through UPnP discovery

functions and access the ZigBee device as if it accesses a

general UPnP device.

2) Shutdown phaseA shutdown phase is similar to the startup phase described

above except for removing the corresponding VUP. It is shown

in Fig.3 (2). Every time existing ZigBee nodes leave the ZigBee

network, the UZG immediately perceives it and then remove the

corresponding VUPs. Finally, all control points on the UPnP

network can recognize the removal of ZigBee devices because

the VUPs explicitly send disconnection message (byebye) to all

the control points before termination.Note that when nodes leave, ZDM delivers device id(s)

within the leave indication message. Since it is possible that

one node has more than two services, the VUPs corresponding

to the services must be removed as well when the node

providing the services leaves the network.

3) Update phaseIn ZigBee, when a node rejoins a ZigBee network through a

different parent node, its short address is changed, and the

node broadcasts an End_device_announce message containing

ZigBee Devices Mirror registryVirtual UPnP

Proxeis

IEEE address (8

bytes) + endpoint

number (1 byte)

(IEEE address +

endpoint number)

Device ID (9 bytes)

Device ID

UDN (9 bytes)

Monitor

Topology

changes

Plug

in/out

Fig. 2. Mirroring ZigBee devices into virtual UPnP proxies

TABLE 3.DEVICE AND SERVICE MAPPING OF UPNP AND ZIGBEE

(SIMPLIFIED)

Type UPnP Field name SDD field name

Device Type Profile ID

Friendly Name User Descriptor

Manufacture ComplexDesc.Manufacturer name

Model Description ComplexDesc.User define

Model Name ComplexDesc.ModelName

Model Number -

Serial Number ComplexDesc.Serial numberUDN DeviceId

Service Service list

Device

Device List End point list

ActionStringy function prototype andcorresponding function pointerService

Service State Table Variable list



6/9


the changed short address and corresponding long address tothe whole network. Because our architecture is able to access

ZDO public interface and be notified of the

End_device_announce message, the UZG immediately mirrors

the changed short address. Yet, the VUP transparently

operates regardless of short address change because a VUP is

identified via UDN comprised of long address and an endpoint

number, which are not changed at runtime.

B. Data FlowAfter discovering VUPs, CPs must be able to control any

ZigBee devices. This subsection describes how the CPs invoke

actions provided by the ZigBee devices, subscribe events, and

are notified of the events that have subscribed.1) Action Request/Response

UPnP CPs use SOAP as means for invoking actions

provided by UPnP devices. Hence, in UZG, SOAP messages

must be converted into corresponding ZigBee application

messages. A sequence diagram in Fig. 4 shows how an action

is processed. When a CP invokes an action, an action request

is first received by a VUP, and then the VUP calls translation

functions in a message converter. The message converter

translates stringy action request into binary-based ZigBee

application messages. Enabling this is that MCs have mapping

of a stringy function prototype and a corresponding function

pointer. Thus, stringy action invocation parameters in the

XML-based action request messages can be easily extracted

and translated into ZigBee binary messages based on the

ZigBee application profile. In this process, each sequence

number of the ZigBee binary messages is mapped with the

stringy action invocation parameters so that the corresponding

SOAP response messages can be delivered to the CPs that

have invoked the action.

2) EventingSince event messages like status changes, etc are crucial in

both ZigBee and UPnP, translating the event messages

between them is essential. However, UPnP provides event-

based communication in a publish/subscribe fashion whereas

ZigBee does not specify event-based communication.

Therefore, it is necessary to support event-based

communication in ZigBee networks and translate the messages

into UPnP event messages.

Fig. 5 depicts the sequences of (1) subscription request, (2)

event notification, and (3) cancellation of subscription. In a

Fig. 5. Sequence diagram of delivering event data (1) Subscription

request (2) Event notification (3) Cancellation of subscription.

Fig. 4. Sequence diagram for action request/response

Fig. 3. Sequence diagram for creation and termination of VUP



7/9


subscription phase, on receipt of a subscription request, the

VUP registers an event listener with a device ID and the

stringy parameters indicating event of interest into the

message converter. Then, the MC translates the device ID and

stringy parameters into ZigBee address (a long address and an

end pointer number) and ZigBee binary messages (i.e., clusterID). Finally, the connected APO sends a Bind_req message in

ZDO to the target ZigBee device by using the translated

parameters. Hereafter, all messages corresponding to the

bound events are delivered to VUPs according to the sequence

(2). Unsubscribing the event has the same sequence as

subscription except that it cancels the previously registered

callback function or bound events.

V. IMPLEMENTATION AND EXPERIMENTAL EVALUATION

We have described the design of UPnP-ZigBee

internetworking architecture so far. In this Section, we show

implementation and experimental results of our proposedarchitecture.

A. ImplementationSince the proposed UPnP-ZigBee internetworking

architecture consists of a UPnP-ZigBee gateway and ZigBee

network topology monitoring functions, we implemented both.

The proposed UPnP-ZigBee gateway was implemented using

C/C++. As for sensor nodes, we use six ZigBee nodes, and one

base station. The ZigBee base station [21] is connected to the

ZigBee gateway via RS232 (baud rate: 115200). In the base

station, we modified application framework and added an APO

in order to forward all messages from ZigBee nodes to the UZG

and vice versa. We observed that the code size of the APO inthe base station was 56 Kbytes. For UPnP, we used open source

UPnP stack [24]. As a result of our implementation, entire code

size of the UZG consumed 1348 Kbytes which did not include

third-party library like expat XML parser.

To exemplify our gateway, we also implemented one

message converter for home control lightening, based on a

profile [21] where the profile includes several device

description such as switch remote controller (SRC), switch

load controller (SLC), and light sensor monochromatic (LSM)

devices. The code size of the message converter was 25

Kbytes.

The UPnP-ZigBee gateway was hosted on the desktoprunning windows operation system, with a 1.7 GHz and 256

Mbytes RAM. We used a UPnP control point [25] to evaluate

the interoperability of the gateway and it was run on the

desktop, which uses windows operation system, with a 1.6

GHz, and 512 Mbytes of RAM. By using this tool, we could

confirm that the UPnP-ZigBee gateway provided not only

interoperability between UPnP and ZigBee but also

dynamicity. Fig. 6 depicts our overall testbed configuration.

With regard to the network topology monitoring functions,

we implemented a local manager and a agent. The local

managers are on each router and a PAN coordinator and

mainly monitor link status of its child by periodically sending

hello messages. When link status is changed due to either join

or leave of ZigBee nodes, local managers send join or leave

indication messages to the UZG. The agent is located in each

end device and simply responds to the hello message from its

parent. The code size of a local manager was 23 Kbytes and

that of an agent was 12 Kbytes.

To measure influence of multi-hop wireless networks we had

to make sure that all packets pass through over multi-hop. For

that reason, we reduced transmission range of all the sensor

nodes and the base station as short as possible by minimizing

transmission power. We set the maximum size of routing and

neighbor table of all the sensor nodes to zero and one,

respectively. Then we placed the nodes in a row while ensuringthat every node had only one child. As a result, every node

could communicate and associate with other nodes within about

20 cm and all packets were relayed along tree route.

During all experiments, we set the network mode as mesh

network and force all end devices to poll its parent every 1

second so as to receive pending data temporarily stored. We

made one node have only one device; therefore, one node can

be seen as one service. Every measurement is repeated 50

times.

Fig. 7. Control point discovered virtual UPnP proxies on left side and

reception of events regarding light level status on bottom-right side.

Fig. 6. Testbed configuration



8/9

B. Experimental ResultsBased on the testbed explained, we tested interoperability

between UPnP and ZigBee and measured performance of the

proposed UZG in terms of startup time, shutdown time, and

action invocation delay.

To test interoperability, we have executed the CPs user

interface (UI) and turned on the ZigBee devices. Consequently,

as shown in the left side frame of Fig. 7, we observed that the

ZigBee devices were presented in the UI. In addition, to see

the event notification functions, we subscribed a light level

state variable of a LSM device. As a consequence, the user

interface showed the subscribed state variable as shown in the

bottom-right frame of Fig. 7.

According to our design, startup time delay from join of a

ZigBee node to creation of a corresponding VUP is an

important factor. As illustrated in Fig. 3 (1), startup time, ,can be given by

,

where is the time from detection of a new node join in the

ZigBee network to its reception of the join indication at UZG,

is the time for service information collection, and is thetime taken to create a VUP. is dependent only on the

ZigBee network, so we do not measured it but measured

and Since there was only one active end point in aZigBee node in our testbed, totally, four ZigBee messages areinvolved (i.e., active endpoint req/rsp and one simple

descriptor req/rsp). Based on this configuration, ismeasured up to five hops as shown in Table 4, and isshown in Table 5. In Table 4, service collection delay in onehop is even smaller than others. This is because, in one hopcommunication, there is no route discovery procedure whereasroute discovery procedure is involved in more than two hopscommunications.

Similarly, shutdown time, , as illustrated in Fig. 3, is

given by

,

where is the time from detection of a node leave in aZigBee network to reception of its indication at a UZG, and

is the time taken to terminate a corresponding VUP at aUZG. With the same reason of , we did not measure

but , which is shown in Table 5.Action invocation delay, , shown in Fig. 6 mainly affects

the performance of the proposed UZG at runtime; therefore,we also measured the action invocation delay which is givenby

,

where and are action request and response processing

delay by UPnP, respectively, and are the time to

translate the action request and response at a corresponding

VUP, and is the time taken from transmission of a ZigBeedata request to reception of corresponding response from the

ZigBee node. Note that and include respective

transmission delay over UPnP network.

Table 6 shows the numerical results ofT in detail. Indeed,

T is dependent on the types of ZigBee nodes. We measured

T under both of ZigBee device types (Router and End device).

As appeared in Table 6, actual translation time ( ) in

the UZG is very short where it is negligible in comparison

with t and (t t).

VI. CONCLUSION

In this paper, we have presented the UPnP-ZigBee

internetworking architecture. Unlike existing integration

architecture, we have considered multi-hop communicationand mobility in ZigBee networks. By combining UPnP-

ZigBee gateway with ZigBee network topology monitoring,

the proposed internetworking architecture dynamically

integrates ZigBee devices into the UPnP network and provides

seamless internetworking between multi-hop ZigBee networks

and UPnP networks.

We have demonstrated the proposed architecture by

implementing UPnP-ZigBee gateway and the topology

monitoring functions and by integrated them together. By

carrying out a number of experiments, we have shown that the

TABLE.6.ACTION INVOCATION DELAY (INVOCATION OF

GETLIGHTSTATUS IN ONE HOP).

Action Invocation delay ( ) in ms

Devtype

R ED N/A N/A R ED

Mean 77.8 587.2 2.1 53 132.8 642.0

Std 3.7 310.8 0.4 9.2 10.9 312.0

Max 82.6 1099.6 3.1 84.1 171 1150.3Min 70.7 90.3 1.2 40.9 118.7 150.9

R: router, ED: end device

TABLE. 5. VIRTUAL UPNP PROXY CREATION AND TERMINATION

DELAY (INCLUDING TRANSMISSION OF ONE ANNOUNCEMENT

MESSAGE)

Creation (

) Termination (

)

Mean (ms) 59.2 417.4Std 4.9 0.8Max (ms) 69.2 419.8Min (ms) 51.0 416.7

TABLE.4.SERVICE COLLECTION DELAY OVER A MULTI-HOP ZIGBEE NETWORK

(ONE ACTIVE_EP_REQ/RSP AND ONE SIMPLE_DESC_REQ/RSP ARE INVOLVED IN OUR TEST SCENARIO).

Service collection delay ()

Hops 1 2 3 4 5

Dev type R ED R ED R ED R ED R EDMean (ms) 218.7 1144 902 1799 898 1826 956 1828 1019 1830

Std 0.00006 6 135 71 117 91 114 73 235 77Max (ms) 218.8 1156 1156 1937 1078 1969 1140 1937 1937 1953Min (ms) 218.5 1140 687 1703 687 1703 766 1703 750 1709

(R: router, ED: end device)

S. H. Kim et al.: UPnP-ZigBee Internetworking Architecture Mirroring a Multi-hop ZigBee Network Topolog 1293



9/9


proposed architecture provides dynamic integration and

seamless internetworking with negligible overhead.

REFERENCES

[1] Zigbee Alliance, "Zigbee specification: Zigbee document 053474r13Version 1.1," 1 Dec. 2006. Web site: www.zigbee.org

[2] Universal Plug and Play (UPnP) Device Architecture ReferenceSpecification Version 1.0. Microsoft Corporation, June 2000,

http://www.upnp.org[3] Wheeler, A. "Commercial Applications of Wireless Sensor Networks

Using ZigBee",IEEE Communications Magazine, Vol: 45, Issue: 4, pp:70-77, April 2007

[4] Eaton Corp., Eaton Home Heartbeat, http://www.homeheartbeat.com/HomeHeartBeat/index.htm

[5] I. Hwang, and J. Baek, Wireless Access Monitoring and ControlSystem based on Digital Door Lock,IEEE Trans. Consumer Electron,Vol. 53, No. 4, Nov. 2007

[6] Geer, D., Users make a Beeline for ZigBee sensor technology,Computer, 2005, 38, (12), pp. 1619

[7] D. Kim, J. Park., P. Yevgen., K. Moon, and Y. Kim. IEEE1394/UPnPSoftware Bridge, IEEE Trans. Consumer Electron, Vol. 51, No. 1, pp.319-323. Feb. 2005.

[8] J. Nakazawa, H. Tokuda, W. Edwards, and U. Ramachandran. ABridging Framewark for Universal Interoperability in Pervasive

System, 26

th

IEEE International Conference Distributed ComputingSystems 2006,[9] Y. Gsottberger, X. Shi, G. Stromberg, T. F. Sturn, and W. Wber.

Embedding Low-Cost Wireless Sensors into Universal Plug and. PlayEnvironments, LNCS 2920. Heidelberg Germany, 01/2004.

[10] P.Schramm, E. Naroska, P. Resch, P. Platte, H. Linde, G. Stromberg,and T. Sturm "A Service Gateway for Networked Sensor Systems,"

IEEE Pervasive Computing, pp. 66-74, 2004[11] Arcway, http://www.arcx.com/archronix/[12] Jeffrey King, Raja Bose, Hen-I Yang, Steven Pickles, and Abdelsalam

Helal. Atlas: A service-oriented sensor platform: Hardware andmiddleware to enable programmable pervasive spaces, In Proceedingsof the 31st IEEE Conference on Local Computer Networks , November

2006.pp 630638.

[13] R. c. Wang, R. S. Chang, and H. C. Chao, Internetworking BetweenZigBee/802.15.4 and IPv6/802.3 Network, SIGCOMM 2007 Workshop

IPv6 and the Future of the Internet, Aug. 2007[14] Kawamoto, R. Emori, T. Sakata, S. Furuhata, K. Yuasa, K. Hara,

S. DLNA-ZigBee Gateway Architecture and Energy Efficient SensorControl for Home Networks, 16th IST Mobile and WirelessCommunications Summit, 1-5 July 2007.

[15] S. Chan, D. Conti, C. Kaler, T. Kuehnel, A. Regnier, B. Roe, D. Sather,J. Schlimmer, H. Sekine, J. Thelin, D. Walter, J. Weast, D.Whitehead,D. Wright, Y. Yarmosh, Devices Profile for Web Services, MicrosoftDevelopers Network Library, February, 2006

[16] Digital Living Network Alliance, http://www.dlna.org/[17] F. Zhu, M. Mutka, and L. Ni, "Service Discovery in Pervasive

Computing Environments," IEEE Pervasive Computing, vol. 4, pp. 81-90, 2005.

[18] S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, and J.-P. Sheu, The BroadcastStorm Problem in a Mobile Ad Hoc Network, in Proc. of the 5th annual

ACM/IEEE international conference on Mobile computing andnetworking, pp. 151-162, Aug. 1999.

[19] T. Imielinski and S. Goel. Dataspace - querying and monitoring deeplynetworked collections in physical space, IEEE PersonalCommunications, 7(5):49, October 2000.

[20] Airbee-ZigBee Network Management System,http://www.airbeewireless.com/

[21] Texas Instruments, http://www.ti.com[22] W. Chen, N. Jain, and S. Singh, ANMP:Ad hoc network management

protocol,IEEE J. Select. Areas Commun., vol. 17, pp. 15061531, Aug.1999.

[23] L.B. Ruiz, J.M. Nogueira, and A.A.F. Loureiro, "MANNA: AManagement Architecture for Wireless Sensor Networks," IEEECommunications Magazine, vol. 41, no. 2, pp. 116125, 2003.

[24] CyberLink UPnP, http://www.cybergarage.org/net/upnp/cc/index.html

[25] Intel Device Spy, http://www.intel.com

Seong Hoon Kim received a B.S. and a M.S degree inelectronic and telecommunication engineering fromKangwon National University, South Korea, in 2006 and2008, respectively. Currently, he is pursuing Ph. Ddegree in computer science from KAIST. His interestsinclude software architecture for communications, sensornetworks and wireless communications.

Kang Jeong Seok was born in Korea on February 4,1982. He received the B.S. degree in department ofelectronic and telecommunication engineering fromKangwon National University, Korea, in 2006, August.Since 2006, September, he pursues the M.S. degree indepartment of electronic and telecommunicationengineering, Kangwon National University, Korea. His

main research interests include distributed middleware,robot component middleware.

Hong Seong Park was born in Korea in 1961. Hereceived the B.S., M.S., and Ph.D. degrees from Seoul

National University, Seoul, Korea, in 1983, 1986, and1992, respectively.Since 1992, he has been with the Department ofElectrical and Computer Engineering, Kangwon NationalUniversity, Korea. His research interests include design

and analysis of communication networks and mobile/wireless communication,discrete-event systems, and network-based control systems.

Daeyoung Kim received the BS and MS degrees incomputer science from the Pusan National University,Korea, in 1990 and 1992, respectively, and the PhD

degree in computer engineering from the University ofFlorida in August 2001. Since February 2002, he hasbeen an associate professor with Department ofComputer Science, KAIST, Korea. From September 2001to January 2002, he was a research assistant professor at

the Arizona State University. Dr. Kim worked as a research staff member withETRI, Korea, from January 1992 to August 1997. His research interestsinclude sensor networks, real-time and embedded systems, and robotics. He isan associate director of Auto-ID Lab Korea (www.autoidlabs.org) and adirector of the Global USN National Research Laboratory.

Young-Joo Kim received the B.S., M.S., and Ph.D.degrees from GyeongSang National University, Jinju,South Korea in 1993, 1999, and 2007, respectively. FromSeptember 2007 to August 2008, he was a post doctor atKAISTSince September 2008, he has been a research professor

at KAIST. His interests include tool design, errordetection, and visualization for debugging in

parallel/distributed and embedded systems.

upnp-zigbee_internetworking_architecture_mirroring_a_multi-hop_zigbee_network_topology-tfr

Documents