design and implementation of nemo based zigbee mobile router for healthcare...

Design and Implementation of NEMO based ZigBee Mobile Router for Healthcare System

Jin Ho Kim, Rim Haw, Eung Jun Cho, Choong Seon Hong

Department of Computer Engineering Kyung Hee University, Korea [email protected], [email protected],

[email protected], [email protected]

Jongwon Choe Department of Computer Science

Sookmyung Women’s University, Korea [email protected]

Abstract— In this paper, we focused on the scheme which supports mobility for ZigBee sensor nodes. We adopt NEMO protocol to provide mobility for low power ZigBee sensor nodes. Therefore, we propose NEMO based ZigBee Mobile Router architecture and operations to support the network mobility of ZigBee network. Also, we present the design and implementation of the ZigBee Mobile Router for healthcare system. The architecture is particularly useful to manage patient’s mobility where each patient is equipped with ZigBee sensor nodes.

Keywords- Network Mobility, NEMO, ZigBee, Sensor Network

I. INTRODUCTION ZigBee [1] is a low rate wireless communication

technology using small, low-cost and low-power sensors based on IEEE 802.15.4 [2] standard. In this paper, we focus on a scheme which supports mobility to ZigBee sensor nodes. In order to provide seamless mobility for low power sensor nodes, we need efficient mobility supporting protocols to maintain the connectivity while on the move. Such protocols include host mobility and network mobility. In case of host mobility as shown in Figure 1(a), when a sensor node moves to another link, each sensor node should have mobility function and exchange signaling messages to maintain the session. Hence, host mobility protocol such as Mobile IPv6 [3] is very inefficient for energy constrained sensor nodes. On the other hand, we assume that sensor network is homogeneous and mobility feature works as a unit of the network as shown in Figure 1(b) (same as Network Mobility (NEMO) [4]). So, we adopt NEMO protocol to support mobility for low power ZigBee sensor nodes. In case of ZigBee network mobility, it includes a ZigBee Mobile Router and a set of ZigBee sensor nodes. If NEMO is applied in the ZigBee sensor network, it can maintain connectivity with the Internet through the ZigBee Mobile Router as a network unit, even though each ZigBee node does not equipped with a mobility protocol. Only the ZigBee Mobile Router maintains Internet access when it changes its point of attachment to the Internet. Therefore, network mobility of ZigBee sensor nodes can be supported by an interoperable architecture between ZigBee and

NEMO. In this paper, we propose an interworking mechanism between ZigBee and NEMO to provide the network mobility of the ZigBee network. Also, we design and implement the ZigBee Mobile Router for healthcare system.

(a) (b)(a) (b) Figure 1. (a) Host Mobility vs. (b) Network Mobility

Our paper is organized as follows. In section II, we briefly introduce the concept of NEMO and ZigBee. In section III, we describe the architecture of NEMO based ZigBee Mobile Router and the operations to support network mobility of ZigBee network. In section IV, we present design and implementation of ZigBee Mobile Router for healthcare system. Finally, we conclude our work in section V.

II. BACKGROUND

A. Overview of NEMO Basic Support protocol The NEMO Basic Support protocol maintains the session

continuity for all mobile network nodes (MNNs) [3], even if the mobile router (MR) dynamically changes its point of attachment to the Internet. It also provides connectivity for all MNNs as it moves. NEMO Basic Support protocol has been standardized in RFC 3963 [4] to support network mobility. NEMO signaling messages such as binding update (BU) [5] and binding acknowledgement (BA) [5] are extended Mobile IPv6 messages. BU and BA messages have an additional mobile router flag ‘R’ to signal the MR. There are two modes for NEMO: explicit and implicit. In the explicit mode, one or more mobile network prefix (MNP) [5] options should be included in a BU message. Whereas in the implicit mode, instead of including MNP options, home agent (HA) [5] has to make a decision about the MNP owned

2010 10th Annual International Symposium on Applications and the Internet

978-0-7695-4107-5/10 $26.00 © 2010 IEEE

DOI 10.1109/SAINT.2010.55

69


978-0-7695-4107-5/10 $26.00 © 2010 IEEE

DOI 10.1109/SAINT.2010.55

77


978-0-7695-4107-5/10 $26.00 © 2010 IEEE

DOI 10.1109/SAINT.2010.55

77


978-0-7695-4107-5/10 $26.00 © 2010 IEEE

DOI 10.1109/SAINT.2010.55

77


978-0-7695-4107-5/10 $26.00 © 2010 IEEE

DOI 10.1109/SAINT.2010.55

77

by the MR and set up a forwarding mechanism for the mobile network, such as a dynamic routing protocol.

When the MR moves to a foreign link away from the home link, the MR sends the BU message to its HA with a new care-of address (CoA), which is the IPv6 address of the MR’s current point of attachment to the Internet. BU message also includes MNP option and ‘R’ flag. Upon receipt of the BU, the HA updates the MR’s information and it replies by sending a BA message. If the packets are sent to an MNN from a correspondent node (CN), the HA intercepts the packets and encapsulates them in a bi-directional tunnel to the MR. After that, MR decapsulates the packets and forwards them to the MNN. Reverse traffic must be tunneled to the HA before it is routed to the CN. NEMO Basic Support protocol specifies bi-directional tunneling so that only MRs and HAs need to be aware of the network mobility.

B. Overview of ZigBee IEEE 802.15.4 wireless standard was developed

specifically for remote monitoring and control. The standard defines transmission and reception on physical radio channel, and channel access, personal area network (PAN) maintenance, and reliable data transport. ZigBee defines topology management, MAC management, routing, discovery protocol, security management and includes IEEE 802.15.4 portions. ZigBee is battery operated and designed for the applications that need to transmit small amount of data. As a result the architecture of protocols and hardware for end devices should be lightweight in order to achieve lower power consumption.

The data transfer mechanism depends on the topology. ZigBee architecture recognizes two types of devices such as reduced function device (RFD) and full function devices (FFD). Only FFD defines full ZigBee functionality and can become a network coordinator. RFD has limited resources and does not allow some advanced functions (e.g. routing) as it is a low cost end device solution. Each ZigBee network has a designed FFD that is a network coordinator. The coordinator acts as the administrator and in charge of organization of the network. Typical coordinator has a neighbor table of devices found in the neighborhood. This leads to extended demands on the coordinator device, as it needs more memory and processing power.

III. PROPOSED MECHANISM This section covers the architecture of ZigBee Mobile

Router and interworking mechanism between ZigBee and NEMO.

A. Proposed NEMO Protocol to Support ZigBee Network Mobility To maintain the session connectivity and support global

mobility to ZigBee mobile network, a ZigBee Mobile Router should perform the home registration procedure to inform the HA regarding the movement of the ZigBee mobile network. In other words, whenever the ZigBee Mobile Router moves to a new network area, binding messages should be exchanged, and a bi-directional tunnel should be

established between the ZigBee Mobile Router and its HA. The ZigBee Mobile Router has two interfaces: An egress interface of the ZigBee Mobile Router can be directly attached to the access router in order to maintain Internet connection, and an ingress interface of the ZigBee Mobile Router acts as a ZigBee Coordinator for entire ZigBee sensor nodes.

If the ZigBee Mobile Router moves to another IPv6 network and detects its movement, it creates a CoA i.e. IPv6 address of ZigBee Mobile Router’s current point of attachment to the Internet. After that, the ZigBee Mobile Router sends a BU message to its HA in order to notify the movement. The BU message includes a proposed ZigBee PAN Coordinator option to inform the ZigBee PAN information. In this case, an additional ZigBee flag ‘Z’ should be set to notify the ZigBee Mobile Router in the BU message. At the same time, the ZigBee Mobile Router stores the mobility information in binding update list table and establishes a bi-directional tunnel between ZigBee Mobile Router and HA. Upon receipt of the BU, the HA updates ZigBee Mobile Router’s information with ZigBee network, CoA and home address for binding cache entry, and it replies by sending a BA message including an additional ZigBee flag ‘Z’. Figure 2 shows the proposed format of BU, BA and ZigBee PAN Coordinator option in detail.

0

PAN ID

ReservedLengthType

7 15 23 31

ZigBee Coordinator’s 16bits short address

Binding Acknowledgement

0

Sequence Number

7 15 23 31

Lifetime

Mobility Options

Status ReservedK R Z

Binding Update

0 7 15 23 31

Lifetime

Mobility Options

Sequence Number

ReservedA H L K M R Z

ZigBee Coordinator Option

0

PAN ID

ReservedLengthType

7 15 23 31

ZigBee Coordinator’s 16bits short address


0

Sequence Number

7 15 23 31

Lifetime

Mobility Options

Status ReservedK R Z

Binding Update

0 7 15 23 31

Lifetime

Mobility Options

Sequence Number

ReservedA H L K M R Z

ZigBee Coordinator Option

Figure 2. The proposed format of BU, BA and ZigBee PAN Coordinator

option

Figure 3 shows a scenario that a ZigBee mobile network moves to another link away from home link. In this scenario, some of ZigBee sensor nodes are deployed on a patient’s body for medical monitoring. Also, the patient has one ZigBee Mobile Router to support the network mobility to such ZigBee sensor nodes. These nodes monitor vital signs of patient such as temperature, blood oxygen saturation and pulse information. The patient has the freedom of moving in

7078787878

his room or within the hospital. The sensing data is sent to the Healthcare Server periodically.

Healthcare Server

AccessRouter 1 Access

Router 2

ZigBee MobileNetwork

ZigBee Mobile Network

Blood oxygen Saturation & Pulse Sensor

ZigBee Sensor Nodes

ZigBee Mobile Router

Home Agent

IPv6 Network

Temperature Sensor

Mobility header (next header)ZigBee PAN Coordinator

option

HoAoption

HA(IPv6 dst)

CoA(IPv6Src)

IPv6 Packet for BU

Base header

BU

Mobility header

HoAoption

HA(IPv6src)

CoA(IPv6 dst)

IPv6 Packet for BA

Base header

BA

move to another network

[ Binding Cache ]

HoA CoA

MR’s Home of Address

MR’s Care of Address

… …

PAN ID ZigBee Addr.

ZigBee PAN ID

16-bit short address

Binding Ack

Binding Update

ZigBee Mobile Router Figure 3. The scenario of interworking between ZigBee and NEMO

B. The Translation Procedure of ZigBee Mobile Router As IPv6 and ZigBee follow different suite of protocols,

an IPv6-ZigBee translation module needs to be installed in the ZigBee Mobile Router to translate the messages and perform address mapping between IPv6 host and ZigBee node. The ZigBee Mobile Router uses an IP address mapping table to track the source IPv6 address and renumbered address for each incoming packets. IP address mapping table relates IPv6 host’s real global IP address and IP-ID that was assigned by the ZigBee Mobile Router. IP-ID is a proposed temporary 16-bit address to distinguish source IPv6 address within the ZigBee network. The ZigBee Mobile Router can support a communication of heterogeneous networks by IPv6-ZigBee translation module.

Figure 4 shows the sequence diagram of communication between the Healthcare Server and ZigBee sensor nodes for IPv6-ZigBee translation module. Before establishing communication, the ZigBee Mobile Router broadcasts a Node Information Request message to all ZigBee sensor nodes within the PAN area, and ZigBee sensor nodes respond to a Node Information Reply message in order to inform its sensed data available. ZigBee Node Information table stores and updates address and sensor attribute of each ZigBee sensor node. When the Healthcare Server wants to get sensing information from ZigBee sensor nodes, it requests sensing data and receives responses from ZigBee sensor nodes. At this time, the ZigBee Mobile Router performs IPv6 to ZigBee and ZigBee to IPv6 message translation for each request and response packets.

Figure 5 and Figure 6 display the detailed procedure of IPv6-ZigBee translation. Figure 5 shows the procedure of data request. The translation process from IPv6 packet into ZigBee frame is as follows: When the Healthcare Server requests the sensing data packets to ZigBee sensor nodes, the ZigBee Mobile Router looks up the IP address mapping table to discover the source IP-ID for IPv6 address of the Healthcare Server. If the entry is not found, a new source IP-ID is assigned in order to maintain the connection between

the Healthcare Server and ZigBee sensor node. After creating the source IP-ID for the Healthcare Server, the translation module converts IPv6 packet into ZigBee frame. The source of the ZigBee frame is the ZigBee Mobile Router’s 16-bit address, and the destination is the ZigBee sensor node which has the requested attribute. The fields of Attribute and Message Type itself are used. The source IP-ID is added in the ZigBee frame.

Creating ZigBee NodeInformation Entry

IPv6 to ZigBeeTranslation

ZigBee to IPv6Translation

Node Information Request

Node Information Reply

ZigBee Sensor Node


Healthcare Server

Sensing Data Request

Data Request

Data Reply

Sensing Data Reply

Figure 4. The sequence diagram to communicate between the Healthcare

Server and ZigBee sensor nodes for IPv6-ZigBee translation module

Figure 5 and Figure 6 display the detailed procedure of IPv6-ZigBee translation. Figure 5 shows the procedure of data request. The translation process from IPv6 packet into ZigBee frame is as follows: When the Healthcare Server requests the sensing data packets to ZigBee sensor nodes, the ZigBee Mobile Router looks up the IP address mapping table to discover the source IP-ID for IPv6 address of the Healthcare Server. If the entry is not found, a new source IP-ID is assigned in order to maintain the connection between the Healthcare Server and ZigBee sensor node. After creating the source IP-ID for the Healthcare Server, the translation module converts IPv6 packet into ZigBee frame. The source of the ZigBee frame is the ZigBee Mobile Router’s 16-bit address, and the destination is the ZigBee sensor node which has the requested attribute. The fields of Attribute and Message Type itself are used. The source IP-ID is added in the ZigBee frame.

Figure 6 shows the procedure of data transmission. The translation process from ZigBee frame into IPv6 packet is as follows: When ZigBee nodes transmit the sensing data packets to the Healthcare Server, the ZigBee Mobile Router looks up the IP address mapping table to discover a destination IP-ID of ZigBee frames. If the destination IP-ID appears in the IP address mapping table, it is replaced with IPv6 address of the Healthcare Server, and the translation module converts ZigBee frame into IPv6 packet. The source of the IPv6 packet is the ZigBee Mobile Router, and the destination is the Healthcare Server. The fields of Attribute,

7179797979

Sensing Data and Message Type are stored in IPv6 payload. The source address of the ZigBee node is added in the Source ZigBee Address field of IPv6 payload.


ZigBee Frame

Source Address

(MR)

DestinationAddress(ZigBee)

MSG Type(Request)

SourceIP-ID

(16-bit)Attribute

Address Mapping Module

Source Address(IPv6)

MSG TypeZigBeeAddress(16-bit)

Attribute

Creating IP-IDSource

Address(IPv6)

SourceIP-ID

(16-bit)

ZigBee Addr. Attribute

ZigBee Sensor Node address Data attribute

… …

[ZigBee Node Information Table]

IPv6 Addr. IP-ID

Healthcare Server address

Temporary 16-bit IDfor Healthcare Server

… …

[IP Address Mapping Table]

ZigBee IPv6 Translator

Source Address

(MR)

DestinationAddress(ZigBee)

MSG TypeSourceIP-ID

(16-bit)

SourceIP-ID

(16-bit)MSG Type

ZigBeeAddress(16-bit)

DestinationAddress

(MR)

Attribute

Attribute

IPv6 Packet

Source Address(IPv6)

DestinationAddress

(MR)

MSG Type(Request)

AttributeZigBeeAddress(16-bit)

Figure 5. The procedure of data request


IPv6 PacketSource Address

(MR)

DestinationAddress(IPv6)

MSG Type(Data Reply)

DataSourceZigBeeaddress

ZigBee FrameSource

Address(ZigBee)

DestinationAddress

(MR)

MSG Type(Data Reply)

DestinationIP-ID

Data

ZigBee Addr. Attribute

ZigBee Sensor Node address Data attribute

… …

[ZigBee Node Information Table]IPv6 Addr. IP-ID

Healthcare Server address

Temporary 16-bit IDfor Healthcare Server

… …

[IP Address Mapping Table]

Address Mapping Table

Source Address(ZigBee)

MSG Type Data

Replacing IP-ID to IPDestination

Address(IPv6)

DestinationIP-ID

ZigBee IPv6 Translator

Source Address

(MR)


MSG Type

SourceZigBeeaddress

Source Address(ZigBee)

MSG Type


DestinationAddress

(MR)

Data

Data

DestinationIP-ID

Figure 6. The procedure of data transmission

IV. IMPLEMENTATION AND TEST We implement a simple IPv6 network and wireless test-

bed to support NEMO based ZigBee Mobile Router as shown in Figure 7. The test-bed is divided into two IEEE 802.11g wireless networks which have one wireless access point with a unique Extended Service Set Identifier (ESSID); home link and foreign link are set to HA and access router (AR), respectively. Also, each wireless network has an access router which can periodically advertise the router advertisement (RA) message including the prefix information. The access router of the home link acts as a HA for the ZigBee Mobile Router.

ZIGBEE-NEMO Daemon is developed for the ZigBee Mobile Router which is implemented in Linux kernel 2.6.11 using modified NEMO Platform for Linux (NEPL) [6]. The ZIGBEE-NEMO Daemon has two major functions: IPv6 packet��ZigBee frame translation module and proposed NEMO protocol to support of ZigBee network mobility.

Figure 8 shows the implementation environment for our proposed interworking mechanism between ZigBee and NEMO to apply it in the healthcare system. As shown in Figure 8, the ZigBee Mobile Router is implemented in the laptop which includes an egress interface to support IEEE 802.11 Wireless LAN and an ingress interface as a ZigBee Coordinator. ZigBee mobile network consists of two ZigBee sensor nodes, one of the nodes senses the pulse and blood oxygen saturation, whereas the other node senses the temperature of the patient. Packet sniffer is used to capture data being transmitted over a ZigBee network for analysis.

IPv6ROUTER

HA

AR

Healthcare Server

ESSID : HA

ESSID : AR


Figure 7. Test-bed to support NEMO based ZigBee Mobile Router

①

②

⑦

③

⑥ ④ ⑤

⑧

⑨

⑩⑪

⑫

⑬

① ZigBee Mobile Router ②WLAN Interface ③ ZigBee Host Node ④ ZigBee Sensor Node (Temperature) ⑤ ZigBee Sensor Node (Blood Oxygen Saturation & Pulse) ⑥ Sniffer Monitoring Program ⑦ Packet Sniffer Device ⑧ Healthcarecare Application ⑨ ZigBee Main Board ⑩ Sensor Board ⑪ Temperature Sensor ⑫ Sensor Board ⑬ Pulse & Blood Oxygen Saturation Sensor

Figure 8. Implementation environment for ZigBee network mobility

We also implement a TinyOS [7] based ZigBee communication protocol including the mesh routing module for both ZigBee Mobile Router and ZigBee sensor nodes as shown in Figure 9. ZigBee sensor nodes are able to get sensing data from sensor interface, and transfer the sensing information to 2.4GHz IEEE 802.15.4 ZigBee communication using Chipcon2420 RF module in the ZigBee Mobile Router. The ZigBee Mobile Router uses universal asynchronous receiver/transmitter (UART)

7280808080

component for universal serial bus (USB) interface to communicate between Linux kernel and TinyOS.

ZigBee Mobile Router ZigBee Sensor Node

TinyOS

ZigBee Network Layer

Data Process

Sensor.getData()/dataReady()

Routingtable

Chipcon2420RF module

Radio Queue

RadioSend/Receive.Send()/receive()

Sensor interface

Sensed value Queue

Neighbor table

Routing Process

Linux Kernel TinyOS

ZigBee Network Layer

Data Process

Routingtable

Chipcon2420RF module

Radio Queue

RadioSend/Receive.Send()/receive()

Neighbor table

Routing ProcessUart.get()

/dev/ttyUSB0.write()

Uart.get()

/dev/ttyUSB0.write()

/dev/ttyUSB0.read()

UARTSend.send()

/dev/ttyUSB0.read()

UARTSend.send()

FCF Destinationaddress

Sourceaddress

radius Sequence IP-ID Msgtype

attribute Sensingdata

MACHeader

Network Header Payload

Sensing Data (ZigBee Frame)

Figure 9. The structure of TinyOS based ZigBee communication module

Figure 10 and Figure 11 show function flow of ZIGBEE-NEMO Daemon to exchange binding message with ZigBee information between ZigBee Mobile Router and HA. Figure 10 shows a function flow to handle the BU message when the ZigBee Mobile Router moves to another link. The ZigBee Mobile Router detects movement through md_trigger_movement_event() and mn_movement_event() functions. Then it calls mn_move() and do_handoff() to perform the handoff. After the ZigBee Mobile Router creates CoA, it sends the BU message to its HA through some functions such as send_home_bu(), send_bu_msg() and mh_send(). And then, it saves binding update list using bul_add(). Finally, the BU message is sent by ip6_build_xmit(), ip6_output() and ip6_output_finish() in IPv6 module.


Home Agent

NEMOmd_trigger_movement

_event

mn_movement_event

mn_move

do_handoff

send_home_bubul_add

Binding Update

List

IPv6

Device

ip6_build_xmit

ip6_output

ip6_output_finish

dev_queue_xmit

NEMO

IPv6

Device

ha_mh_recv

Binding Cache Entry

bcache_add_homereg

bu_worker

ip6_input_finish

ip6_input

ipv6_rcv

net_rx_action

ipv6_parse_exthdrs

Binding Update

send_bu_msg

mh_create_opt_zigbee_coordintor

mh_send

mh_binding_update

mh_opt_parse

HoACoAFlagsLifetimeSequenceZigBee PAN IDZigBee 16-bit addr


Figure 10. The function flow to handle the BU message

When HA receives the BU message from net_rx_action() function, it handles the packet through ipv6_rcv(), ip6_input() and ip6_input_finish() functions in IPv6 module. If the BU packet is verified by ipv6_parse_exthdrs() function, then it is forwarded to ZIGBEE-NEMO Daemon in the HA, and processes the BU message through ha_recv_bu(), bu_worker() and mh_binding_update() functions. Also, ZigBee PAN Coordinator option is handled by mh_opt_parse() function. Finally, the HA saves the BU information in binding cache entry through bcache_add_ homereg() function.

Figure 11 shows a function flow to handle the BA message. Upon accepting the BU, the HA replies with the BA message by using send_ba() and mh_send() functions. When the ZigBee Mobile Router receives the BA message from net_rx_action() function in Wireless LAN device driver, it is forwarded to IPv6 module using ipv6_rcv(), ip6_input() and ip6_input_finish() functions. If the BA packet is verified by ipv6_parse_exthdrs() function, then it is forwarded to ZIGBEE-NEMO Daemon in the ZigBee Mobile Router. Finally, the HA processes the BA message through ba_rcv() function.

ZigBee Mobile Router Home Agent

NEMO

ba_rcv

bul_delete

IPv6

Device

NEMO

IPv6

Device

send_ba

ip6_input_finish

ip6_input ipv6_rcv

net_rx_action

ipv6_parse_exthdrs

bul_update

ip6_build_xmit

ip6_output

ip6_output_finish

dev_queue_xmit

Binding Update

List

Binding Cache Entry


ha_mh_recv

bu_worker

mh_binding_update

mh_sendmn_mh_recv



Figure 11. The function flow to handle the BA message

Figure 12 shows the handoff procedure of the ZIGBEE- NEMO Daemon when the ZigBee Mobile Router moves to foreign link away from home link. The following describes the detailed home registration procedure of the ZigBee Mobile Router how to perform the handoff to support ZigBee network mobility.

• Movement Detection: When the ZigBee Mobile

Router is attached to foreign link (AR link), it will receive the RA message from access router including prefix information of foreign network. And then the ZigBee Mobile Router should decide whether it is still in home link or has moved to foreign link by comparing the current prefix with the previous prefix in the RA message. If the ZigBee Mobile Router detects movement to foreign link, default route will be changed to new access router on an egress interface.

7381818181

• Binding Update: The ZigBee Mobile Router sends the BU message to its HA with ‘Z’ flag in order to notify the movement. The ZigBee bit (Z) is set by the sending ZigBee Mobile Router to indicate HA that the BU message is from the ZigBee Mobile Router and includes ZigBee PAN Coordinator option. Also, the ZigBee Mobile Router has to manage a binding update list which records a binding entry including the information of ZigBee mobile network.

• Bi-directional Tunnel: A bi-directional tunnel is established between ZigBee Mobile Router and HA. This tunnel seems like a virtual point-to-point link. All communications to and from ZigBee sensor nodes in a ZigBee mobile network should go through the bi-directional tunnel when the ZigBee Mobile Router moves to foreign link. The bi-directional tunnel provides mobility transparency to the ZigBee sensor nodes within ZigBee mobile network and the Healthcare Server.

• Binding Acknowledgement: When the ZigBee Mobile Router receives the BA message from the HA without any problem, the ZigBee Mobile Router completes home registration procedure successfully.

Movement Detection

Binding Update

Bi-directional Tunnel

Binding Acknowledgement Figure 12. ZIGBEE-NEMO Daemon

Figure 13 shows the binding cache in the HA, binding update list in the ZigBee Mobile Router and kernel routing table of the ZigBee Mobile Router. Binding cache maps home address and ZigBee information to the current CoA for the ZigBee Mobile Router. This allows the HA to tunnel the traffic to the ZigBee sensor node’s current location, and allows the Healthcare Server to send packets directly to the ZigBee Mobile Router at its current location. As we mentioned before, binding update list is maintained by the ZigBee Mobile Router. The list has an entry for every binding that the ZigBee Mobile Router has trying to establish with the HA. Each entry includes home address, current CoA, ZigBee PAN ID and ZigBee addresses of the ZigBee Mobile Router. Kernel IPv6 routing table represents routing entry of the ZigBee Mobile Router. When the ZigBee Mobile Router moves to foreign link, it changes the default route to a bi-directional tunnel interface.

Binding Cache Entry(with ZigBee information

in Home Agent)

Binding Update List Entry(with ZigBee informationin ZigBee Mobile Router)

IPv6 Routing Table(Representing Tunnel interface

with HA in ZigBee Mobile Router)

Figure 13. Binding cache in HA, binding update list in ZigBee Mobile

Router and kernel routing table of ZigBee Mobile Router

Src . Addr.Dest. Addr.

(1)

(2)

(3) (4)

(5)

Figure 14. IPv6-ZigBee translation procedure

Figure 14 describes the results of the IPv6-ZigBee translation module in the ZigBee Mobile Router. When the Healthcare Server requests the data to ZigBee sensor nodes, the ZigBee Mobile Router performs the packet translation operation. IPv6-ZigBee translation module converts the IPv6 request packet into the ZigBee frame and forwards it to ZigBee sensor nodes. After that, ZigBee sensor nodes reply the sensing data to the Healthcare Server. The following describes the detailed procedure of IPv6-ZigBee translation as shown in Figure 14.

1) The Healthcare Server receives information of ZigBee sensor nodes from the ZigBee Mobile Router.

2) The Healthcare Server requests the sensing data to ZigBee sensor nodes.

3) The ZigBee Mobile Router translates the IPv6 data request packet into ZigBee frame, and sends it to ZigBee sensor nodes.

7482828282

4) ZigBee sensor nodes reply the sensing data to the ZigBee Mobile Router.

5) The Healthcare Server receives the sensing data from the ZigBee Mobile Router.

We also develop the monitoring application for the

Healthcare Server. As mentioned before, we deploy ZigBee sensor nodes on a patient’s body to get the medical monitoring such as temperature, blood oxygen saturation and pulse information. Such sensing data is represented by three graphs in real-time respectively. Also, this monitoring application displays sensing values including patient and sensor nodes information in detail.

ACKNOWLEDGMENT This research was supported by the MKE, Korea, under

the ITRC support program supervised by the NIPA (NIPA-2010-(C1090-1002-0002)).

Dr. C.S. Hong is the corresponding author.

V. CONCLUSION In this paper, we focused on the scheme which supports

mobility for ZigBee sensor nodes. We adopt NEMO protocol to provide mobility for low power ZigBee sensor nodes. Accordingly, we proposed the interworking mechanism between ZigBee and NEMO to support the ZigBee network mobility. Also, we implemented NEMO based ZigBee Mobile Router for the healthcare system. As future works, we will evaluate the performance of our proposed mechanism under various mobility models.

REFERENCES [1] ZigBee Alliance, “ZigBee Specification”, January 2008. from

http://www.zigbee.org [2] IEEE Std. 802.15.4 Wireless Medium Access Control (MAC) and

Physical Layer (PHY) Specification for Low-Rate Wireless Personal Area Networks, May 2003.

[3] D. Johnson, C. Perkins, and J. Arkko, “Mobility Support in IPv6,” IETF RFC 3775, June 2004.

[4] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” IETF RFC 3963, January 2005.

[5] T. Ernst and H-Y. Lach, "Network Mobility Support Terminology," IETF RFC 4885, July 2007.

[6] NEMO Platform for Linux (NEPL), http://software.nautilus6.org/ NEPL-UMIP

[7] TinyOS Community Forum, http://www.tinyos.net

7583838383

design and implementation of nemo based zigbee mobile router for healthcare...

Documents