Internet DRAFT - draft-hongcs-6lo-bcwc
draft-hongcs-6lo-bcwc
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]
