6Lo Working Group Hong, Choong Seon Internet-Draft Kyung Hee University Intended status: Standards Track Al Ameen, M. Expires: September 15, 2016 Kyung Hee University Seung Il Moon Kyung Hee University April 19, 2016 Emergency Communication for Low Energy Body-Centric Wearable Networks draft-hongcs-6lo-bcwc-00 Abstract Wearable devices are among the core technologies for Internet of Things (IoT). Recent advances in wireless communication devices have made it possible to create a wearable network in and around the human body. Such a network can be used for diverse applications such as monitoring human body activities and personal entertainments. A typical wearable device runs on battery power, which is limited and often non-rechargeable. Therefore, a low energy operation environment is desirable. Emergency traffic management is an important aspect of such a network. This document describes how an out-of-bound external wake up based on on-demand mechanism can work to successfully transmit emergency traffic in a typical body-centric wearable network (BC-WN). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 15, 2016. Copyright Notice Hong, et al. Expires Sept 15, 2016 [Page 1] Internet-Draft Low Energy BN-WN April 2016 Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . .. . . . . . 3 1.1. Terminology and Requirements Language . . . . . . . . . 3 2. Emergency Communication . . . . . . . . . . . . . . . . . . . . 3 2.1. Communication process . . . . . .. . . . . . . . . .. . 4 2.2. Data communication . . . . . . . . . . . . . . .. . . . 4 2.3. Network setup . . . . . . . . . . . . . . . . . . . . . 5 2.4. Packets . . . . . . . . . . . . . . . . . . . . . . . 6 3. Low Energy Operation . . . . . . . . . . . . . . . . . . . . . 7 3.1 On-demand communication with addressing . . . . . . . . . 7 3.2. MAC operation and back-off . . . . . . . . . . . . . . . .9 4. IANA Considerations . . . . . . .. . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . .10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . .10 6.1. Normative References . . . . . . . . . . . . . . . . . . . . .10 6.2. Informative References . . . . . .. . . . . . . . . . . . . .10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . .. . . . 11 Hong, et al. Expires Sept 15, 2016 [Page 2] Internet-Draft Low Energy BN-WN April 2016 1. Introduction In recent times, the design and implementation of wearable systems are on the rise. They are being actively used in both medical and non-medical applications. A network of such devices can be formed to monitor activities in and around the human body. However, the devices usually have limited processing, battery, and memory capacity. Energy efficiency and low delay are among the major design issues. To save energy, a device is put into sleep mode when not in use. This means the main radio is turned off. It is turned on when there is a need for communication. Managing this sleep and wake up mechanism is a delicate affair. It can be managed through scheduling. Periodic scheduling of sleep/wake up is easier to implement. Emergency communication is an important aspect of such a wearable network. If device wants to transmit emergency data to another device, which is turned off, an on-demand scheme can be used to successfully transmit it in an unscheduled mode. Since in such a scenario, a device does not periodically wake up to check the medium for packets, a sender can use an external trigger mechanism to wake up a sleeping device to communicate. RFC4944 [RFC4944] specifies the transmission of IPv6 over IEEE802.15.4. The BC-WN in many respects has similar characteristics to that of IEEE802.15.4. This document specifies the details of a system to manage an emergency event in wearable device communication in an efficient manner. 1.1. Terminology and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document is in part inspired by [IEEE802-2011]. 2. Emergency Communication Emergency events can occur due to several reasons. It may happen in any of the devices including the network controller. For example, a device can sense abnormality in the sensing data. It can also sense that the battery is dying. The Controller may face critical problems during its operation. It may also require sudden data from a device, which is currently in the sleep state. All of these can be classified as an emergency or urgent task. The tasks can be medical health related or non-medical in nature. The handling of the emergency event is a very sensitive issue in a BAN. The delay must be as low as possible to handle such situations. Hong, et al. Expires Sept 15, 2016 [Page 3] Internet-Draft Low Energy BN-WN April 2016 2.1. Communication Process A wake up process is handled using the wake up radio. A two-stage communication process is used as shown in Figure 1. In stage-1, the wake up radio is switched on. Once the receiver node verifies itself as the intended receiver, it transmits back an acknowledgment to the sender using the same channel. In stage-2, the main radio transceivers are triggered on for data communication. +------------+ +------------+ | Sender | | Receiver | +------------+ +------------+ | | ,| | || +------------------+ | Stage-1 || | wake up radio | | || | process | | || +------------------+ | `| | | | ------------------------------ | | | | | +------------------+ |` | |Data communication| || Stage -2 | | process | || | +------------------+ |, | | | | | | Figure 1: Communication process 2.2. Data communication An example of the emergency communication process is shown in Figure 2. In the first case, the case of an emergency wake up command (emergency alarm) packet is depicted. This process is completed in stage-1 itself. It can be used to notify about emergency types, which the receiver (controller) can know by looking into predefined information in the wake up packet. Hong, et al. Expires Sept 15, 2016 [Page 4] Internet-Draft Low Energy BN-WN April 2016 The emergency command is a short wake up frame (SWUF). The sender then waits for the wake up acknowledgment (WACK) timeout period. It retransmits the command if no WACK is received. The process continues until successful. The second case depicts an on-demand data communication process. In this case, the wake up process is followed by the data communication process and ends with an acknowledgment(ACK). +----------+ +--------+ +----------+ +--------+ |Controller| | Device | |Controller| | Device | +----------+ +--------+ +----------+ +--------+ | | | | | |<--Device Sleeping-->| | | | | | | |<--Device wakes up-->| | |wake up radio| |wake up radio| |<------------| |<------------| | WACK | | WACK | |------------>| |------------>| | | | Data | | | |<----------- | | | | ACK | | | |------------>| | | | | | | | | (a) (b) Figure 2: Communication (a) Without data, (b) with data 2.3 Network setup A star topology is used as shown in Figure 3. (Device a)----+ +----(Device x) \ / (Device b)------+( Controller )+-------(Device y) / \ (Device c)-----+ +----(Device z) Figure 3: BC-WN Star topology All the devices in the network MUST be equipped with antennae for the wake up radio and data communication. A device is capable of both receiving and sending the wake up radio signal. It remains in the sleep state until either an event triggers it on or it is woken up by external radio signal. Hong, et al. Expires Sept 15, 2016 [Page 5] Internet-Draft Low Energy BN-WN April 2016 2.4. Packets A typical wake up packet uses the address of a node as shown in Figure 4. The fields in the wake up packets are - frame header, address, payload and frame check sequence (FCS) using the cyclic redundancy code (CRC) algorithm. The frame header contains a preamble and start frame delimiter (SFD). They help against miss and false detection and provide synchronization. Node address or ID is used to identify the intended receiver. The payload contains information about the events. +---------+---------+-----------+-------+ | Frame |Address | Payload | CRC | | Header | | | | +---------+---------+-----------+-------+ Figure 4: Wake up packet Other MAC frames used are shown in Figure 5. A 'More Data' field is used for multiple packets transmission. One bit is used to depict simple yes/no for more data packets. The final packet size depends on the payload field. The physical (PHY) layer packet properties are similar to the IEEE802.15.4 channel model. 48 variable 26 bits +---------+----------+-------+ | MAC | Payload | FCS | | Header | | CRC) | +---------+----------+-------+ (a) 16 8 16 1 7 bits +---------+---------+----------+----------+----------+ | Frame |Sequence | Address | More Data|Reserved | | Control |Number | | | | +---------+---------+----------+----------+----------+ (b) 16 8 16 bits +---------+---------+-------+ | Frame |Sequence | CRC | | Header |Number | | +---------+---------+-------+ (c) Figure 5: MAC frames (a) MAC, (b) Header, (c) Acknowledgment Hong, et al. Expires Sept 15, 2016 [Page 6] Internet-Draft Low Energy BN-WN April 2016 3. Low Energy Operation A BC-WN uses a low power wake up radio for prompt communication. There is a lack of a satisfactory means to communicate immediately in current protocols and delay is a major issue. This is also true in the case of the IEEE15.4x standard protocols. A wake up radio based system through the on-demand request can significantly reduce the idle state energy consumption. A typical wearable network has 1 to 10m coverage area. In addition, there is only a very limited impact on latency because the corresponding device wakes up immediately. Wake up radios operate at very low power mode. The wake up radio based MAC takes advantage of a typical BC-WN as follows: - smaller network size in terms of devices compared to typical sensor networks; - limited communication range; - a device can be easily triggered on by external wake up radio signal; - wake up radio puts little extra cost in terms of power consumption. 3.1 On-demand communication with addressing Addressing is an important factor in the wake up radio. It is used for selective communication. A flow chart of a typical wake up radio based system using addressing is shown in Figure 6. It is to be noted that energy is consumed to decode a wake up packet to determine the recipient. Addressing can reduce the waking up of all the nodes in the neighborhood with a slight increase in the complexity. Hong, et al. Expires Sept 15, 2016 [Page 7] Internet-Draft Low Energy BN-WN April 2016 +----------------------+ +----------------->| Device sleeping | | | (Main radio OFF) | | +----------------------+ | | | | | v | /\ | / \ | / \ | No /Packet\ |<--------------------------/detected\ | \ / | \ / | \ / | \ / | \/ | |Yes | v | +--------------------------+ | | | | | Decode Wakeup Packet | | | | | +--------------------------+ | | | v | / \ | / \ | / \ | / \ | No /Broadcast\ | +-------------- \ Packet / | | \ / | v \ / | / \ \ / | / \ \ / | / \ | | No /Address\ | +-------\ to me?/ |Yes \ / | \ / | \ / v | +----------------------------+ Yes| | | +---->| Wake up the Main Radio | | | +----------------------------+ | v (End) Figure 6: Flow chart of wake up radio with addressing Hong, et al. Expires Sept 15, 2016 [Page 8] Internet-Draft Low Energy BN-WN April 2016 3.2. MAC Operation and back-off A slotted contention based mechanism is used for communication. An example MAC operation is shown in Figure 7. A device with an emergency event uses channel sensing to check the channel for activity. It also uses the back-off mechanism to avoid the collision. It uses single clear channel assessment (CCA) unlike the IEEE802.15.4. +---------+---------+ +---------+---------+ | | WACK | | | WACK | Controller | | | | | | -----------------+---------+---------+---------+---------+------------> +---------+ +---------+ |Collision| |Success | | | | | ^ +---------+ +---------+ | +---------+---------+--------+---------+---------+---------+ | Back-off| Wake up | | Back-off| Wake up | | Device | Radio | | | Radio | | | -------+---------+---------+--------+---------+----------------------> Figure 7: MAC operation and back-off Before attempting to transmit, a device utilizes the back-off mechanism. It chooses the value from the range (0, B), where the back-off window size (B) can be fixed or adapted as per the application requirements. The value it chooses is called the back-off counter. It is expressed in terms of slots. The counter value is decremented one slot at a time. For example, if it chooses a back-off value of 3, it waits for 3 slots before reattempting to transmit the packet. Once the counter expires, it senses the channel. If the channel is idle, it transmits the wake up radio packet. If it senses the channel busy, it chooses a new value for the Counter and the process is repeated. 4. IANA Considerations There are no IANA considerations related to this document. Hong, et al. Expires Sept 15, 2016 [Page 9] Internet-Draft Low Energy BN-WN April 2016 5. Security Considerations BC-WN has similar requirements of security as in the IEEE802.15.4. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. 6.2. Informative References [IEEE802-2011] Institute of Electrical and Electronics Engineers (IEEE), IEEE Standard for Local and metropolitan area networks Part 15.4:Low-Rate Wireless Personal Area Networks LR-WPANs), 2011. Hong, et al. Expires Sept 15, 2016 [Page 10] Internet-Draft Low Energy BN-WN April 2016 Authors' Addresses Choong Seon Hong Computer Science and Engineering Department, Kyung Hee University Yongin, South Korea Phone: +82 (0)31 201 2532 Email: cshong@khu.ac.kr Al Ameen, M. Computer Science and Engineering Department, Kyung Hee University Yongin, South Korea Phone: +82 (0)31 201 2987 Email: ameen@khu.ac.kr Seung Il Moon Computer Science and Engineering Department, Kyung Hee University Yongin, South Korea Phone: +82 (0)31 201 2987 Email: moons85@khu.ac.kr Hong, et al. Expires Sept 15, 2016 [Page 11]