MBStar : A Real-time Communication Protocol for Wireless Body Area ...

1 downloads 66072 Views 1000KB Size Report
is a simple application layer designed for security on top of it. MBStar utilizes ...... and develop MBStar for WBAN, which is a real-time, high- frequency, reliable ...
MBStar : A Real-time Communication Protocol for Wireless Body Area Networks Xiuming Zhu, Song Han, Pei-Chi Huang, Aloysius K. Mok Univ. of Texas at Austin

Deji Chen Emerson Process Management

xmzhu, shan, peggy, [email protected]

[email protected]

Abstract—In this paper, we report on the design and implementation of MBStar, a higher-frequency, real-time, reliable, secure protocol for wireless body area networks(WBAN). As in most proposals for body sensor networks, MBStar adopts the star topology for communication, and is designed to support a message rate as high as 400 Hz, which to the best of our knowledge, is the highest among low-power wireless communication protocols implemented at the present time. The physical layer of MBStar utilizes 802.15.4 DSSS compatible radio for which a higher-frequency, reliable, TDMA MAC layer is built. There is a simple application layer designed for security on top of it. MBStar utilizes public/private key encryption for provisioning devices and does not involve any human configuration before device join. Considering the resource limit of most embedded systems, the TDMA requirement of computing a shared global communication schedule presents a practical problem since it may not be feasible for all the devices to communicate in a long hyper-period while the communication schedule between devices is being created or modified as devices depart and rejoin. We solve this problem by keeping only the global hyper-period schedule on the gateway side, with each device being configured with a shorter, local period. Then, retransmission is employed to resolve any conflicts between the devices. Our strategy has the property that, given any fixed task set, the minimal average number of retransmissions is independent of any communication scheduling algorithm, and the EDF (Earliest Deadline First) is optimal for our communication architecture. Finally, we present experimental results that demonstrate that MBStar is an effective protocol for wireless body area networks. Keywords-Wireless body area networks; High frequency; Reliable and real-time communication;

I. INTRODUCTION The application of wireless technology to health care has been recognized to be an important research topic [1]. Typically for such applications, sensors or actuators are attached to the human body and a powerful server that serves as the central data processor and the data sink. Together they form a wireless communication network, commonly called a Wireless Body Area Network (WBAN), as proposed in 2001 [2]. A key problem in WBAN is how to connect heterogeneous body sensors and assistive actuators securely, reliably and to meet real-time performance requirements. Typically, body sensors have to send out health data periodically and their transmission frequencies range from several Hz to several hundred Hz. There is also an increasing need for real-time control for assistive actuators. For wireless communication, there are several well-developed standards such as Wi-Fi, Bluetooth, ZigBee and WirelessHART. However, these standards fall short in some aspects to serve the needs of WBAN for medical

applications. For example, both Wi-Fi and Bluetooth cannot provide timing guarantees on packet delivery. While beaconEnabled ZigBee and WirelessHART can provide real-time communication, they are too slow for such applications. The maximum transmission frequency of WirelessHART is 100 Hz and ZigBee is even slower. In this paper, we propose MBStar, a new protocol for WBAN. The main notable features of MBStar are listed as follows. • Higher Frequency. MAC timeslot of MBStar is 2.5 milliseconds and the data rate can be as high as 400 Hz. • Real-time. MBStar MAC layer adopts TDMA (Time Division Multiple Access) to ensure accurate timing control for packet delivery. • Reliable. MBStar utilizes channel hopping and channel blacklist to minimize noise interference. It also supports acknowledged transmission and retransmission to provide link reliability. • Secure. MBStar employs both public/private key mechanisms for provisioning devices before join and uses AES (Advanced Encryption Standard) for encrypting health data after join. • Star Topology. Since body area networks cover a small area, the star topology is quite sufficient. In a MBStar network, we shall assume that a gateway is connected with access point(s) and a number of sensors/actuators are connected to the access point wirelessly. A major contribution of our paper is to provide a practical solution to implementation problems by appropriate design choices. In our application model, sensor processes send data periodically, and a sensor may depart and rejoin a network at any time. We use the offset-free scheduling model [3] where the processes are executed periodically in accordance with a schedule whose length covers the hyper-period of the processes. Because of resource limits, it may not be feasible for a sensor node to keep a long global schedule covering the hyper-period. In our solution, a newly joined sensor process is configured with the parameters of local period Tnew and an offset Onew . After configuration, the sensor sends data in the Onew + k ∗ Tnew , k = 0, 1, 2 . . . time slots. This strategy may incur ’collisions’ between the sensor data transmissions at the access point 1 since the access point can send/receive on only one channel at a time. Physically, there is actually no 1 In this paper, we assume that there is only one access point connected to the gateway; extension to the multiple access point case is possible

collision since senders transmit on different channels by using frequency hopping in our scheme, and ’collision’ is detected by the transmitter if there is no acknowledgement from the intended receiver. In case of collision, a sender retransmits the data until either it gets an ACK or data expiration. We shall define a MBStar offset-free scheduling problem in terms of the determination for each process an optimal pair of values for (Tnew ,Onew ); an optimal schedule must guarantee both the highest utilization ratio of the receiver’s channel and the lowest average number of retransmissions. We tackle this problem in four steps. First, we prove the the optimality of the EDF scheduler in generating the global schedule for the MBStar offset-free scheduling problem when the period parameters have been fixed. Second, EDF utilization upper bound is used to choose the optimal value for Tnew . Third, optimal value for Onew is determined by searching within a small range. Finally, EDF is used to generate the schedule. The remainder of the paper is structured as follows: Section II introduces background and the related work. Section III describes MBStar in Detail, followed by an prototype implementation in Section IV. Section V will present the experimental 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 least one powerful data center server, a number of sensor nodes for sensing and actuator nodes for control actions. It can be easily confused with Wireless Sensor Actuator Networks (WSAN). Compare to WSAN, the specific requirements of WBAN which can be listed as follows: 1) Reliability. Data sent by WBAN sensors are heath information for which high reliability is required. WBAN reliability should be certifiable. 2) Latency. Health data, especially emergency data, cannot tolerate long response time. Real-time transmission with performance guarantee is required, especially in the case of control actions where low latency is often required for system stability. 3) Security. privacy as well as freedom from tempering is important in WBAN. 4) Power consumption. Compared to WSAN, battery replacement in WBAN is easier and so there is less focus on power consumption. Table I lists some body sensor bandwidth requirements [1] [4]. From the table, we can see the sizes of medical data packets are usually small while the bandwidth range can vary quite widely. B. Related Wireless Protocols As mentioned above, current commercial wireless protocols (Wi-Fi, Bluetooth, Zigbee and WirelessHART) cannot be applied to WBAN directly. Table II summarizes the features of these protocols. Except for voice packets, Bluetooth cannot guarantee real-time delivery. For WirelessHART, the data rate is at most 100 Hz and the message header of WirelessHART is unnecessarily long for health data, which is not power efficient.

TABLE I: Bandwidth and data size requirements on typical biomedical measurements Biomedical measurements EMG ECG Blood Pressure Respiration Heart Rate Motion Pressure

Bandwidth 100-200 Hz 100-250 Hz 50-100 Hz 50 Hz 25 Hz 100-200 Hz

Data size 16 bits 12 bits 16 bits 16 bits 24 bits 12 bits

TABLE II: Features of present Wireless Communication Protocols Protocol

Low power

Realtime Delivery

Channel Hopping

WiFi Bluetooth Zigbee WirelessHART

No Yes Yes Yes

No Yes Yes Yes

No Yes No Yes

High frequency (> 100Hz) Possible No Yes No

Besides above protocols, there are several related works such as BSN-MAC [5], H-MAC [6], Lamprinos [7], Omeni [8]. All these protocols try to improve energy efficiency. BSN-MAC uses an adaptive MAC protocol. It utilizes 802.15.4 beacon-mode and it adjusts the interval of contentionfree and contention-based period based on sensors feedback. In this way, it gains better energy efficiency. H-MAC proposes an interesting way to synchronize the human body sensors by making use of the human heartbeat rhythm as an external clock, thus saving the energy of broadcasting time messages. Lamprinos [7] proposes a token-based mechanism to synchronize transmission between the data sink and sensors. Only the sensor that obtains the token is allowed to send data and it must release the token after finishing transmission. Through this lock-share method, it removes the collisions between slaves. Omeni [8] employs listen-before-transmit (LBT) to avoid collision with nearby senders and proposes a dynamic time 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 and there is no need to use any routing mechanism. Till today, the star topology is the major established for all WBANs. III. MBS TAR IN D ETAIL In this section, we describe the MBStar protocol in detail. MBStar adopts several important features from current wireless protocols, like channel hopping and channel blacklist to create a suitable solution for WBAN. A. MBStar Protocol Architecture and topology Fig. 1 shows the architecture of MBStar protocol. The physical layer utilizes the 802.15.4 radio for low power consumption, for which a higher frequency, reliable, TDMA MAC layer is built. The MAC layer adopts channel hopping and channel blacklist to minimize the effect of noise on any particular channel and retransmission is also used to attain high reliability. The MAC time slot length is 2.5 milliseconds supports a higher bandwidth than current low-power wireless

TABLE IV: MBStar Timing Profiles Symbol TsTxOffset TsTxMaxPacket TsRxAckDelay TsRxAckWait TsRxOffset TsRxWait TsTxAckDelay

Fig. 1: Architecture of MBStar Protocol TABLE III: 802.15.4 Radio Timing Profiles Symbol TsTxWarmup TsTxCooldown TsTxRx TsTxUnit TsTxPhyHeader

Description Tx Warm-up Tx Cool-down Turnaround between Tx and Rx Tx one byte Tx physical header (6 bytes)

Value (µs) 96 12 192 32 192

protocols. On top of all, there is a simple, secure application layer, and MBStar can support 128-bit AES (Advanced Encryption Standard) encryption/decryption. The application layer will sample health data from the sensors and then encrypt the data and pass it down to the MAC layer. The main reason why we do not put security in MAC layer is for efficiency. Usually, encryption/decryption involves high computational cost and the MAC time slot may be too short to complete all the tasks. We shift security into the application layer because the timing requirement is not as harsh. The MBStar network has a star topology that connects a number of devices to an access point that is in turn connected to the gateway. The MBStar protocol stack is executed by all the nodes in a network. Nodes that are sensors/actuators collect data and transmit them via an access point to the central data server for processing and the actuator commands are sent downlink for control actions. B. MBStar MAC Layer The MAC layer is the key part of MBStar. In this section, we will describe the definition of MAC time slot and the format of packet. 1) MAC Time Slot Definition: Table III shows the 802.15.4 timing profiles. The basic time slot is 2.5 milliseconds. The 802.15.4 physical layer header is 6 bytes. Hence, there is not much space in one packet to hold many bytes. In MBStar, the maximum DLPDU (or MAC Layer Protocol Data Unit) packet size is 24 bytes, which is quite enough for medical data and there is a smaller MAC ACK packet, which is 9 bytes. Fig. 2 and Table IV show the timing definition for transmitting slot and receiving slot. A noteworthy value is TsRxWait and TsRxAckWait. Both are 434 µs, which is designed for receiving all the physical header bytes. If there is no physical header of a packet arriving after this period, the receiver should close its antenna for saving power. 2) Time Synchronization: Since MBStar adopts a very timestringent slot size, the time synchronization requirement is more demanding than other low-power networks. Since two devices may drift in different directions, the receiver may open its antenna either too early or too late. In MBStar, the

TsTxAck

Description Tx preparation time Time to Tx the max packet (24 Bytes) Time between finishing Tx and waiting for the ACK Wait time for the start of ACK Rx preparation Time Wait time for the start of message Time between the end of message and start of sending ACK Tx time for ACK

Value (µs) 100 972 150 434 50 434 200 492

Fig. 2: MAC Slot Timing

receiver should open the antenna 50 µs before the sender starts transmitting. Hence, the maximum permitted time difference is 50 µs. For devices with 10 ppm clock accuracy, we have to synchronize them at least every 50/(10 * 2) = 2.5 s. Since MBStar is a star topology, it is enough for the access point to send out a broadcast packet every 2.5 seconds. 3) MAC Data Format: Table V shows the DLPDU data packet format. MBStar endeavors to find a good balance between reliability, security and packet size. For one packet, there is a 9-byte overhead. A packet begins with 2-byte tag in order to distinguish itself from other 802.15.4 compatible protocol packets. The time slot number snippet gives the least significant byte of the time slot number which denotes the offset (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 generated securely according to the present absolute slot number and destination address. Only two devices sharing the same key can authenticate it. Finally, there is a 2-byte CRC at the tail of the packet. 4) Channel Hopping and Channel Blacklist: MBStar adopts channel hopping and channel blacklist to minimize the effect of noise on any specific channel by using hopping from channel to channel. Each device is configured with a unique channel offset. The current channel for a device can be computed as follow. Channel = (Timeslot Snippet + Channel Offset) % Number of Channels Periodically, the access point updates the transmission failure number of each channel and broadcasts the present channel situation. In this way, each device in the network knows how to avoid using blacklisted channels before the next update.

TABLE V: DLPDU format Byte Number Byte 0-1 Byte 2 Byte 3 Byte 4 Byte 5-n Byte n+1-n+2 Byte n+3-n+4

Description MBStar Packet Tag Bit 0-3 is for packet specifier and bit 4-7 is network ID Bit 0-3 is destination address and bit 4-7 is source address Time slot number snippet (the least significant byte value) Payload (maximum 15 bytes) MIC (message integrity code) CRC

C. Application Layer The application layer is relatively simple. It is mainly responsible for encrypting sensor data and decrypting configuration commands from the access point. The maximum APDU payload is 14 bytes, which is enough for medical application.

1) The gateway first configures the access point and then the access point starts to broadcast periodically. 2) For a device, it synchronizes itself when it receives broadcast packets and then starts to send request for authentication based on Internet Key Exchange protocol (IKE). 3) After finishing IKE phase II, a shared key is established between the gateway and the device. Then, the gateway configures a new key and the network ID into device. At this point, secure communication channel is established. 4) Next, the device will send out a bandwidth request and wait for the response from the gateway. If the request is authorized, the device will send out data periodically subject to the bandwidth agreement. 5) A device may drop out of the network for losing synchronization at any time. However, it can always start rejoin. IV. I MPLEMENTATION

D. Security Basically, secure communication in wireless networks involves two steps: 1) How to authenticate the new device during joining process? 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 for password input. ZigBee and WirelessHART require the user to store the unique device ID beforehand. A manual configuration interface (keyboard, screen, FSK port and so on) is needed for authentication. In MBStar, we utilize the Internet Key Exchange protocol (IKE) [9] to authenticate and provision a device over the air. IKE consists of two phases. In phase I, we use the Diffie-Hellman key exchange mechanism to establish a secure authenticated communication channel between peers. Based on the secure channel, the peers negotiate Security Associations (SAs) for further services. In MBStar, we adopt a SelfCertified ECC-based Diffie-Hellman(ECDH) key exchange protocol [10] in phase I. In phase II, a certificate is generated in the gateway and will be configured into the new device. One major concern of using ECDH on embedded systems is the time overhead. ECDH is not a good option for timestringent applications. However, since there is usually no explicit time requirement for the join process, this is not a problem. The latter is much easier to handle. As soon as a device is authenticated, a fresh communication key will be immediately provisioned with the shared key generated by ECDH. Thereafter, communication will be protected by symmetric encryption/decryption algorithms, such as AES or DES. MBStar can support up to 128-bit encryption, which is deemed to be good enough at the current time. E. Join Sequence Based on the above description, the sequence of a device join is as follows:

In this section, we will describe our implementation. We shall first introduce our hardware platform, and then our software architecture. Then, we shall discuss some algorithmic issues concerning link scheduling. A. Hardware Platform Our implementation is built on Freescale MC1322x series which 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 security Freescale provides both a simple 802.15.4 physical layer library and a security library. These libraries enable us to operate the antenna directly and develop the security module easily in MBStar. B. Software Architecture Fig. 3 shows the software architecture of our implementation. The main modules can be described as follows: • Message Handling Module: Message Handling module is responsible for sending and receiving packets, usually one for receiving and another for sending. For a nontiming-critical interface (sensor to APP,e.g), there is a packet queue associated with it and the message handling module will use events to notify the corresponding layer after putting the packet in the queue. For timing-critical tasks, message handling will directly use interrupts to handle the message. There is no queue between the MAC layer and the physical layer. The transmitting buffer and receiving buffer are shared by both layers. This simple design removes the queuing delay and ensures the quick handling of messages. • Timer Module : There are four 16-bit hardware timers on MC1322x and we use only one of them. For each timer, there is a free running register storing the current tick number and a comparison register for input. Whenever

the values of the two registers are the same, a timer interrupt event will occur. Timer interrupts have the highest priority and are used for processing only time critical and light-weight jobs. Computational intensive job, like encryption/decryption, may take too long and thus are not performed by the timer interrupt handler. Another function of the timer module is synchronization with the access point. In MBStar, the synchronization operation is carried out when a packet, mostly, advertisement, from the access point arrives. The arrival time of the first bit is recorded and is compared to the designed packet sending time as follows. time diff = arrival time -slot star time-TsTxOffset









As mentioned above, a device will redo the synchronization at least every 2.5 seconds to maintain synchronization. Scheduler : The scheduler module in the MAC layer is used to determine the type (transmitting, Receiving, or idle) of next time slot according to configuration stored in MAC PIB. In our implementation, it is called at the end of each time slot because a device has to get all the information to determine the type of next slot (retry, e.g). Security Module : The security module is put in the application layer because of its high time cost. This decision is acceptable in MBStar. Measurements show that it takes less than 0.5 milliseconds for encrypting/decrypting 24 bytes on MC1322x with built-in AES module. For secure provisioning, [11] lists the time and memory cost on MC1322x: the total memory footprint of ECDH implementation is around 12 KB and it takes less than 10 seconds to complete all the authentication steps. Pre-computation is also employed in our implementation. For example, the encryption of sensor data can be done beforehand. Also, packet MIC generation can also be precomputed both for sender and receiver because MIC is not related to the content of a packet. MAC Time Slot State Machine : Fig. 4 shows the transition of MAC time slot states for transmitting slot and receiving slot. The transition is driven either by timer interrupt or by message coming interrupt. As shown in the figure, all the operations are light-weighted to guarantee timing requirements. APDU processor : The functionality of APDU (Application Protocol Data Unit) processor is simple. It is used to parse configuration messages from the gateway and encapsulate sensor data into APDU which is then sent down to MAC layer.

C. Link Scheduling This section introduces the link scheduling problem in MBStar. We first describe a typical scenario and define the associated MBStar offset-free scheduling problem. We then discuss our solution approach. 1) MBStar Offset-free Scheduling Problem: For economy of 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 from sensors. Our discussion can be readily extended to the downlink case. The scenario can be described as follows: • •



For the access point, it can only communicate with one device in each time slot. For a wireless body sensor, it may have a desired data transmission rate (maximum rate) and also a tolerable rate (minimum rate). In other words, the bandwidth request is a range. (See Table I) The protocol is based on TDMA and channel hopping. So, devices are sending on different channels in the same time slot. There is no physical collision but logical

devices

2 1 0

0

1

2

3

4

5

6

time slot Fig. 5: An Example for Schedule in Gateway

transmission collision may occur at the target (access point). • To ensure data reception, the sender will retransmit the same data packet if it does not receive the correct ACK. However, if a new sample arrives (sampling rate is the same as transmission rate), the sender will have to discard the 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 enough bandwidth to meet the lowest data rate requirement, the device will not be permitted to join the network. To solve the problem, we adopt a simple way to configure the device. For each bandwidth request, the gateway will respond with two values: the designated beginning time slot number and the permitted rate. If the permitted rate is not zero, the device can start sending the data at the designed time slot number at the (fixed) permitted rate ad infinitum. Otherwise, the bandwidth is insufficient and the device is not permitted to send any data. The gateway has all the information required to generate a suitable schedule to guarantee every packet be received before expiration if there is no other interference. Note that the devices do not have knowledge of the global schedule that spans a hyper-period. Each device only keeps its own period. Fig. 5 shows an example of the schedule. The X-axis denotes time slot number and Y-axis denotes sensor number. A stripped block denotes a transmission failure because of ’collision’ while a clear one means a success (same for later figures). In this figure, there are two sensors. Sensor 0 is sending a packet every 2 slots while sensor 1 is sending every 3 slots. Both begin at time 0. And at time 0, access point is scheduled to pick up the packet sent by sensor 0 and send an ACK back. At time 1, access point is scheduled to talk to sensor 1 since it knows sensor 1 will retry. There are several reasons why we do not share the global schedule that spans the hyper-period. First, since the sampling rates of medical devices are not harmonics in general, the length of the hyper-period may be very long. We cannot in practice expect every device to have enough memory or computing capability to keep in step with the global scheduler. Also, the configuration packet size is likely to be not long enough and thus, the configuration loop will be very long even if a device has enough space. Second, since devices may join and leave arbitrarily, each join and departure will involve an 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 1 is of no use, which results in power waste. However, as stated in the related work section, recharging body medical devices is

much easier than that in normal wireless sensor networks, and power consumption is not considered as the key issue here. We adopt the offset-free real-time scheduling model [3] to tackle our problem. In offset-free systems, the offset of tasks is assigned by the scheduler. In MBStar, we aim to find both an optimal offset and period for a new device. Thus, the MBStar offset-free scheduling problem is defined as follows: Consider that n senders s1 , . . . , sn already joined the network, and there is a new sensor snew that needs to be accommodated. • Each joined sensor si is characterized by a pair (Ti , Oi ) with period Ti ∈ N and offset Oi ≥ 0. The release time of kth (k = 1, 2, . . .) packet of si is Oi + (k − 1) ∗ Ti . And, sender si keeps transmitting the packet until either it receives an ACK from the receiver or the next packet from the sensor is released. The kth packet must be received before Oi + k ∗ Ti th slot. • The new sensor is characterized by a pair (minTnew ,maxTnew ) with desired period to be minTnew but no bigger than the tolerable period maxTnew . • The average global retransmission number retran number is defined as the number of retransmissions divided by the number of successful transmissions 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 all joined si . • The new task set is a set of pairs {(T1 , O1 ), ..., (Tn , On )},which n ∈ N that contains the period and offset assignment to the new sensor task. The objective is to find a pair (Tnew , Onew ) for the new sensor, 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 the smallest average retransmission number. Next, we shall discuss our solution approach for this problem. First, the optimality of the EDF policy is proved given that the task period and offset parameters are fixed. Then, how to choose optimal values for (Tnew , Onew ) will be proposed. 2) Optimality of EDF: The optimality of the EDF (earliest deadline first) preemptive scheduling algorithm for tasks with arbitrary release times and deadlines has been proved by Dertouzos [12]. Liu and Layland [13] and Spuri [14] proved that as long as the global utilization ratio is no bigger than 1, EDF can be applied successfully, even if the tasks are asynchronous. This also applies to the discrete time model where the granularity of time measurements is in terms of integral multiples of some basic time quantum [15]. In this model, time intervals are always measured between integral time points and given in integral time units (time slots). Since our protocol is based on TDMA, one transmission only takes exactly one time slot regardless of the data size and both task periods and execution times are all measured in time slots.

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 other words, there exists a minimum non-zero number of collisions between devices if equation (2) is satisfied. We now show Lemma IV.3. Lemma IV.2: If n devices collide at the same time, at least n ∗ (n − 1)/2 retransmissions will be generated. Proof: Suppose n devices collide at time slot t, since the access point can only receive one packet at one time slot, it needs at least n time slots to receive n packets. Then, at time slot t + 1, at least n − 1 devices will resend. Hence, at time slot t + i, i ∈ [1, n − 1], at least n − i retransmissions will come out. Hence, totally, 1 + 2 + . . . + (n − 1) = n ∗ (n − 1)/2 retries will be generated. 2 Lemma IV.3: For any given fixed task set, the smallest global average retransmission number is independent of the scheduling algorithm that does not idle tasks unnecessarily. Proof: Based on Lemma IV.1 and Lemma IV.2, we can get that the smallest average retransmission number is only related to periods and offsets. Thus, no scheduling algorithm can affect this value. For a scheduler, as long as it schedules a successful receiving 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 is pairwise co-prime between each other, equation (2) is satisfied for all offsets. Every 15 slots, period 3 and 5 ’collide’ and at least one should retry. Every 12 slots, period 3 and 4 ’collide’ and at least one should retry. Also, every 20 slots, period 4 and 5 ’collide’ and at least one should retry. Finally, every 60 slots, all three ’collide’ and at least three retrial packets will be sent. Theorem IV.1: Given a fixed offset-free task set, EDF is optimal for generating the schedule for the MBStar offset-free scheduling problem.

2

devices

2

1

0

1

0

5

10

15

0

20

0

5

time slot

10

15

20

time slot

(a) EDF Schedule

(b) RM Schedule

Fig. 6: Example for same average retransmission number

Proof: EDF satisfies the first requirement for optimality according to Dertouzos [12]. For the second requirement, we note that the receiver does not idle unnecessarily because one packet among all the packet in a logical collision is always picked up by the access point. So the EDF scheduler achieves the highest utilization and also does not cause any extra 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 the right is generated by the RM (Rate Monotonic) scheduler. From the figure, the average retransmission number of both schedules which is also the smallest value, is the same. As long as the ’collided’ slot is not idle, the retransmission ratio is the smallest. 3) Solution for MBStar Offset-free Scheduling Problem: The above section shows that it is straightforward to choose the optimal value for Tnew as long as the global utilization ratio is smaller than 1. However, finding an optimal value for Onew is more difficult and the choice of Onew might greatly affect the average retransmission number. Fig. 7 shows an example. For case A the task set is {(2,0),(3,0),(6,5)} and for case B it is {(2,0),(3,0),(6,0)}. Both schedules are generated by EDF and it is obvious that the average retransmission number of case A will be much lower than that of case B. 3

devices

(1)

3

2 1 0

0

1

2

3

4

5

6

4

5

6

time slot (a) Case A 3

devices

a ≤ t < a + P, t ≡ Oi (mod Ti ), 1 ≤ i ≤ n

3

devices

Notice that here, any time interval cannot span window that starts in the middle of a time slot and ends in the middle of another one. Let a time slot be a scheduling time unit, then all task periods and execution times are integers. Furthermore, all execution times are of one time unit. Thus, it is not hard to see that EDF meets the first constraint. We shall prove EDF retains its 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 least common multiple of T1 , T2 , . . . , Tn and let a, O1 , . . . , On be any integers. There exists one integer t which satisfies the conditions

2 1 0

0

1

2

3

time slot (b) Case B Fig. 7: Example for Different Offset Assignments

Unfortunately, we do not have an analytical expression to compute the optimal Onew . For practical purpose, however, we

4 Optimal Assignment

Retransmission ratio

3.5

Random Assignment 3

All Zero

2.5 2

Fig. 9: Example for reschedule

1.5 1 0.5 0

0

5

10

15

number of tasks Fig. 8: Average Retransmission Numbers for Different Offset Assignment Policies

can search through all the possibilities provided that the search range is small. In particular, note that the search range is no larger than Tnew , and paper [3] further proves that there are at most gcd{Tnew ,lcm{T1 , . . . , Tn }} choices for Onew and the range is [0,gcd{Tnew ,lcm{T1 , . . . , Tn }}), where gcd and lcm denote the greatest common divisor and the least common multiple respectively. In practice, since the hyper-period length is already known, the time complexity of searching Onew is O(Tnew ). We note that the searching space will be much larger if we had tried to solve the global scheduling problem that does not allow retransmission such that the offsets have to be found for every task to avoid any collision. Algorithm 1 summarizes the solution. It should be noted that, in line 23, we only compare the average retransmission number 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 infinite horizon schedule. We have done a simulation to find out how much gain we can get from the optimal offset assignment. The results are shown in Fig. 8. In the simulation we generate several groups of sensors with periods randomly chosen between 2 and 40. The group size is between 2 and 15. For each group, we tried three types of offset assignment policies and measure the average retransmission number. The policies are: all zeros, random assignments and optimal values. Each test is repeated 5 times and the average is taken. In Fig. 8 the X-axis is the group size and the Y-axis is the average of the average retransmission number. From the figure, we can see that the optimal assignment is the best. Its average retransmission number is always below 0.5 and about half of that of the random assignment. Both are better than the zero assignment, whose average retransmission number can be as high as above 3.5. Bigger retransmission number leads to bigger power consumption. It should be emphasized that when there is a physical packet loss, a device will retry. For the access point, it can easily reschedule another ’pickup’ before packet expiration. Fig. 9 gives a illustration. The task set is {(5, 0), (2, 0)}. At slot 5 (the block with a cross), the packet is supposed to be received successfully by access point but lost because of interference. However, the access point soon finds out that it should receive

a packet from device 0 and knows it will retry. Hence, it will ’wait’ at slot 8 and get the packet before its expiration. Notice that, since the access point knows all the offsets and periods, it only needs to search a short range (at most the period of the faulty device) to produce such a schedule. However, if the schedule is pretty full, it may not be able to find an empty slot and the packet will be lost forever. Algorithm 1 Solution for MBStar offset-free problem 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31:

// // // // //

Input: Bandwidth request (minTnew , maxTnew ) Output: Pair (Tnew , Onew ) and an optimal schedule S U Ratio is the present utilization ratio H Len is the present length of hyper-period V is the present scheduled tasks set

//Step 1: Find optimal value for Tnew if U Ratio + 1/maxTnew ≤ 1 then Find the smallest value T 0 in [minTnew , maxTnew ] which 1/T 0 + U Ratio < 1. Then, Tnew = T 0 else return FAILURE; // No enough bandwidth end if //Step 2: Find Optimal value for Onew Of f set Range=gcd(Tnew , H Len) least Retran Ratio = M ax P eriod(V ∪ (Tnew , O0 )) optimal Of f set = 0 for all Each O0 between [0,Of f set Range − 1] do V 0 = V ∪ (Tnew , O0 ) r = M ax Of f set(V 0 ) // new hyper-period length P = gcd(H Len, T new) // Generate EDF schedule in [r + P, r + 2 * P] S 0 = Get EDF Schedule(0, r + 2 ∗ P ) retran Ratio = Get ReT ran Ratio(S 0 , V 0 ) if least Retran Ratio > retran Ratio then least Ratran Ratio = retran Ratio optimal Of f set = O0 S = S0 end if end for

V. E XPERIMENTS In this section, we present our experiment results based on the prototype implementation which is described in Section IV, and setup a star network with one access point and three devices as shown in Fig. 10. The access point is connected to

−4

x 10

80HZ 50HZ 200HZ Weighted Average

Loss Ratio

3

Fig. 10: Experiment testbed: One Access Point and three devices are organized in a star network TABLE VI: Device configuration and experiment settings

2

1

0

0

10

20

30

40

50

60

70

Time (minute)

Dev ID

Description

dev 1

access point sensor sensor sensor

dev 2 dev 3 dev 4

Data Frequency NA

Period

Offset

40

NA

Join Sequence 0

80 Hz 50 Hz 200 Hz

5 8 2

0 0 1

1 2 3

Fig. 12: Packet Loss Ratio in Normal Office Environment TABLE VII: Loss ratio with noise maker

total packets missed packets loss ratio

a computer through the serial port, and the baud rate is set to 230400 bps. A serial port communication software is running on the computer to collect all the packets exchanged between the computer and the access port. The frequencies of the three devices are 200Hz, 80Hz and 50Hz, respectively. Their join sequence and offset assignments are summarized in Table VI and the communication schedule is shown in Fig. 11. Same as in Fig. 9, a stripped block is used to denote a transmission failure because of collision. Our experiments mainly focus on evaluating the loss ratio of our MBStar system in different test scenarios. The results are shown in normal office environment, noisy environment and its co-existence performance when other wireless networks in 2.4GHz frequency band are present, for instance, Bluetooth and Wi-Fi. A. Experiments in Normal Office Environment In this experiment, we put our testbed in a normal office environment. There are several Wi-Fi networks around but we disable the Wi-Fi interface on the laptop. Then, after the MBStar system keeps running in one hour, collects 1311599 packets in total and misses 61 packets. The averaged loss ratio

w/ channel blacklist and reschedule 424812 101 0.00024

is 4.65 ∗ 10−5 . Fig. 12 shows the change of the packet loss ratio for each device along with the time. It can be observed from the figure that all devices’ packet loss ratios are very small. B. In Noisy Environment MBStar tolerates noisy environment with channel hopping. In this experiment, we would like to test how channel blacklist and reschedule can further improve the system performance. First, we create a noise maker that continuously sends 30byte packets with random value every 2.5 milliseconds. It occupies a specific channel for a minute, then moves on to another channel. This is repeated over all the channels. Then, we put the noise maker one meter apart from the access point and ran the experiment twice, one with both channel blacklist and reschedule for loss packet enabled and the other with both disabled. Each experiment is run at least 16 minutes so that each channel has been jammed at least once. As shown in Table VII, the result is that with channel blacklist and reschedule, the loss ratio is at least 10 times lower. Note even with both disabled the loss ratio is still low. C. Coexistence with other Networks

3

devices

2

1

0

w/o channel blacklist and reschedule 415571 1081 0.00259

0

5

10

15

20

25

30

35

time slot Fig. 11: Communication schedule in the experiments

40

Now, we investigate the situation when there are other networks (BlueTooth and Wi-Fi) around. 802.15.4-2006 document [18] has shown the simulated coexistence results for ZigBee, which shares the same physical layer with MBStar. From the simulation, it seems rather pessimistic while there are 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, the packet error ratio is more than 10%. However, our results on test-bed are much better. 1) Coexistence with BlueTooth: In this experiment, we use a 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

packet number miss number loss ratio

Close to each other Result 596489 3298 0.00553

1 meter apart Result 605432 135 0.00022

TABLE IX: Loss ratio with Wi-Fi around

total packets missed packets loss ratio

static channel assignment 212486 4747 0.0223

w/ channel hopping and blacklist 214582 793 0.0037

sending data to a Bluetooth earplug. Hence, the mobile phone is the main noise maker. Table VIII shows the results under different cases. In the first setting, we put the mobile phone between 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, distance adjustment should be recommended when the two meet each other. 2) Coexistence with Wi-Fi: In this case, we open Wi-Fi antenna on the laptop and are using FTP to upload and download files from a remote server. Since Wi-Fi only works on one wide channel, channel hopping and blacklist in MBStar will play an important role in reliability. Hence, two experiments have been done. For one experiment, we statically assign devices with channels which overlap with Wi-Fi. For another, we enable channel hopping and channel blacklist. The results are shown in 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 of coexistence between MBStar and other networks based on 2.4G Hz radio. However, compared to the simulated results in [18], the loss ratio is very low. VI. D ISCUSSION AND C ONCLUSION In this paper, the major of our contributions is to design and develop MBStar for WBAN, which is a real-time, highfrequency, reliable, secure protocol. MBStar uses star topology as most other wireless body area networks. The physical layer utilizes 802.15.4 compatible radio for low power consumption. The MAC layer adopts TDMA for real-time packet delivery and a time stringent time slot with only 2.5 milliseconds is designed. MAC layer employs channel hopping and blacklist to avoid noise from specific channel. Retransmission is utilized in 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 the air, which removes human involvement in pre-configuration and is more secure. After join, the less time-consuming symmetrical encryption is applied on medical data for privacy protection. Our prototype implementation endeavors to meet the stringent timing requirements. Simple design and proper pre-

computation techniques are applied. For link scheduling, we propose an easy and feasible method that only configures a local period and an offset to a device while keeping the global hyper-period in the gateway. Hence, collisions between devices may happen and retransmission is employed. We then point out that the least global average retransmission number is independent of any scheduling algorithm and EDF is still optimal under such case and used for choosing the local period. Also, we give out the range for searching the optimal offset. Experimental results on our implementation are very encouraging. In the normal office environment, error ratio is around 10−5 . For noisy environment, the functionality of channel blacklist and reliability mitigates the packet loss ratio greatly. We also show co-existence results with Bluetooth and Wi-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 and merging our protocol into a real body medical application. R EFERENCES [1] L. Benoit, B. Braem, I. Moerman, C. Blondia, and P. Demeester, “A survey on wireless body area networks,” Wireless Networks, pp. 1–18, 2010. [2] K. Van Dam, S. Pitchers, and M. Barnard, “Body area networks: Towards a wearable future,” in Proceedings of WWRF kick off meeting,, March 2001. [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, and I. Korhonen, “Acquisition of biomedical signals databases,” Engineering in 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 protocol for body sensor network,” in Engineering in Medicine and Biology Society, 2005, pp. 2451–2454. [6] ——, “Heartbeat-driven medium-access control for body sensor networks,” Trans. Info. Tech. Biomed., vol. 14, pp. 44–51, January 2010. [7] I. Lamprinos, A. Prentza, E. Sakka, and D. Koutsouris, “Energy-efficient mac protocol for patient personal area networks,” in 27th Annual International Conference of the engineering in Medicine and Biology Society, 2005, pp. 3799–3802. [8] O. A. Omeni, A. Burdett, and C. Toumazou, “Energy efficient medium access 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 curve cryptography,” submitted to 2011 IEEE International Conference on Computer Science and Automation Engineering (CSAE 2011). [12] M. L. Dertouzos, “Control robotics: The procedural control of physical processes.” in IFIP Congress, 1974, pp. 807–813. [13] C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming 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-time systems,” Tech. Rep., 1996. [15] A. K. Mok., “Fundamental design problems of distributed systesm for the 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 of periodic, 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.