IEEE Transactions on Consumer Electronics, Vol. 55, No.

3, AUGUST 2009
Contributed Paper
Manuscript 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 integrating
either wired networks or single-hop wireless networks into
UPnP networks, integrating ZigBee with UPnP is more
difficult 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 gateway
mirrors ZigBee network topology; therefore, it creates,
terminates, and updates virtual UPnP proxies according to
ZigBee topology changes. Thus, the proposed
internetworking architecture dynamically and automatically
integrates ZigBee devices into the UPnP network and
provides seamless internetworking between a multi-hop
ZigBee network and the UPnP network. We have
demonstrated 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 and
seamless internetworking
1
.

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,

1
This work was supported by Korea Science & Engineering Foundation
through the NRL Program
Seong Hoon Kim, Daeyoung Kim, and Young-Joo Kim are with Korea
Advanced 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 Electronic
and Telecommunication Engineering, Kangwon National University, 200-701,
Korea (e-mail: sleeper82@control.kangwon.ac.kr and hspark@kangwon.ac.kr).
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 between
UPnP 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 mobile
nodes 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.

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 Work
Due 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 pervasive
systems. 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 requires
Shaman 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 components
by 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 Considerations
UPnP 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 following
design 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 and
attribute naming
Profile ID and in-
out clusters(binary)
Template-based naming
and predefined
Initial
communication
method
Unicast and
broadcast
Unicast and multicast
Discovery and
registration
Query-based
Query-and announcement-
based
Service discovery
infrastructure
Nondirectory-based Nondirectory-based
Service
Information state
Hard state soft state
Discovery scope
Network topology
(multi-hop ad-hoc
network)
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 status
inquiry
N/A Notification and polling

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

1288
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 first
explain ZigBee network topology monitoring schemes. Then,
we describe UPnP-ZigBee gateway architecture together with
mapping framework between UPnP and ZigBee.
A. Monitoring ZigBee Network Topology
Monitoring 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 monitoring
Reactive 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 monitoring
Proactive 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 long
delay. 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 monitoring
Differently 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 hello
messages. 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. Agents
located 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

S. H. Kim et al.: UPnP-ZigBee Internetworking Architecture Mirroring a Multi-hop ZigBee Network Topology 1289
network monitoring scheme is that these days the network
management including topology management is basic
functions and such functions are maintained at the Internet
side 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 Gateway
In this subsection we illustrate system components of a UPnP-
ZigBee gateway as depicted in Fig. 1 and a mapping framework
between 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 depending
on 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. Along
with 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 of
corresponding 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 ZigBee
As 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 device
description 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_M
Device 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.

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

1290
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 a
set 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 problem
would 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 AND
ZIGBEE
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 Flow
1) 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 UPnP
middleware 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 phase
A 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 phase
In 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 registry
Virtual 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 number
UDN Device Id
Service Service list
Device
Device List End point list
Action
Stringy function prototype and
corresponding function pointer
Service
Service State Table Variable list

S. H. Kim et al.: UPnP-ZigBee Internetworking Architecture Mirroring a Multi-hop ZigBee Network Topology 1291
the changed short address and corresponding long address to
the 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 Flow
After 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) Eventing
Since 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

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

1292
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., cluster
ID). 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 proposed
architecture.
A. Implementation
Since 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 in
the 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 desktop
running 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 ensuring
that 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



B. Experimental Results
Based 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, I
s
,
can be given by
I
s
= t
]
+t
sc
+p
c
,
where t
]
is the time from detection of a new node join in the
ZigBee network to its reception of the join indication at UZG,
t
sc
is the time for service information collection, and p
c
is the
time taken to create a VUP. t
]
is dependent only on the
ZigBee network, so we do not measured it but measured
t
sc
and p
c
. Since there was only one active end point in a
ZigBee node in our testbed, totally, four ZigBee messages are
involved (i.e., active endpoint req/rsp and one simple
descriptor req/rsp). Based on this configuration, t
sc
is
measured up to five hops as shown in Table 4, and p
c
is
shown in Table 5. In Table 4, service collection delay in one
hop is even smaller than others. This is because, in one hop
communication, there is no route discovery procedure whereas
route discovery procedure is involved in more than two hops
communications.
Similarly, shutdown time, I
sd
, as illustrated in Fig. 3, is
given by
I
sd
= t
I
+p
t
,
where t
I
is the time from detection of a node leave in a
ZigBee network to reception of its indication at a UZG, and
p
t
is the time taken to terminate a corresponding VUP at a
UZG. With the same reason of t
]
, we did not measure t
I

but p
t
, which is shown in Table 5.
Action invocation delay, I
u
, shown in Fig. 6 mainly affects
the performance of the proposed UZG at runtime; therefore,
we also measured the action invocation delay which is given
by
I
u
= t
uq
+p
uq
+t
zn
+p
u
+t
u
,
where t
uq
and t
u
are action request and response processing
delay by UPnP, respectively, p
uq
and p
u
are the time to
translate the action request and response at a corresponding
VUP, and t
zn
is the time taken from transmission of a ZigBee
data request to reception of corresponding response from the
ZigBee node. Note that t
uq
and t
u
include respective
transmission delay over UPnP network.
Table 6 shows the numerical results of T
aI
in detail. Indeed,
T
aI
is dependent on the types of ZigBee nodes. We measured
T
aI
under both of ZigBee device types (Router and End device).
As appeared in Table 6, actual translation time (p
uq
+p
u
) in
the UZG is very short where it is negligible in comparison
with t
zn
and (t
aq
+t
ar
).
VI. CONCLUSION
In this paper, we have presented the UPnP-ZigBee
internetworking architecture. Unlike existing integration
architecture, we have considered multi-hop communication
and 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 (T
a|
) in ms

t
zn

p
aq
+p
ar

t
aq
+t
ar

T
a|

Dev
type
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.3
Min 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 (p
uc
) Termination (p
ut
)
Mean (ms) 59.2 417.4
Std 4.9 0.8
Max (ms) 69.2 419.8
Min (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 (t
xc
)
Hops 1 2 3 4 5
Dev type R ED R ED R ED R ED R ED
Mean (ms) 218.7 1144 902 1799 898 1826 956 1828 1019 1830
Std 0.00006 6 135 71 117 91 114 73 235 77
Max (ms) 218.8 1156 1156 1937 1078 1969 1140 1937 1937 1953
Min (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 Topology 1293

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

1294
proposed architecture provides dynamic integration and
seamless internetworking with negligible overhead.
REFERENCES
[1] Zigbee Alliance, "Zigbee specification: Zigbee document 053474r13
Version 1.1," 1 Dec. 2006. Web site: www.zigbee.org
[2] Universal Plug and Play (UPnP) Device Architecture Reference
Specification 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.h
omeheartbeat.com/HomeHeartBeat/index.htm
[5] I. Hwang, and J. Baek, Wireless Access Monitoring and Control
System 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/UPnP
Software Bridge, IEEE Trans. Consumer Electron, Vol. 51, No. 1, pp.
319-323. Feb. 2005.
[8] J. Nakazawa, H. Tokuda, W. Edwards, and U. Ramachandran. A
Bridging Framewark for Universal Interoperability in Pervasive
System, 26
th
IEEE International Conference Distributed Computing
Systems 2006,
[9] Y. Gsottberger, X. Shi, G. Stromberg, T. F. Sturn, and W. Wber.
Embedding Low-Cost Wireless Sensors into Universal Plug and. Play
Environments, 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 and
middleware to enable programmable pervasive spaces, In Proceedings
of the 31st IEEE Conference on Local Computer Networks, November
2006.pp 630638.
[13] R. c. Wang, R. S. Chang, and H. C. Chao, Internetworking Between
ZigBee/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 Sensor
Control for Home Networks, 16
th
IST Mobile and Wireless
Communications 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, Microsoft
Developers 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 Broadcast
Storm Problem in a Mobile Ad Hoc Network, in Proc. of the 5th annual
ACM/IEEE international conference on Mobile computing and
networking, pp. 151-162, Aug. 1999.
[19] T. Imielinski and S. Goel. Dataspace - querying and monitoring deeply
networked collections in physical space, IEEE Personal
Communications, 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: A
Management Architecture for Wireless Sensor Networks," IEEE
Communications 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 in
electronic and telecommunication engineering from
Kangwon National University, South Korea, in 2006 and
2008, respectively. Currently, he is pursuing Ph. D
degree in computer science from KAIST. His interests
include software architecture for communications, sensor
networks and wireless communications.

Kang Jeong Seok was born in Korea on February 4,
1982. He received the B.S. degree in department of
electronic and telecommunication engineering from
Kangwon National University, Korea, in 2006, August.
Since 2006, September, he pursues the M.S. degree in
department of electronic and telecommunication
engineering, Kangwon National University, Korea. His
main research interests include distributed middleware,
robot component middleware.

Hong Seong Park was born in Korea in 1961. He
received the B.S., M.S., and Ph.D. degrees from Seoul
National University, Seoul, Korea, in 1983, 1986, and
1992, respectively.
Since 1992, he has been with the Department of
Electrical and Computer Engineering, Kangwon National
University, 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 in
computer science from the Pusan National University,
Korea, in 1990 and 1992, respectively, and the PhD
degree in computer engineering from the University of
Florida in August 2001. Since February 2002, he has
been an associate professor with Department of
Computer Science, KAIST, Korea. From September 2001
to January 2002, he was a research assistant professor at
the Arizona State University. Dr. Kim worked as a research staff member with
ETRI, Korea, from January 1992 to August 1997. His research interests
include sensor networks, real-time and embedded systems, and robotics. He is
an associate director of Auto-ID Lab Korea (www.autoidlabs.org) and a
director 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. From
September 2007 to August 2008, he was a post doctor at
KAIST
Since September 2008, he has been a research professor
at KAIST. His interests include tool design, error
detection, and visualization for debugging in
parallel/distributed and embedded systems.