Embed Size (px)
Citation preview
MBStar : A Real-time Communication Protocol for Wireless Body AreaNetworks
Xiuming Zhu, Song Han, Pei-Chi Huang, Aloysius K. MokUniv. of Texas at Austin
xmzhu, shan, peggy, [email protected]
Deji ChenEmerson Process Management
Abstract—In this paper, we report on the design and im-plementation of MBStar, a higher-frequency, real-time, reliable,secure protocol for wireless body area networks(WBAN). As inmost proposals for body sensor networks, MBStar adopts thestar topology for communication, and is designed to support amessage rate as high as 400 Hz, which to the best of our knowl-edge, is the highest among low-power wireless communicationprotocols implemented at the present time. The physical layerof MBStar utilizes 802.15.4 DSSS compatible radio for whicha higher-frequency, reliable, TDMA MAC layer is built. Thereis a simple application layer designed for security on top of it.MBStar utilizes public/private key encryption for provisioningdevices and does not involve any human configuration beforedevice join. Considering the resource limit of most embeddedsystems, the TDMA requirement of computing a shared globalcommunication schedule presents a practical problem since itmay not be feasible for all the devices to communicate in along hyper-period while the communication schedule betweendevices is being created or modified as devices depart and rejoin.We solve this problem by keeping only the global hyper-periodschedule on the gateway side, with each device being configuredwith a shorter, local period. Then, retransmission is employedto resolve any conflicts between the devices. Our strategy hasthe property that, given any fixed task set, the minimal averagenumber of retransmissions is independent of any communicationscheduling algorithm, and the EDF (Earliest Deadline First) isoptimal for our communication architecture. Finally, we presentexperimental results that demonstrate that MBStar is an effectiveprotocol for wireless body area networks.
Keywords-Wireless body area networks; High frequency; Re-liable and real-time communication;
I. INTRODUCTION
The application of wireless technology to health care hasbeen recognized to be an important research topic [1]. Typ-ically for such applications, sensors or actuators are attachedto the human body and a powerful server that serves as thecentral data processor and the data sink. Together they form awireless communication network, commonly called a WirelessBody Area Network (WBAN), as proposed in 2001 [2].
A key problem in WBAN is how to connect heterogeneousbody sensors and assistive actuators securely, reliably andto meet real-time performance requirements. Typically, bodysensors have to send out health data periodically and theirtransmission frequencies range from several Hz to several hun-dred Hz. There is also an increasing need for real-time controlfor assistive actuators. For wireless communication, there areseveral well-developed standards such as Wi-Fi, Bluetooth,ZigBee and WirelessHART. However, these standards fallshort in some aspects to serve the needs of WBAN for medical
applications. For example, both Wi-Fi and Bluetooth cannotprovide timing guarantees on packet delivery. While beacon-Enabled ZigBee and WirelessHART can provide real-timecommunication, they are too slow for such applications. Themaximum transmission frequency of WirelessHART is 100 Hzand ZigBee is even slower.
In this paper, we propose MBStar, a new protocol forWBAN. The main notable features of MBStar are listed asfollows.
• Higher Frequency. MAC timeslot of MBStar is 2.5 mil-liseconds and the data rate can be as high as 400 Hz.
• Real-time. MBStar MAC layer adopts TDMA (Time Di-vision Multiple Access) to ensure accurate timing controlfor packet delivery.
• Reliable. MBStar utilizes channel hopping and channelblacklist to minimize noise interference. It also supportsacknowledged transmission and retransmission to providelink reliability.
• Secure. MBStar employs both public/private key mecha-nisms for provisioning devices before join and uses AES(Advanced Encryption Standard) for encrypting healthdata after join.
• Star Topology. Since body area networks cover a smallarea, the star topology is quite sufficient. In a MBStarnetwork, we shall assume that a gateway is connectedwith access point(s) and a number of sensors/actuatorsare connected to the access point wirelessly.
A major contribution of our paper is to provide a practicalsolution to implementation problems by appropriate designchoices. In our application model, sensor processes send dataperiodically, and a sensor may depart and rejoin a networkat any time. We use the offset-free scheduling model [3]where the processes are executed periodically in accordancewith a schedule whose length covers the hyper-period of theprocesses. Because of resource limits, it may not be feasiblefor a sensor node to keep a long global schedule covering thehyper-period. In our solution, a newly joined sensor processis configured with the parameters of local period Tnew andan offset Onew. After configuration, the sensor sends data inthe Onew + k ∗ Tnew, k = 0, 1, 2 . . . time slots. This strategymay incur ’collisions’ between the sensor data transmissionsat the access point 1 since the access point can send/receiveon only one channel at a time. Physically, there is actually no
1In this paper, we assume that there is only one access point connected tothe gateway; extension to the multiple access point case is possible
collision since senders transmit on different channels by usingfrequency hopping in our scheme, and ’collision’ is detectedby the transmitter if there is no acknowledgement from theintended receiver. In case of collision, a sender retransmitsthe data until either it gets an ACK or data expiration.
We shall define a MBStar offset-free scheduling problem interms of the determination for each process an optimal pair ofvalues for (Tnew,Onew); an optimal schedule must guaranteeboth the highest utilization ratio of the receiver’s channeland the lowest average number of retransmissions. We tacklethis problem in four steps. First, we prove the the optimalityof the EDF scheduler in generating the global schedule forthe MBStar offset-free scheduling problem when the periodparameters have been fixed. Second, EDF utilization upperbound is used to choose the optimal value for Tnew. Third,optimal value for Onew is determined by searching within asmall range. Finally, EDF is used to generate the schedule.
The remainder of the paper is structured as follows: Sec-tion II introduces background and the related work. Sec-tion III describes MBStar in Detail, followed by an prototypeimplementation in Section IV. Section V will present theexperimental data and Section VI the conclusion.
II. BACKGROUND AND RELATED WORK
A. Wireless Body Area Network
According to [1] [3], WBAN usually consists of at leastone powerful data center server, a number of sensor nodesfor sensing and actuator nodes for control actions. It canbe easily confused with Wireless Sensor Actuator Networks(WSAN). Compare to WSAN, the specific requirements ofWBAN which can be listed as follows:
1) Reliability. Data sent by WBAN sensors are heath in-formation for which high reliability is required. WBANreliability should be certifiable.
2) Latency. Health data, especially emergency data, cannottolerate long response time. Real-time transmission withperformance guarantee is required, especially in the caseof control actions where low latency is often required forsystem stability.
3) Security. privacy as well as freedom from tempering isimportant in WBAN.
4) Power consumption. Compared to WSAN, battery re-placement in WBAN is easier and so there is less focuson power consumption.
Table I lists some body sensor bandwidth requirements [1][4]. From the table, we can see the sizes of medical datapackets are usually small while the bandwidth range can varyquite widely.
B. Related Wireless Protocols
As mentioned above, current commercial wireless protocols(Wi-Fi, Bluetooth, Zigbee and WirelessHART) cannot beapplied to WBAN directly. Table II summarizes the featuresof these protocols. Except for voice packets, Bluetooth cannotguarantee real-time delivery. For WirelessHART, the data rateis at most 100 Hz and the message header of WirelessHART isunnecessarily long for health data, which is not power efficient.
TABLE I: Bandwidth and data size requirements on typical biomedicalmeasurements
Biomedical measurements Bandwidth Data sizeEMG 100-200 Hz 16 bitsECG 100-250 Hz 12 bitsBlood Pressure 50-100 Hz 16 bitsRespiration 50 Hz 16 bitsHeart Rate 25 Hz 24 bitsMotion Pressure 100-200 Hz 12 bits
TABLE II: Features of present Wireless Communication Protocols
Protocol Lowpower
Real-timeDelivery
ChannelHopping
Highfrequency(>100Hz)
WiFi No No No PossibleBluetooth Yes Yes Yes NoZigbee Yes Yes No YesWirelessHART Yes Yes Yes No
Besides above protocols, there are several related workssuch as BSN-MAC [5], H-MAC [6], Lamprinos [7],Omeni [8]. All these protocols try to improve energy effi-ciency. BSN-MAC uses an adaptive MAC protocol. It utilizes802.15.4 beacon-mode and it adjusts the interval of contention-free and contention-based period based on sensors feedback. Inthis way, it gains better energy efficiency. H-MAC proposesan interesting way to synchronize the human body sensorsby making use of the human heartbeat rhythm as an externalclock, thus saving the energy of broadcasting time messages.Lamprinos [7] proposes a token-based mechanism to synchro-nize transmission between the data sink and sensors. Only thesensor that obtains the token is allowed to send data and itmust release the token after finishing transmission. Throughthis lock-share method, it removes the collisions betweenslaves. Omeni [8] employs listen-before-transmit (LBT) toavoid collision with nearby senders and proposes a dynamictime slot allocation for lower frequency, fluctuating traffic.
Since the sensors are deployed only on the human body,the mesh topology is not necessary for such a small area andthere is no need to use any routing mechanism. Till today, thestar topology is the major established for all WBANs.
III. MBSTAR IN DETAIL
In this section, we describe the MBStar protocol in detail.MBStar adopts several important features from current wire-less protocols, like channel hopping and channel blacklist tocreate a suitable solution for WBAN.
A. MBStar Protocol Architecture and topology
Fig. 1 shows the architecture of MBStar protocol. Thephysical layer utilizes the 802.15.4 radio for low powerconsumption, for which a higher frequency, reliable, TDMAMAC layer is built. The MAC layer adopts channel hoppingand channel blacklist to minimize the effect of noise on anyparticular channel and retransmission is also used to attainhigh reliability. The MAC time slot length is 2.5 millisecondssupports a higher bandwidth than current low-power wireless
Fig. 1: Architecture of MBStar Protocol
TABLE III: 802.15.4 Radio Timing Profiles
Symbol Description Value (µs)TsTxWarmup Tx Warm-up 96TsTxCooldown Tx Cool-down 12TsTxRx Turnaround between Tx and Rx 192TsTxUnit Tx one byte 32TsTxPhyHeader Tx physical header (6 bytes) 192
protocols. On top of all, there is a simple, secure applica-tion layer, and MBStar can support 128-bit AES (AdvancedEncryption Standard) encryption/decryption. The applicationlayer will sample health data from the sensors and then encryptthe data and pass it down to the MAC layer.
The main reason why we do not put security in MAC layeris for efficiency. Usually, encryption/decryption involves highcomputational cost and the MAC time slot may be too shortto complete all the tasks. We shift security into the applicationlayer because the timing requirement is not as harsh.
The MBStar network has a star topology that connects anumber of devices to an access point that is in turn connectedto the gateway. The MBStar protocol stack is executed byall the nodes in a network. Nodes that are sensors/actuatorscollect data and transmit them via an access point to the centraldata server for processing and the actuator commands are sentdownlink for control actions.
B. MBStar MAC Layer
The MAC layer is the key part of MBStar. In this section, wewill describe the definition of MAC time slot and the formatof packet.
1) MAC Time Slot Definition: Table III shows the 802.15.4timing profiles. The basic time slot is 2.5 milliseconds. The802.15.4 physical layer header is 6 bytes. Hence, there is notmuch space in one packet to hold many bytes. In MBStar, themaximum DLPDU (or MAC Layer Protocol Data Unit) packetsize is 24 bytes, which is quite enough for medical data andthere is a smaller MAC ACK packet, which is 9 bytes.
Fig. 2 and Table IV show the timing definition for transmit-ting slot and receiving slot. A noteworthy value is TsRxWaitand TsRxAckWait. Both are 434 µs, which is designed forreceiving all the physical header bytes. If there is no physicalheader of a packet arriving after this period, the receiver shouldclose its antenna for saving power.
2) Time Synchronization: Since MBStar adopts a very time-stringent slot size, the time synchronization requirement ismore demanding than other low-power networks. Since twodevices may drift in different directions, the receiver mayopen its antenna either too early or too late. In MBStar, the
TABLE IV: MBStar Timing Profiles
Symbol Description Value (µs)TsTxOffset Tx preparation time 100TsTxMaxPacket Time to Tx the max packet (24
Bytes)972
TsRxAckDelay Time between finishing Tx andwaiting for the ACK
150
TsRxAckWait Wait time for the start of ACK 434TsRxOffset Rx preparation Time 50TsRxWait Wait time for the start of message 434TsTxAckDelay Time between the end of message
and start of sending ACK200
TsTxAck Tx time for ACK 492
Fig. 2: MAC Slot Timing
receiver should open the antenna 50 µs before the sender startstransmitting. Hence, the maximum permitted time differenceis 50 µs. For devices with 10 ppm clock accuracy, we haveto synchronize them at least every 50/(10 * 2) = 2.5 s. SinceMBStar is a star topology, it is enough for the access point tosend out a broadcast packet every 2.5 seconds.
3) MAC Data Format: Table V shows the DLPDU datapacket format. MBStar endeavors to find a good balancebetween reliability, security and packet size. For one packet,there is a 9-byte overhead. A packet begins with 2-byte tagin order to distinguish itself from other 802.15.4 compatibleprotocol packets. The time slot number snippet gives the leastsignificant byte of the time slot number which denotes theoffset (measured in the number of time slots) from time zero,i.e., the time point at which the access point joins the network.The MIC is used for DLPDUs authentication and generatedsecurely according to the present absolute slot number anddestination address. Only two devices sharing the same keycan authenticate it. Finally, there is a 2-byte CRC at the tailof the packet.
4) Channel Hopping and Channel Blacklist: MBStaradopts channel hopping and channel blacklist to minimizethe effect of noise on any specific channel by using hoppingfrom channel to channel. Each device is configured with aunique channel offset. The current channel for a device canbe computed as follow.
Channel = (Timeslot Snippet + Channel Offset) %Number of Channels
Periodically, the access point updates the transmission fail-ure number of each channel and broadcasts the present channelsituation. In this way, each device in the network knows howto avoid using blacklisted channels before the next update.
TABLE V: DLPDU format
Byte Number DescriptionByte 0-1 MBStar Packet TagByte 2 Bit 0-3 is for packet specifier and bit 4-7 is
network IDByte 3 Bit 0-3 is destination address and bit 4-7 is
source addressByte 4 Time slot number snippet (the least signifi-
cant byte value)Byte 5-n Payload (maximum 15 bytes)Byte n+1-n+2 MIC (message integrity code)Byte n+3-n+4 CRC
C. Application Layer
The application layer is relatively simple. It is mainlyresponsible for encrypting sensor data and decrypting configu-ration commands from the access point. The maximum APDUpayload is 14 bytes, which is enough for medical application.
D. Security
Basically, secure communication in wireless networks in-volves two steps:
1) How to authenticate the new device during joiningprocess?
2) How to make sure the secure communication after join?With respect to the former, all current wireless protocols
involve manual pre-configuration. Wi-Fi and Bluetooth ask forpassword input. ZigBee and WirelessHART require the user tostore the unique device ID beforehand. A manual configurationinterface (keyboard, screen, FSK port and so on) is needed forauthentication.
In MBStar, we utilize the Internet Key Exchange protocol(IKE) [9] to authenticate and provision a device over theair. IKE consists of two phases. In phase I, we use theDiffie-Hellman key exchange mechanism to establish a secureauthenticated communication channel between peers. Based onthe secure channel, the peers negotiate Security Associations(SAs) for further services. In MBStar, we adopt a Self-Certified ECC-based Diffie-Hellman(ECDH) key exchangeprotocol [10] in phase I. In phase II, a certificate is generatedin the gateway and will be configured into the new device.
One major concern of using ECDH on embedded systemsis the time overhead. ECDH is not a good option for time-stringent applications. However, since there is usually noexplicit time requirement for the join process, this is not aproblem.
The latter is much easier to handle. As soon as a deviceis authenticated, a fresh communication key will be imme-diately provisioned with the shared key generated by ECDH.Thereafter, communication will be protected by symmetric en-cryption/decryption algorithms, such as AES or DES. MBStarcan support up to 128-bit encryption, which is deemed to begood enough at the current time.
E. Join Sequence
Based on the above description, the sequence of a devicejoin is as follows:
1) The gateway first configures the access point and thenthe access point starts to broadcast periodically.
2) For a device, it synchronizes itself when it receivesbroadcast packets and then starts to send request forauthentication based on Internet Key Exchange protocol(IKE).
3) After finishing IKE phase II, a shared key is establishedbetween the gateway and the device. Then, the gatewayconfigures a new key and the network ID into device. Atthis point, secure communication channel is established.
4) Next, the device will send out a bandwidth request andwait for the response from the gateway. If the requestis authorized, the device will send out data periodicallysubject to the bandwidth agreement.
5) A device may drop out of the network for losingsynchronization at any time. However, it can always startrejoin.
IV. IMPLEMENTATION
In this section, we will describe our implementation. Weshall first introduce our hardware platform, and then oursoftware architecture. Then, we shall discuss some algorithmicissues concerning link scheduling.
A. Hardware Platform
Our implementation is built on Freescale MC1322x serieswhich have the following core features:
• 24 MHz 32-bit ARM 7 core based MCU• 96K bytes RAM• 802.15.4 compatible radio• Four independent 16-bit hardware timers• Hardware acceleration for AES securityFreescale provides both a simple 802.15.4 physical layer
library and a security library. These libraries enable us tooperate the antenna directly and develop the security moduleeasily in MBStar.
B. Software Architecture
Fig. 3 shows the software architecture of our implementa-tion. The main modules can be described as follows:
• Message Handling Module: Message Handling moduleis responsible for sending and receiving packets, usuallyone for receiving and another for sending. For a non-timing-critical interface (sensor to APP,e.g), there is apacket queue associated with it and the message handlingmodule will use events to notify the corresponding layerafter putting the packet in the queue. For timing-criticaltasks, message handling will directly use interrupts tohandle the message. There is no queue between the MAClayer and the physical layer. The transmitting buffer andreceiving buffer are shared by both layers. This simpledesign removes the queuing delay and ensures the quickhandling of messages.
• Timer Module : There are four 16-bit hardware timers onMC1322x and we use only one of them. For each timer,there is a free running register storing the current ticknumber and a comparison register for input. Whenever
the values of the two registers are the same, a timerinterrupt event will occur.Timer interrupts have the highest priority and are usedfor processing only time critical and light-weight jobs.Computational intensive job, like encryption/decryption,may take too long and thus are not performed by thetimer interrupt handler.Another function of the timer module is synchronizationwith the access point. In MBStar, the synchronizationoperation is carried out when a packet, mostly, adver-tisement, from the access point arrives. The arrival timeof the first bit is recorded and is compared to the designedpacket sending time as follows.
time diff = arrival time -slot star time-TsTxOffset
As mentioned above, a device will redo the synchroniza-tion at least every 2.5 seconds to maintain synchroniza-tion.
• Scheduler : The scheduler module in the MAC layer isused to determine the type (transmitting, Receiving, oridle) of next time slot according to configuration storedin MAC PIB. In our implementation, it is called at theend of each time slot because a device has to get all theinformation to determine the type of next slot (retry, e.g).
• Security Module : The security module is put in theapplication layer because of its high time cost. This deci-sion is acceptable in MBStar. Measurements show that ittakes less than 0.5 milliseconds for encrypting/decrypting24 bytes on MC1322x with built-in AES module. Forsecure provisioning, [11] lists the time and memorycost on MC1322x: the total memory footprint of ECDHimplementation is around 12 KB and it takes less than10 seconds to complete all the authentication steps.Pre-computation is also employed in our implementation.For example, the encryption of sensor data can be donebeforehand. Also, packet MIC generation can also be pre-computed both for sender and receiver because MIC isnot related to the content of a packet.
• MAC Time Slot State Machine : Fig. 4 shows thetransition of MAC time slot states for transmitting slotand receiving slot. The transition is driven either by timerinterrupt or by message coming interrupt. As shown in thefigure, all the operations are light-weighted to guaranteetiming requirements.
• APDU processor : The functionality of APDU (Appli-cation Protocol Data Unit) processor is simple. It is usedto parse configuration messages from the gateway andencapsulate sensor data into APDU which is then sentdown to MAC layer.
C. Link Scheduling
This section introduces the link scheduling problem inMBStar. We first describe a typical scenario and define theassociated MBStar offset-free scheduling problem. We thendiscuss our solution approach.
1) MBStar Offset-free Scheduling Problem: For economyof space, we only consider uplink scheduling in this paper,
Fig. 3: Software Architecture
Fig. 4: MAC Time Slot State
which means that the access point only receives data fromsensors. Our discussion can be readily extended to the down-link case. The scenario can be described as follows:
• For the access point, it can only communicate with onedevice in each time slot.
• For a wireless body sensor, it may have a desired datatransmission rate (maximum rate) and also a tolerable rate(minimum rate). In other words, the bandwidth request isa range. (See Table I)
• The protocol is based on TDMA and channel hopping.So, devices are sending on different channels in thesame time slot. There is no physical collision but logical
0 1 2 3 4 5 60
1
2
time slot
devi
ces
Fig. 5: An Example for Schedule in Gateway
transmission collision may occur at the target (accesspoint).
• To ensure data reception, the sender will retransmit thesame data packet if it does not receive the correct ACK.However, if a new sample arrives (sampling rate is thesame as transmission rate), the sender will have to discardthe old packet in order to send the latest data.
• Devices may join and leave at arbitrary times.• The gateway tries to satisfy the maximum bandwidth
requirement of a device. If it does not have enoughbandwidth to meet the lowest data rate requirement, thedevice will not be permitted to join the network.
To solve the problem, we adopt a simple way to configurethe device. For each bandwidth request, the gateway willrespond with two values: the designated beginning time slotnumber and the permitted rate. If the permitted rate is not zero,the device can start sending the data at the designed time slotnumber at the (fixed) permitted rate ad infinitum. Otherwise,the bandwidth is insufficient and the device is not permitted tosend any data. The gateway has all the information requiredto generate a suitable schedule to guarantee every packet bereceived before expiration if there is no other interference.Note that the devices do not have knowledge of the globalschedule that spans a hyper-period. Each device only keepsits own period. Fig. 5 shows an example of the schedule.The X-axis denotes time slot number and Y-axis denotessensor number. A stripped block denotes a transmission failurebecause of ’collision’ while a clear one means a success (samefor later figures). In this figure, there are two sensors. Sensor0 is sending a packet every 2 slots while sensor 1 is sendingevery 3 slots. Both begin at time 0. And at time 0, access pointis scheduled to pick up the packet sent by sensor 0 and sendan ACK back. At time 1, access point is scheduled to talk tosensor 1 since it knows sensor 1 will retry.
There are several reasons why we do not share the globalschedule that spans the hyper-period. First, since the samplingrates of medical devices are not harmonics in general, thelength of the hyper-period may be very long. We cannotin practice expect every device to have enough memory orcomputing capability to keep in step with the global scheduler.Also, the configuration packet size is likely to be not longenough and thus, the configuration loop will be very longeven if a device has enough space. Second, since devices mayjoin and leave arbitrarily, each join and departure will involvean update of the hyper-period schedule to the entire network,which is not very scalable.
As we can see from Fig. 5, the first packet sent by sensor 1is of no use, which results in power waste. However, as statedin the related work section, recharging body medical devices is
much easier than that in normal wireless sensor networks, andpower consumption is not considered as the key issue here.
We adopt the offset-free real-time scheduling model [3] totackle our problem. In offset-free systems, the offset of tasks isassigned by the scheduler. In MBStar, we aim to find both anoptimal offset and period for a new device. Thus, the MBStaroffset-free scheduling problem is defined as follows:
Consider that n senders s1, . . . , sn already joined the net-work, and there is a new sensor snew that needs to beaccommodated.
• Each joined sensor si is characterized by a pair (Ti, Oi)with period Ti ∈ N and offset Oi ≥ 0. The release timeof kth (k = 1, 2, . . .) packet of si is Oi + (k − 1) ∗Ti. And, sender si keeps transmitting the packet untileither it receives an ACK from the receiver or the nextpacket from the sensor is released. The kth packet mustbe received before Oi + k ∗ Tith slot.
• The new sensor is characterized by a pair(minTnew,maxTnew) with desired period to beminTnew but no bigger than the tolerable periodmaxTnew.
• The average global retransmission numberretran number is defined as the number ofretransmissions divided by the number of successfultransmissions in the global hyper-period schedule,assuming packet loss is due to logical conflict only.
• The global utilization ratio U is the sum of 1/Ti for alljoined si.
• The new task set is a set of pairs {(T1, O1), ...,(Tn, On)},which n ∈ N that contains the period andoffset assignment to the new sensor task.
The objective is to find a pair (Tnew, Onew) for the newsensor, where Tnew ∈ [minTnew,maxTnew] and Onew ∈ N ,and to generate a schedule in the gateway for the new task set.A schedule is optimal if it meets the following constraints:
1) It has the highest global utilization ratio.2) Subject to the highest utilization ratio that can be
achieved for the task set, the schedule should attain thesmallest average retransmission number.
Next, we shall discuss our solution approach for this prob-lem. First, the optimality of the EDF policy is proved giventhat the task period and offset parameters are fixed. Then, howto choose optimal values for (Tnew, Onew) will be proposed.
2) Optimality of EDF: The optimality of the EDF (earliestdeadline first) preemptive scheduling algorithm for tasks witharbitrary release times and deadlines has been proved byDertouzos [12]. Liu and Layland [13] and Spuri [14] provedthat as long as the global utilization ratio is no bigger than1, EDF can be applied successfully, even if the tasks areasynchronous. This also applies to the discrete time modelwhere the granularity of time measurements is in terms ofintegral multiples of some basic time quantum [15]. In thismodel, time intervals are always measured between integraltime points and given in integral time units (time slots). Sinceour protocol is based on TDMA, one transmission only takesexactly one time slot regardless of the data size and both taskperiods and execution times are all measured in time slots.
Notice that here, any time interval cannot span window thatstarts in the middle of a time slot and ends in the middle ofanother one. Let a time slot be a scheduling time unit, then alltask periods and execution times are integers. Furthermore, allexecution times are of one time unit. Thus, it is not hard to seethat EDF meets the first constraint. We shall prove EDF retainsits optimality with the second constraint. Before proving this,two lemmas should be listed first.Lemma IV.1: (Generalized Chinese Remainder Theorem) [16]Let T1, T2, . . . , Tn be positive integers. Let P be the leastcommon multiple of T1, T2, . . . , Tn and let a,O1, . . . , On beany integers. There exists one integer t which satisfies theconditions
a ≤ t < a+ P, t ≡ Oi(mod Ti), 1 ≤ i ≤ n (1)
provided that
Oi ≡ Oj(mod(gcd(Ti, Tj))), 1 ≤ i < j ≤ n (2)
and there is no such integer t when the later condition fails.Lemma IV.1 says that if equation (2) is satisfied, sensor
si, sj will always collide with each other periodically. In otherwords, there exists a minimum non-zero number of collisionsbetween devices if equation (2) is satisfied. We now showLemma IV.3.Lemma IV.2: If n devices collide at the same time, at leastn ∗ (n− 1)/2 retransmissions will be generated.Proof: Suppose n devices collide at time slot t, since theaccess point can only receive one packet at one time slot, itneeds at least n time slots to receive n packets. Then, at timeslot t + 1, at least n − 1 devices will resend. Hence, at timeslot t + i, i ∈ [1, n − 1], at least n − i retransmissions willcome out. Hence, totally, 1+2+ . . .+(n−1) = n∗ (n−1)/2retries will be generated. 2Lemma IV.3: For any given fixed task set, the smallestglobal average retransmission number is independent of thescheduling algorithm that does not idle tasks unnecessarily.Proof: Based on Lemma IV.1 and Lemma IV.2, we can get thatthe smallest average retransmission number is only related toperiods and offsets. Thus, no scheduling algorithm can affectthis value. For a scheduler, as long as it schedules a successfulreceiving when there is at least one device sending its packet,it will have the smallest value. 2
To illustrate this result, let us take the following three tasks.Suppose the pair set is (5,O1),(3,O2) and (4,O3), since 3,4,5 ispairwise co-prime between each other, equation (2) is satisfiedfor all offsets. Every 15 slots, period 3 and 5 ’collide’ and atleast one should retry. Every 12 slots, period 3 and 4 ’collide’and at least one should retry. Also, every 20 slots, period 4and 5 ’collide’ and at least one should retry. Finally, every 60slots, all three ’collide’ and at least three retrial packets willbe sent.Theorem IV.1: Given a fixed offset-free task set, EDF isoptimal for generating the schedule for the MBStar offset-freescheduling problem.
0 5 10 15 200
1
2
3
time slot
devi
ces
(a) EDF Schedule
0 5 10 15 200
1
2
3
time slot
devi
ces
(b) RM Schedule
Fig. 6: Example for same average retransmission number
Proof: EDF satisfies the first requirement for optimality ac-cording to Dertouzos [12]. For the second requirement, wenote that the receiver does not idle unnecessarily becauseone packet among all the packet in a logical collision isalways picked up by the access point. So the EDF schedulerachieves the highest utilization and also does not cause anyextra retransmission.
Fig. 6 shows an example. The task set is {(5,0),(4,0),(2,1)}.The left schedule is generated by EDF while the one on theright is generated by the RM (Rate Monotonic) scheduler.From the figure, the average retransmission number of bothschedules which is also the smallest value, is the same. Aslong as the ’collided’ slot is not idle, the retransmission ratiois the smallest.
3) Solution for MBStar Offset-free Scheduling Problem:The above section shows that it is straightforward to choose theoptimal value for Tnew as long as the global utilization ratiois smaller than 1. However, finding an optimal value for Onew
is more difficult and the choice of Onew might greatly affectthe average retransmission number. Fig. 7 shows an example.For case A the task set is {(2,0),(3,0),(6,5)} and for case Bit is {(2,0),(3,0),(6,0)}. Both schedules are generated by EDFand it is obvious that the average retransmission number ofcase A will be much lower than that of case B.
0 1 2 3 4 5 60
1
2
3
time slot
devi
ces
(a) Case A
0 1 2 3 4 5 60
1
2
3
time slot
devi
ces
(b) Case B
Fig. 7: Example for Different Offset Assignments
Unfortunately, we do not have an analytical expression tocompute the optimal Onew. For practical purpose, however, we
0 5 10 150
0.5
1
1.5
2
2.5
3
3.5
4
number of tasks
Ret
rans
mis
sion
rat
io
Optimal Assignment
Random Assignment
All Zero
Fig. 8: Average Retransmission Numbers for Different Offset AssignmentPolicies
can search through all the possibilities provided that the searchrange is small. In particular, note that the search range is nolarger than Tnew, and paper [3] further proves that there areat most gcd{Tnew,lcm{T1, . . . , Tn}} choices for Onew andthe range is [0,gcd{Tnew,lcm{T1, . . . , Tn}}), where gcd andlcm denote the greatest common divisor and the least commonmultiple respectively. In practice, since the hyper-period lengthis already known, the time complexity of searching Onew isO(Tnew). We note that the searching space will be much largerif we had tried to solve the global scheduling problem thatdoes not allow retransmission such that the offsets have to befound for every task to avoid any collision.
Algorithm 1 summarizes the solution. It should be notedthat, in line 23, we only compare the average retransmissionnumber in the time window [r+P, r + 2 * P-1]. This is because,according to paper [17], from time r+P the schedule in interval[r + P, r+2*P-1] will be repeated infinitely in the infinitehorizon schedule.
We have done a simulation to find out how much gainwe can get from the optimal offset assignment. The resultsare shown in Fig. 8. In the simulation we generate severalgroups of sensors with periods randomly chosen between2 and 40. The group size is between 2 and 15. For eachgroup, we tried three types of offset assignment policiesand measure the average retransmission number. The policiesare: all zeros, random assignments and optimal values. Eachtest is repeated 5 times and the average is taken. In Fig. 8the X-axis is the group size and the Y-axis is the averageof the average retransmission number. From the figure, wecan see that the optimal assignment is the best. Its averageretransmission number is always below 0.5 and about halfof that of the random assignment. Both are better than thezero assignment, whose average retransmission number canbe as high as above 3.5. Bigger retransmission number leadsto bigger power consumption.
It should be emphasized that when there is a physical packetloss, a device will retry. For the access point, it can easilyreschedule another ’pickup’ before packet expiration. Fig. 9gives a illustration. The task set is {(5, 0), (2, 0)}. At slot 5(the block with a cross), the packet is supposed to be receivedsuccessfully by access point but lost because of interference.However, the access point soon finds out that it should receive
Fig. 9: Example for reschedule
a packet from device 0 and knows it will retry. Hence, it will’wait’ at slot 8 and get the packet before its expiration. Noticethat, since the access point knows all the offsets and periods,it only needs to search a short range (at most the period ofthe faulty device) to produce such a schedule. However, if theschedule is pretty full, it may not be able to find an emptyslot and the packet will be lost forever.
Algorithm 1 Solution for MBStar offset-free problem
1: // Input: Bandwidth request (minTnew,maxTnew)2: // Output: Pair (Tnew, Onew) and an optimal schedule S3: // U Ratio is the present utilization ratio4: // H Len is the present length of hyper-period5: // V is the present scheduled tasks set6:7: //Step 1: Find optimal value for Tnew
8: if U Ratio+ 1/maxTnew ≤ 1 then9: Find the smallest value T ′ in [minTnew,maxTnew]
which 1/T ′ + U Ratio < 1. Then, Tnew = T ′
10: else11: return FAILURE; // No enough bandwidth12: end if13:14: //Step 2: Find Optimal value for Onew
15: Offset Range=gcd(Tnew, H Len)16: least Retran Ratio = Max Period(V ∪ (Tnew, O
′))17: optimal Offset = 018: for all Each O′ between [0,Offset Range− 1] do19: V ′ = V ∪ (Tnew, O
′)20: r = Max Offset(V ′)21: // new hyper-period length22: P = gcd(H Len, T new)23: // Generate EDF schedule in [r + P, r + 2 * P]24: S ′ = Get EDF Schedule(0, r + 2 ∗ P )25: retran Ratio = Get ReTran Ratio(S ′,V ′)26: if least Retran Ratio > retran Ratio then27: least Ratran Ratio = retran Ratio28: optimal Offset = O′
29: S = S ′
30: end if31: end for
V. EXPERIMENTS
In this section, we present our experiment results based onthe prototype implementation which is described in Section IV,and setup a star network with one access point and threedevices as shown in Fig. 10. The access point is connected to
Fig. 10: Experiment testbed: One Access Point and three devices are organizedin a star network
TABLE VI: Device configuration and experiment settings
Dev ID Description DataFrequency
Period Offset Join Se-quence
dev 1 accesspoint
NA 40 NA 0
dev 2 sensor 80 Hz 5 0 1dev 3 sensor 50 Hz 8 0 2dev 4 sensor 200 Hz 2 1 3
a computer through the serial port, and the baud rate is set to230400 bps. A serial port communication software is runningon the computer to collect all the packets exchanged betweenthe computer and the access port. The frequencies of the threedevices are 200Hz, 80Hz and 50Hz, respectively. Their joinsequence and offset assignments are summarized in Table VIand the communication schedule is shown in Fig. 11. Sameas in Fig. 9, a stripped block is used to denote a transmissionfailure because of collision.
Our experiments mainly focus on evaluating the loss ratio ofour MBStar system in different test scenarios. The results areshown in normal office environment, noisy environment andits co-existence performance when other wireless networks in2.4GHz frequency band are present, for instance, Bluetoothand Wi-Fi.
A. Experiments in Normal Office Environment
In this experiment, we put our testbed in a normal officeenvironment. There are several Wi-Fi networks around butwe disable the Wi-Fi interface on the laptop. Then, after theMBStar system keeps running in one hour, collects 1311599packets in total and misses 61 packets. The averaged loss ratio
0 5 10 15 20 25 30 35 400
1
2
3
time slot
devi
ces
Fig. 11: Communication schedule in the experiments
0 10 20 30 40 50 60 700
1
2
3
x 10−4
Time (minute)
Los
s R
atio
80HZ
50HZ
200HZ
Weighted Average
Fig. 12: Packet Loss Ratio in Normal Office Environment
TABLE VII: Loss ratio with noise maker
w/o channel blacklistand reschedule
w/ channel blacklistand reschedule
total packets 415571 424812missed packets 1081 101loss ratio 0.00259 0.00024
is 4.65 ∗ 10−5. Fig. 12 shows the change of the packet lossratio for each device along with the time. It can be observedfrom the figure that all devices’ packet loss ratios are verysmall.
B. In Noisy Environment
MBStar tolerates noisy environment with channel hopping.In this experiment, we would like to test how channel blacklistand reschedule can further improve the system performance.First, we create a noise maker that continuously sends 30-byte packets with random value every 2.5 milliseconds. Itoccupies a specific channel for a minute, then moves on toanother channel. This is repeated over all the channels. Then,we put the noise maker one meter apart from the access pointand ran the experiment twice, one with both channel blacklistand reschedule for loss packet enabled and the other withboth disabled. Each experiment is run at least 16 minutes sothat each channel has been jammed at least once. As shownin Table VII, the result is that with channel blacklist andreschedule, the loss ratio is at least 10 times lower. Note evenwith both disabled the loss ratio is still low.
C. Coexistence with other Networks
Now, we investigate the situation when there are othernetworks (BlueTooth and Wi-Fi) around. 802.15.4-2006 doc-ument [18] has shown the simulated coexistence results forZigBee, which shares the same physical layer with MBStar.From the simulation, it seems rather pessimistic while thereare other networks around. For example, if there is 802.11b(Wi-Fi) within one meter, the packet error ratio is close to 1.And if there is 802.15.1 (BlueTooth) within one meter, thepacket error ratio is more than 10%. However, our results ontest-bed are much better.
1) Coexistence with BlueTooth: In this experiment, we usea BlueTooth earplug to make a long phone call. On remote site,it plays music continuously and on local site, a mobile phone is
TABLE VIII: Loss ratio with Bluetooth around
Close to each otherResult
1 meter apart Result
packet number 596489 605432miss number 3298 135loss ratio 0.00553 0.00022
TABLE IX: Loss ratio with Wi-Fi around
static channel assign-ment
w/ channel hoppingand blacklist
total packets 212486 214582missed packets 4747 793loss ratio 0.0223 0.0037
sending data to a Bluetooth earplug. Hence, the mobile phoneis the main noise maker. Table VIII shows the results underdifferent cases. In the first setting, we put the mobile phonebetween devices and access point. And in the second setting,we put the mobile phone a little further (about 1 meter away).For the former case, the loss ratio is 0.00553 and the later,it is 0.00022, which is about 20 times better. Hence, distanceadjustment should be recommended when the two meet eachother.
2) Coexistence with Wi-Fi: In this case, we open Wi-Fi an-tenna on the laptop and are using FTP to upload and downloadfiles from a remote server. Since Wi-Fi only works on one widechannel, channel hopping and blacklist in MBStar will play animportant role in reliability. Hence, two experiments have beendone. For one experiment, we statically assign devices withchannels which overlap with Wi-Fi. For another, we enablechannel hopping and channel blacklist. The results are shownin Table IX. It can be observed that, with channel hopping,the loss ratio is about seven times lower.
From above experiments, there does exist a problem ofcoexistence between MBStar and other networks based on2.4G Hz radio. However, compared to the simulated resultsin [18], the loss ratio is very low.
VI. DISCUSSION AND CONCLUSION
In this paper, the major of our contributions is to designand develop MBStar for WBAN, which is a real-time, high-frequency, reliable, secure protocol. MBStar uses star topologyas most other wireless body area networks. The physical layerutilizes 802.15.4 compatible radio for low power consumption.The MAC layer adopts TDMA for real-time packet deliveryand a time stringent time slot with only 2.5 milliseconds isdesigned. MAC layer employs channel hopping and blacklistto avoid noise from specific channel. Retransmission is utilizedin MAC layer to provide reliability. On top of that, a simple,secure application layer is built. For security, MBStar uses IKE(Internet Key Exchange) protocol to provision a device on theair, which removes human involvement in pre-configurationand is more secure. After join, the less time-consumingsymmetrical encryption is applied on medical data for privacyprotection.
Our prototype implementation endeavors to meet the strin-gent timing requirements. Simple design and proper pre-
computation techniques are applied. For link scheduling, wepropose an easy and feasible method that only configuresa local period and an offset to a device while keeping theglobal hyper-period in the gateway. Hence, collisions betweendevices may happen and retransmission is employed. We thenpoint out that the least global average retransmission numberis independent of any scheduling algorithm and EDF is stilloptimal under such case and used for choosing the localperiod. Also, we give out the range for searching the optimaloffset.
Experimental results on our implementation are very en-couraging. In the normal office environment, error ratio isaround 10−5. For noisy environment, the functionality ofchannel blacklist and reliability mitigates the packet loss ratiogreatly. We also show co-existence results with Bluetooth andWi-Fi and it is much better than simulated results of ZigBee.Hence, it is quite suitable for real application.
Our future work consists of developing full-blown stack andmerging our protocol into a real body medical application.
REFERENCES
[1] L. Benoit, B. Braem, I. Moerman, C. Blondia, and P. Demeester, “Asurvey on wireless body area networks,” Wireless Networks, pp. 1–18,2010.
[2] K. Van Dam, S. Pitchers, and M. Barnard, “Body area networks: Towardsa wearable future,” in Proceedings of WWRF kick off meeting,, March2001.
[3] J. Goossens, “Scheduling of offset free systems,” Real-Time Syst.,vol. 24, pp. 239–258, March 2003.
[4] T. Penzel, B. Kemp, G. Klosch, A. Schlogl, J. Hasan, A. Varri, andI. Korhonen, “Acquisition of biomedical signals databases,” Engineeringin Medicine and Biology Magazine, IEEE, vol. 20, no. 3, pp. 25–32,2001.
[5] H. Li and J. Tan, “An ultra-low-power medium access control protocolfor body sensor network,” in Engineering in Medicine and BiologySociety, 2005, pp. 2451–2454.
[6] ——, “Heartbeat-driven medium-access control for body sensor net-works,” Trans. Info. Tech. Biomed., vol. 14, pp. 44–51, January 2010.
[7] I. Lamprinos, A. Prentza, E. Sakka, and D. Koutsouris, “Energy-efficientmac protocol for patient personal area networks,” in 27th AnnualInternational Conference of the engineering in Medicine and BiologySociety, 2005, pp. 3799–3802.
[8] O. A. Omeni, A. Burdett, and C. Toumazou, “Energy efficient mediumaccess protocol for wireless medical body area sensor networks,”Biomedical Circuits and Systems, IEEE Transactions on, vol. 2, no. 4,pp. 251–259, 2008.
[9] “The internet key exchange(ike),” http://tools.ietf.org/html/rfc2409.[10] B. Arazi, “Certification Of DL/EC Keys,” May 1999.[11] D. Chen, M. Nixon, T. Lin, S. Han, X. Zhu, and A. Mok, “Over
the air provisioning of industrial wireless devices using elliptic curvecryptography,” submitted to 2011 IEEE International Conference onComputer Science and Automation Engineering (CSAE 2011).
[12] M. L. Dertouzos, “Control robotics: The procedural control of physicalprocesses.” in IFIP Congress, 1974, pp. 807–813.
[13] C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogram-ming in a hard-real-time environment,” J. ACM, vol. 20, pp. 46–61,January 1973.
[14] M. Spuri and P. Reflecs, “Analysis of deadline scheduled real-timesystems,” Tech. Rep., 1996.
[15] A. K. Mok., “Fundamental design problems of distributed systesm forthe hard-realtime environment,” Ph.D. dissertation, MIT, 1983.
[16] D. E. Knuth, The art of computer programming, volume 2 (3rd ed.):seminumerical algorithms, 1997.
[17] J. Y.-T. Leung and M. L. Merrill, “A note on preemptive scheduling ofperiodic, real-time tasks,” Inf. Process. Lett., vol. 11, no. 3, pp. 115–118,1980.
[18] “IEEE standard 802.15.4-2006,” http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf, 2006.
