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]