Emergency Handling for MAC Protocol in Human Body Communication

Abstract

The human body communication (HBC) is a technology that enables short range data communication using the human body as a medium, like an electrical wire. Thus it removes the need for a traditional antenna. HBC may be used as a type of data communication in body area network (BAN), while the devices are being in contact with body. One of important issues in BAN is an emergency alarm because it may be closely related to human life. For emergency data communication, the most critical factor is the time constraint. IEEE 802.15.6 specifies that the emergency alarm for the BAN must be notified in less than 1 sec and must provide prioritization mechanisms for emergency traffic and notification. As one type of BAN, the HBC must follow this recommendation, too. Existing emergency handling methods in BAN are based on the carrier sensing capability on radio frequencies to detect the status of channels. However, PHY protocol in HBC does not provide the carrier sensing. So the previous methods are not well suitable for HBC directly. Additionally, in the environment that the emergency rate is very low, the allocation of dedicated slot(s) for emergency in each superframe is very wasteful. In this work, we proposed specific emergency handling operation for human body communication's medium access control (HBC-MAC) protocol to meet the emergency requirements for BAN. We also showed the optimal number of emergency slots for the various combinations of beacon intervals and emergency rates.

1. Introduction

The IEEE 802.15 Task Group 6 (BAN Group) is developing a communication standard optimized for low power devices operating on, in, or around the human body (but not limited to humans). It covers a variety of applications in medical area, consumer electronics area, personal entertainment area, and so forth [1].

A typical wireless BAN consists of a number of inexpensive, lightweight, and miniature sensor platforms from application to application, each featuring one or more physiological sensors. For example, 12 for cardiac arrhythmia monitor/recorder, 6 for wireless capsule endoscope, and 12 for insulin pump. The usual number of nodes is expected to 12 in the standard document. The sensors could be located on the body as tiny intelligent patches, integrated into clothing, or implanted below the skin or muscles. Application in BAN includes permanent monitoring and logging of vital signs with the goal of supervising the health status of patients suffering from chronic diseases.

The BAN using human body as a communication medium has been researched in frequency, transmission range, node distance, transmitting power, received power, and energy consumption to form a power and energy efficient network.

The human body communication (HBC) is a method for data communication using user's body as a medium. It does not require any wire or wireless medium [2]. Two devices are connected and data is transmitted between them via user's body, simply by touch: touch and play (TAP) concept as shown in Figure 1.

Figure 1

HBC applications.

HBC is very suitable for providing a context awareness service based on TAP. After devices are connected by touch, identification signals are transmitted through user's body, and the type of devices is recognized by each other. For example, when a user touches an advertisement device with one hand while holding a PDA in the other hand, the touch is detected by the advertisement device and the device sends advertisement contents. Finally, the information can be downloaded into the PDA via user's body.

HBC provides these features by utilizing frequency selective digital transmission (FSDT), a type of direct digital signaling. Because it does not require analog modulation, the transmitted data can be reached in the receiver using simple signal processing: amplifying, filtering, and comparing with a reference signal. Hence, the communication devices with FSDT are easy to implement, has low power consumption, and can be made in small sizes.

Wearable health monitoring systems integrated into a telemedicine system are novel information technology that will be able to support early detection of abnormal conditions and prevention of its serious consequences [3]. When the HBC technologies are applied to the wearable medical systems, it is very important and essential to immediately deal with emergency situation because of being fatal to human. Medical emergency data usually needs high priority and reliability than nonmedical data. Late reporting of emergency situation might be fatally harmful. For emergency data communication, the most critical factor is the time constraint.

Fortunately, the IEEE 802.15.4 standard reserves a guaranteed time slot called GTS for future use [4]. However, there is no reliable support for on demand and emergency traffic. Thus, the pure concept of superframe structure of 802.15.4 cannot be applied to emergency data handling. Other proposals for the emergency handling are basically based on the CSMA/CA mechanism in BAN. Their medium is radio signal whose frequencies might be 400 M or 2.4 GHz and network range is purposed to be up to 5 meters. But HBC network uses human body as medium of 10~30 MHz frequencies and its PHY layer does not support carrier-sense capability. The MAC approach is totally different, and so is the emergency handling. Complete list of MAC technical requirements are derived from the approval of TG6 technical requirement document [5]. The documents mandate emergency management capabilities for the IEEE 802.15.6 specification. The specification must support alarm state notification across BAN in less than 1 second and must provide prioritization mechanisms for emergency traffic and notification. In this work, we proposed specific emergency handling operation for HBC-MAC to meet emergency requirements of BAN.

The rest of this paper is organized as follows: Section 2 presents related works for our protocol and Section 3 describes emergency handling for HBC-MAC that we propose. In Section 4, we present performance analysis and performance results are shown. In Section 5, finally we give concluding remarks.

2. Related Works

Several MAC protocols have been developing for IEEE 802.15.6 to meet emergency requirement capacities [6–9].

In Samsung MAC proposal [6], polling-based channel access mechanism is preferred with the proposed design approach. Polling is the most suitable channel access mechanism for implant communication. Poiling mechanism for on body communication eases out integration aspects of channel access mechanisms. But emergency data handling scheme should support fast and reliable transfer of emergency data for implant devices.

Olympus MAC purposed for a star-topology BAN [7]. In beacon period (BP), coordinator sends beacon periodically to bind the superframe as shown in Figure 2. In emergency access period (EAP), coordinator reserves slots for periodical guaranteed communication with end devices. At least one EAP slot is required to poll every end device periodically. If one EAP slot is not enough, it can be used to reserve more CFP slots. It is faster way to get contention free period (CFP) than going through contention access period (CAP).

Figure 2

NICT MAC superframe structure.

Versatile MAC [8] equips with ETS (emergency data transmit slot) in TDMA data transmit period. ETS is highly adaptable to abrupt emergency data and supports high QoS and reliability. Versatile MAC handles data based on their priority. Prioritized back-off, CCA, and data slot allocation are applied to all data transmission to serve higher priority data first. The ETS is designed for emergency alarm primarily, but it may be used for nonemergency data. In case no DTS (data transmission slot) is available, ETS can be assigned to nonemergency data.

NICT proposed a BAN superframe structure for TG6 [9]. The structure consists of active portion and inactive portion. The active portion is sequentially divided into three portions: the beacon, the contention access period (CAP), and the contention-free period (CFP) as shown in Figure 2. PTS, CAP, and CFP are called priority access period (PAP). The CAP supports contention-based channel access for one-time prompt traffic, such as device association/deassociation, bandwidth request, and some low duty cycle traffics. The CFP supports scheduled channel access for periodical traffics and QoS guaranteed traffics, such as medical waveforms and stream of audio and video. The priority access period (PAP) is immediately after the beacon in the superframe. The PAP is comprised of priority time slot (PTS) which is a physical time period immediately after the beacon, and embedded PAP, which are the unoccupied slots in both CAP and CFP. The PTS in the superframe provides guaranteed channel access only for emergency traffic.

These MAC protocols for IEEE 802.15.6 follow the emergency requirements. However most of them use carrier sense operation to get the channel. In HBC, physical layer protocol does not provide carrier sense capability. A node cannot sense the signals on a body whether other nodes start to send a message or not. Thus, existing emergency handling techniques for BAN are not well suitable for HBC.

3. Emergency Handling for HBC-MAC

Our proposed MAC protocol modified beacon enabled IEEE 802.15.4 protocol maintaining a superframe structure. The superframe is composed of three parts: beacon, contention access period (CAP) and contention free period (CFP), as shown in Figure 3. CFP consists of a number of guaranteed time slots (GTS) and may include zero or single emergency guaranteed time slot (EGTS) or several EGTSs.

Figure 3

Superframe structure of HBC.

According to IEEE 802.15.4 contention access protocol specification, nodes have to perform clear channel assessment (CCA) before transmitting data into the channel. The use of CSMA/CA provides a reliable solution for wireless sensor network but it cannot be used for human body communication because nodes cannot perform CCA in a favorable way. Therefore within the CAP part of HBC-MAC, we applied slotted ALOHA scheme without carrier sensing. Because HBC does not have CS capability, the only way for a sender to know whether the transmission was successful or not is to receive a successful ACK frame from the receiver in a slot period. CAP is used for the irregular management data and medical report data. CFP is used reservation-based by request/confirm for bulky and/or regular data transmissions. The CFP is activated upon request from a node to coordinator for allocating time slots depending on the node's requirement. Upon receiving this request, the coordinator checks whether there are sufficient resources and, if possible, allocates the requested time slots.

Emergency data frame is very short; therefore, one time slot is enough for whole emergency data transmission. From the view of an irregular short message, it is adequate to be transmitted in CAP. But from the view of reliability, transmission is not guaranteed for the high-priority emergency data in CAP. So we allocated emergency GTS (EGTS) in CFP as if emergency were a regular event. Whenever any device has an emergency data, it uses EGTS without request to coordinator. But because it is not a regular event, it is wasteful to allocate many EGTS slots in every CFP. So we propose how many EGTS slots are necessary in various conditions of beacon interval (BI) time and emergency occurrence rates. As coordinator controls the number of EGTS in CFP, some CFP may have several EGTSs and some CFP may have zero EGTS. But usually the maximum number of EGTSs in a superframe does not exceed one. The existence and the location of EGTS are broadcasted through Beacon to every node by coordinator. We form a group of superframes without EGTS along with superframe with one or more EGTSs into a superframe group.

Case A (Emergency occurs in a superframe interval which has EGTS).

In this case, emergency data is transmitted immediately using EGTS without any hesitation, as shown in Figure 4. Devices know whether the EGTS is included in this superframe or not by listening to the beacon. If an EGTS has been allocated in the current superframe, the device can transmit the emergency traffic in the allocated EGTS.

Figure 4

Emergency alarm occurs within superframe interval with EGTS.

Case B (Emergency occurs in a superframe interval which doesnot include EGTS).

In this case, device doesn't wait next superframe interval with EGTS. Once the emergency occurs within superframe interval without EGTS, device tries to transmit emergency alarm in CAP duration until it meets superframe including EGTS. This is to provide a second opportunity for emergency traffics which occurred in the superframe interval without EGTS. In HBC, slotted aloha is used in CAP. Therefore it cannot guarantee successful transmission. If emergency alarm transmission fails within all the CAP durations, then it can transmit at guaranteed time slot, as shown in Figures 5(a) and 5(b).

Figure 5

(a) Emergency alarm occurs within superframe interval without EGTS (successful in CAP). (b) Emergency alarm occurs within superframe interval without EGTS (successful in EGTS).

Case C (Multiple emergencies).

In a life critical situation, multiple alarm sources may activate alarms simultaneously. Multiple emergencies may happen in EGTS-superframe as shown in Figure 6, or in multiple without EGTS-superframes duration as in Figure 7. In both cases, emergency data may collide in one EGTS. Even though they will try to get the slots at the next CAP or EGTS period, it will degrade the performance of emergency transmission and result in longer delay.

Figure 6

Multiple emergency alarms occur in a same superframe with EGTS.

Figure 7

Multiple emergency alarms occur in a same superframe group.

4. Performance Evaluation

EGTS is too expensive for low data rate emergency data. If EGTS rate factor is high and emergency alarm message rate is low then amount of wasted bandwidth will be increased, because for most of the time, devices do not use allocated EGTS slots. To reduce overhead of unused EGTSs, we need to adapt ETGS rate factor while keeping the regulation of guaranteed low latency for emergency data.

There are two types of EGTS rate factor: superrate and subrate. The rate shows how many superframes may have at least one EGTS. For example, when EGTS rate is superrate of 4, it means one EGTS is enough during 4 superframes so as to meet the emergency latency requirement. When EGTS rate is subrate of 1/2, it means that one superframe must contain at least two EGTSs to meet the requirement. EGTS rate factor, Rate_EGTS, is obtained by

(1)

where BI is beacon interval, is guaranteed low latency, and is the number of emergency occurrences during a superframe group.

In HBC-MAC, suggested length of BI is 62 ms. But it may be varied according to the physical condition or the need of applications. As it gets longer (e.g., 3 sec), the principle has to be changed from the superrate to the subrate. We showed the breakpoints of EGTS superrate and subrate in Table 1.

Table 1 Breakpoint of EGTS superrate to subrate.

Actually, required EGTS rate factor, Req_EGTS, depends on the emergency rate. It is calculated as follows:

(2)

where is the emergency rate showing how many alarms happen in an unit time. This emergency rate is very low. It may occur once a week, once a month, and so on.

Based on the slot time, we can calculate the overhead time. So is calculated as follows:

(3)

5. Performance Analysis

5.1. Simulation Parameters and Assumptions

In this work, we considered only periodic and real-time short emergency alarm message. We considered only one EGTS enough for whole emergency data transmission. Also we assumed that the maximum number of nodes which make emergency alarms simultaneously is 5. Simulation parameters are shown in Table 2.

Table 2 Simulation parameters.

5.2. Result Analysis

Figure 8 shows EGTS superrate and subrate factor to satisfy emergency requirement. For example, in the case that only one emergency occurs with BI of 62 ms, to allocate one EGTS per 17 superframes is enough to meet the emergency requirements. When 5 emergencies occur during operation with BI of 3000 ms, we can see that every superframe must include 15 EGTSs to satisfy the emergency requirement.

Figure 8

EGTS superrate and subrate factor by traffic.

Required EGTS subrate and superrate factor based on the emergency rate condition is shown in Figure 9. If the emergency traffic rate decreases or multiple emergencies do not happen frequently, then EGTS rate factor should be higher. In this case, wastage bandwidth increases, therefore overhead time of unused EGTSs increases, as shown in Figure 10.

Figure 9

Required EGTS rate factor by emergency traffic condition with BI = 62 ms.

Figure 10

Overhead time of unused EGTS with BI = 62 ms.

6. Conclusion

The existing concept of operation and superframe structure of IEEE 802.15.4 or IEEE 802.15.6 cannot be directly applied to emergency data handling in HBC-MAC protocol due to the lack of CS capability in HBC.

In this work, we proposed a specific emergency handling operation for HBC-MAC using EGTS to meet the emergency requirements from IEEE 802.15.6 BAN. Because EGTS is too expensive and wasteful for the low data rate emergency, we showed the adequate number of emergency slots to reduce overhead. We formulated ETGS rate factor according to the guaranteed low latency of emergency data.