Mobile Middleware for Wireless Body Area Network - IEEE Xplore

32nd Annual International Conference of the IEEE EMBS
Buenos Aires, Argentina, August 31 - September 4, 2010
Mobile Middleware for Wireless Body Area Network
Xiang Chen, Agustinus Borgy Waluyo, Isaac Pek, and Wee-Soon Yeoh
Abstract— This paper presents a flexible, efficient and
lightweight Wireless Body Area Network (WBAN) Middleware.
The Middleware is developed to bridge the communication
between mobile device as a gateway and the sensor nodes, and
therefore it shields the underlying sensor and OS/protocol stack
away from the WBAN application layer. The middleware is
coded in the form of lightweight dynamic link library, which
allows the application developer to simply incorporate the
middleware resource dynamic link library into their
application and call the required functions (i.e. data
acquisition, resource management and configurations). A
showcase of the middleware deployment is exhibited at the end
of the paper.
Index Terms—lightweight middleware, mobile middleware,
wireless body area network middleware.
I. INTRODUCTION
ecent advances of miniaturized sensor devices are
Rcapable of collecting physiological data, carrying out
processing of the data, and then wirelessly transmitting this
information to the gateway. This interaction is commonly
known as Wireless Body Area Network (WBAN).
In WBAN, energy efficiency is extremely critical as
sensor nodes are powered by batteries. This issue together
with the growing variety of sensor devices in the market,
cause application development very difficult and time
consuming, especially for those who are not familiar with
networking protocol and real-time embedded OS. As such, it
is natural to design a middleware that shields the underlying
sensor hardware or OS/protocol stack from the higher-level
applications.
The proposed middleware helps to accelerate application
developer by utilizing highly reusable codes or a common
set of service API. The middleware supports mobile health
monitoring application using WBAN. The main functions of
this middleware include data acquisition, resource
reconfigurations and resource managements. As the
middleware is deployed in a mobile device, which has
inherent resource constraints (i.e. limited memory and
Manuscript received April 1, 2010. This work was supported by Science
and Engineering Research Council (SERC) of the Singapore Agency for
Science, Technology and Research (A*STAR) on Embedded & Hybrid
Systems II (EHS-II) programme under grant 052-118-0058.
Xiang Chen is with the Institute for Infocomm Research (I 2 R), A*STAR,
Singapore (e-mail: xchen@i2r.a-star.edu.sg).
Agustinus Borgy Waluyo is with the Centre for Distributed Systems and
Software Engineering, Monash University, Australia (e-mail:
Agustinus.Borgy.Waluyo@infotech.monash.edu.au).
Isaac Pek is with the Institute for Infocomm Research (I 2 R), A*STAR,
Singapore (e-mail: ipek@i2r.a-star.edu.sg).
Wee-Soon Yeoh is with the Institute for Infocomm Research (I 2 R),
A*STAR, Singapore (e-mail: wsyeoh@i2r.a-star.edu.sg).
processing power), it is particularly important to ensure an
optimized system design and coding.
Our preliminary work on WBAN middleware has been
reported in [1]. In the earlier work, the middleware is
designed as a separate application, which operates using
socket programming. However, this approach is very much
resource intensive and apparently not the best way to adopt
especially when the host device is lightweight. In this paper,
we present a new form of middleware in dynamic link
library (dll), which uses a call-back function instead of
socket mechanism. The architecture of the middleware has
been further optimized. The efficiency and size of this
middleware as compared to its predecessor are shown in this
paper.
The subsequent section is organized as follows. A detailed
description of the proposed middleware can be found in
Section II, followed by a showcase of the middleware
deployment in Section III. Finally, Section IV concludes the
paper.
II. MOBILE MIDDLEWARE FOR WBAN: ARCHITECTURE AND
FUNCTIONALITIES
The proposed mobile middleware is designed to support
multi-modal sensors, allowing different sensors types (e.g.
accelerometers, and ECG) to co-exist and transmit to a
common gateway.
A. Overview
The Middleware supports two-way
communication/interaction from applications to the
underlying sensor nodes. The programs that constitute the
WBAN Middleware reside in both the sensor nodes (Lower
Middleware) and the PDA (Upper Middleware). Figure 1
illustrates the overall system overview.
The Lower Middleware programs are coded in nesC using
TinyOS 2.1x, while the Upper Middleware is programmed
in C#. The upper and lower layers communicate over
wireless IEEE 802.15.4 (Zigbee) protocol, passing through a
base station node. This node utilizes the native BaseStation
program, provided by TinyOS.
B. Lower Middleware
The Lower Middleware relates to the functions and
processes inside the sensor node. The main tasks of this
Lower Middleware are; (i) to establish radio communication
with the sensor gateway, (ii) to support data sensing and
reporting, (iii) to supply single node streaming service, (iv)
to provide configurations capability and (v) to enable
resource control and management. To realize this, the Lower
Middleware incorporates several components, and provides
a user defined function for the developer to utilize based on
978-1-4244-4124-2/10/$25.00 ©2010 IEEE 5504

the nature of their application. The components and the
functions are further described below.
Sensor
Gateway
PDA(C#)
Mobile Health Application
Mobile Middleware
(Upper Middleware)
Wireless Communication
The ADC Channel should correspond to the physical
hardware (i.e. the sensor should be physically connected to
ADC Channel 1 - if “ADC_CHANNEL = 1” is specified).
The Channel Number allows applications to determine the
origin of the data in a radio packet. The channel number
uniquely identifies each data stream originating from the
sensor node (SingleChannelSensor only has one
channel). The sampling rate parameter lets the developer to
modify the sampling frequency of the sensor. To distinguish
between different sensors, we provide sensor type parameter.
Sensor Nodes
(Lower Middleware)
Figure 1. System overview
• Components
We have designed two Lower Middleware programs, one
for a single stream of data coming out from the ADC (i.e.
ECG) and another is for multiple data streams (i.e three-axis
accelerometers), which is called SingleChannelSensor
and MultipleChannelSensor, respectively. The
graph component of the single stream of data is depicted in
Figure 2. As can be seen from Figure 2, we employ
BANMAC component as part of the program. This
component is particularly responsible for the communication
protocol between sensor nodes and sensor gateway. The
protocol adopts a polling scheme, which follows a star
topology and a master-slave model. This ensures that each
sensor transmits the data reading at different times, and
hence avoids collision. The BANMAC differs from standard
polling in the sense that each transmission is preceded by a
very short carrier sense period. A routine check to the
channel in order to ensure it is free for transmission is
carried out each time a packet is to be sent out. Further
details of this BANMAC component can be found in [2].
Other components include LedsC to control the light on the
sensor, and a few Timers for data collection, sensor radio
on/off, and battery reading.
• User-defined Function and Parameter Setting
The user-defined function and parameter setting are
available to allow the application developer adjust the
attributes of the parameters and process the data according to
their requirements. Figure 3(a) indicates the parameter
configurations in the header file. As shown in Figure 3(a),
the appropriate ADC Channel (which the sensor is connected
to) has to be specified.
(a) Parameter configurations
(b) User defined function
Figure 3. Parameter configurations and User-defined function
As an example, for accelerometer, the type is set to ‘1’,
while ECG is ‘2’. The user-defined function as displayed in
Figure 3(b), is called onBoardProcessing and supposed
to be left empty by default. Developers can add in additional
code which will be executed each time new data is
successfully sampled. The Lower Middleware allows
developers to perform this function prior to data
transmission. The example shown in Figure 3(b) divides the
incoming data by 5 before they are transmitted out.
C. Upper Middleware
The Upper Middleware’s role is to communicate with the
Lower Middleware based on the given set of APIs. The
architecture of the Upper Middleware can be seen in Figure
4. We describe the call back function, reconfiguration and
resource management features in the following.
• Call back Function
This call back function is implemented in the Upper
Middleware, and is defined to serve the communication
aspect between Upper Middleware and higher-level
application.
Msp430
ADCxC
(Sensorx)
BANMessengerR
(receiver)
BANMessengerS
(messenger2)
Msp430
ADCvC
(Battery)
Read
BANReceive
SingleChannelSensorC
BANSend
Read
Boot
Split
Control Packet BANSend BANCtrl BANRadio
Leds
Ctrl
Timer
Timer
Timer
Timer
MainC BANMessengerS BANMAC BAN
(messenger1)
Radio
LedsC
TimerMilliC
DataCollection
Timer
TimerMilliC
OneShot
Timer
TimerMilliC
Toggle
Timer
TimerMilliC
Battery
Timer
Figure 2. Lower Middleware components
5505

Resource
Control
Command
Application Layer ( Mobile Health Application)
Notification
and
r esource
information
Mote properties
request and
information
Incoming data streams
with relevant mote ID and
sensor type
ResourceManager
SensorHub MoteProperties
Sensor Command
Check Sensor
Mote properties
Request
Response Interface
update and
information
Commands
Sensor_RespMsg
Incoming Data
Resource
Resource
Streams and
C heck Sensor Control
Information
set/update mote
Command Interface Command
Incoming Data
properties
Streams
Sensor_CmdMsg SensorGateway
DataManager MoteManager
Mote
updates
Decrypts the
Incoming Data
Message
Incoming and
Outgoing Data
Streams
Check Sensor Data
Interface
Sensor_DataMsg
COM port number of the attached base station node (see
Figure 7). The SensorHub object is the main link between
the application and the Upper Middleware. Each application
should only create a single instance of SensorHub. A call
to this function is necessary to begin receiving data from the
sensor nodes. Without a call to this function, no
data/responses from the sensor node network will be
received by the application.
SensorDecoder
Sensor
Nodes
Gateway Node
Encrypted Wireless Data Transmission
SingleChannelSensor
Multiple ChannelSensor
Figure 4. Upper Middleware architecture
This function replaces the threads in the socket
programming. In this case, the application developer needs
to define function delegates in which the Upper Middleware
will use to callback whenever new data/response arrives
from the sensor nodes. As such, it is not necessary to
maintain constant connection for checking purposes.
Figure 5. Defining function delegates
Upon defining function delegates shown in Figure 5, the
application developer subsequently is required to assign the
function delegates to local functions. The local function that
we use as an example is called
middlewareDataFunction for processes data and
middlewareResponseFunction for processes
responses (see Figure 6).
Figure 7. Initiate the Upper Middleware
• Reconfiguration
Reconfiguration feature enables applications to change the
property of the sensors on-the-fly, such as changing the
sampling rate of the sensor through the Upper Middleware.
Figure 8 shows the reconfiguration functions in the Upper
Middleware.
Figure 8. Sensor reconfiguration functions
• Resource Management
Resource management relates to the ability to control each
of the sensor nodes in the network. A set of resource control
APIs is provided by the Upper Middleware. Resource
control messages include sensor once-off and periodic sleep,
sensor’s battery level reading and notification as depicted in
Figure 9.
Figure 9. Sensor resource management functions
Figure 6. Assigning function delegates to local function
The Upper Middleware will ‘callback’ incoming
data/response to the application through these functions.
Input parameters must be adhered to for them to function
correctly. Define local data and response callback functions
with the input parameters.
The application developer may add the desired
implementation/processing code into the body of the
middlewareDataFunction. To initiate the upper
Middleware, the developer firstly needs to create a new
instance of SensorHub, passing as its input parameter the
III. MIDDLEWARE DEPLOYMENT
This section shows the deployment of the proposed
middleware by an application. Our sensor hardware is a set
of EHSII sensors, developed by the Embedded & Hybrid
Systems II program in A*STAR [3] which have similar
specifications as the Imperial College BSN motes [4].
Figure 10. Sensor devices and a PDA
5506

For this purpose, we utilize three accelerometers and one
ECG, and the Upper Middleware resides in the PDA (HTC
X7501 Advantage Ultra Mobile). Figure 10 shows the
image of the associated sensor nodes and the mobile device.
• Incorporating the Middleware into an Application
As stated earlier, the proposed middleware is developed
in C# in the form of dll functions. In this showcase, we have
developed a mobile health monitoring application that will
deploy the middleware and interact with the sensor devices
through the middleware. We are using Visual Studio 2008
development suite. There are two simple steps to add the
proposed middleware program into the application. The first
step that application developer needs to do is to add a
reference to the Middleware.dll in the project, by selecting
‘Reference’ in the Solution Explorer as illustrated in Figure
11(a). In this example, the Middleware dll is named
Middleware.v3. Following this, in the second step, the
developer will have to import the Middleware.v3 into
the source code ‘using Middleware.v3’ statement at the
header of the code (see Figure 11(b)). Subsequently, the
application developer may commence deploying the
middleware functions based on the procedures that have
been described earlier in section IIC.
• Parameter Setting Interface
As part of the sensor reconfiguration and management
features, the application should be built with an interface to
utilize these features as what displayed in Figure 12(d). Each
of these control command calls the relevant function given
by the Upper Middleware. Figure 12(d) shows the radio
toggle command has been triggered for sensor mote 4 and
the sensor sends an acknowledgement back to the
application.
(a) Sensor indicators
(b) Accelerometers waveform
(a) Reference the Middleware
(b) Import the Middleware
Figure 11. Incorporating Middleware dll
• Data Acquisition
After incorporating the middleware into the application
and activating the data acquisition functions, the application
should start receiving data streams from each of the sensor
node. As shown in Figure 12(a), the light indicator in the
application turns into green, which means that the
application is receiving sensor data. The four lights indicates
mote 1 to 4. Mote 1 to 3 corresponds to the three
accelerometer sensors, while mote 4 relates to the ECG
sensor. Figure 12(b) and (c) depicts the accelerometer and
ECG waveforms, respectively after receiving the data from
the sensor nodes.
(c) ECG waveform (d) Sensor control interface
Figure 12. Sensor data acquisition and presentation
• Performance Comparison
Compared to our previous WBAN middleware in [1], the
Middleware reported in this paper offers much smaller size
and better performance. The size of the previous Upper
Middleware (106 bytes) is about two times larger than the
current version (41 bytes) in this paper. In terms of the
efficiency (loading time), the current middleware (~1.5 sec.)
is about 5 to 6 times faster as compared to its predecessor
(~10 sec.). These two are arguably the most significant
elements when working in resource-constrained
environments.
IV. CONCLUSION
We have presented an efficient, flexible and lightweight
mobile middleware for wireless body area network. The
middleware architecture, its functions/processes, and the
deployment of the middleware including performance
comparison of the middleware have been discussed.
REFERENCES
[1]. A.B.Waluyo, I. Pek, X. Chen and W-S. Yeoh, “SLIM: A Secured
Lightweight Interactive Middleware for Wireless Body Area
Network” In Proc. of the 30th International Conference of the IEEE
Engineering in Medicine and Biology Society, pp. 1821–1824, 2008.
[2]. Bd. Silva, A. Natarajan, M. Motani, and K-C. Chua, “Design
Considerations of Body Sensor Networks”, In Proc. of the IEEE
Healthcom, pp.323-328, 2008.
[3]. A*STAR,”EHSII: Embedded & Hybrid Systems II”, http://www.ehssg.org/.
Referenced: April, 2009.
[4]. B. Lo, S. Thiemjarus, R. King, and G-Z. Yang, “Body Sensor
Network – A Wireless Sensor Platform for Pervasive Healthcare
Monitoring”, In Proc. of the 3rd International Conference on
Pervasive Computing, pp.77-80, 2005.
5507