6Lo Working Group Hong, Choong Seon Internet-Draft Kyung Hee University Intended status: Standards Track Al Ameen, M. Expires: August 09, 2018 Kyung Hee University Seung Il Moon Kyung Hee University Feb 09, 2018 Scheduling to Increase Lifetime for Low Energy Body-Centric Wearable Networks draft-hongcs-6lo-sbcn-00 Abstract Recent advances in Internet of Things(IoT) have increased the usage of sensing technologies. Breakthroughs is microelectronics have increased the use of wearable devices to monitor human body functions and its surroundings. A typical wearable device has low resources in terms of power and processing capabilities. Reducing the energy consumption is one of the key design factors in a wearable network so that the devices may work for longer duration. Idle listening and overhearing are major causes of energy consumption. These issues can be resolved by maximizing the sleeping time of a device (switched off) and avoid unnecessary wakeup time (idle listening) to save energy. An external wakeup scheduling to handle the sleep/wakeup cycle of a device can be adapted. This document describes how a 2wakeup scheduling using an out-of-bound external wake up mechanism can work to successfully increase the lifetime of a typical body-centric wearable network (S-BCN). 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 July 19, 2018. Copyright Notice Hong, et al. Expires August 09, 2018 [Page 1] Internet-Draft Low Energy S-BCN February 2018 Copyright (c) 2018 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. Wake up Scheduling . . . . . . . . . . . . . . . . . . . . . . . 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 August 09, 2018 [Page 2] Internet-Draft Low Energy S-BCN February 2018 1. Introduction The wearable wireless sensor devices are nowadays becoming popular. A network of these devices can monitor the human body functions and its surroundings to provide efficient health and personal care. In a typical network, the receiver device must be switched on (awake) before the sender can transfer the packets. Due to this reason, a receiver spends extra time in the on state, which causes energy wastage. Sometimes, a device remains in the on state in anticipation of packets from a potential sender, which also causes energy wastage. The majority of the protocols use a sleep/wakeup scheduling to conserve energy. The schedule can be periodic or aperiodic. Wakeup scheduling is a major design issue in energy constrained networks. Current standardized protocols lack mechanisms to communicate if a device is not in the awake state at the time of communication. Therefore, in an event-based unscheduled packet transfer scenario, a sender must wait till the receiver device is awake causing delay and energy wastage. To resolve this issue, we propose an external radio triggered wakeup scheduling for a wearable network. In this model, a low cost, low power wakeup radio circuit is attached to a wearable device. 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. Wake up Scheduling An external radio to trigger on the receiver device as and when needed. This method can avoid periodic scheduling, which reduces energy wastage. In one cycle, a device spends time in the idle period and busy period. In the idle period, it sleeps and in the busy period it tries to transmit the packets. We have used a Wakeup Radio/Wakeup-ACK/Data/ACK operation. 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 August 09, 2018 [Page 3] Internet-Draft Low Energy S-BCN February 2018 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 The communication process is shown in Figure 2. The device sends a wake up radio packet to the receiver (controller). It waits for the wake up acknowledgment (WACK) timeout period. It retransmits the command if no WACK is received. Hong, et al. Expires August 09, 2018 [Page 4] Internet-Draft Low Energy S-BCN February 2018 Once the WACK packet is received, it transmits the data packet and waits for the acknowledgment (ACK). The retransmission continues till the process is sucessful. +----------+ +--------+ |Controller| | Device | +----------+ +--------+ | | | |<--Device Sleeping | | | |<--Device wakes up |wake up radio| |<------------| | WACK | |------------>| | Data | |<------------| | WACK | |------------>| | | | | (a) Figure 2: Data communication 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: S-BCN Star topology All the devices in the network MUST be equipped with wake up radio antennae. A device is capable of both receiving and sending the wake up radio signal. It remains in the sleep state until either an e vent triggers it on or it is woken up by external radio signal. Hong, et al. Expires July 19, 2018 [Page 5] Internet-Draft Low Energy S-BCN January 2018 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 August 09, 2018 [Page 6] Internet-Draft Low Energy S-BCN February 2018 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 August 09, 2018 [Page 7] Internet-Draft Low Energy S-BCN February 2018 +----------------------+ +----------------->| 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 August 09, 2018 [Page 8] Internet-Draft Low Energy S-BCN February 2018 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 August 09, 2018 [Page 9] Internet-Draft Low Energy S-BCN February 2018 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 August 09, 2018 [Page 10] Internet-Draft Low Energy S-BCN February 2018 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 August 09, 2018 [Page 2]