Internet DRAFT - draft-sajjad-6lo-wban
draft-sajjad-6lo-wban
6Lo Working Group MS. Akbar
Internet-Draft Bournemouth University
Intended status: Informational AR. Sangi
Expires: October 30, 2018 Huaiyin Institute of Technology
M. Zhang
J. Hou
Huawei Technologies
C. Perkins
Futurewei
A. Petrescu
CEA, LIST
R.N.B.Rais
Ajman University
April 30, 2018
Transmission of IPv6 Packets over Wireless Body Area Networks (WBANs)
draft-sajjad-6lo-wban-02
Abstract
Wireless Body Area Networks (WBANs) intend to facilitate use cases
related to medical field. IEEE 802.15.6 defines PHY and MAC layer
and is designed to deal with better penetration through the human
tissue without creating any damage to human tissues with the approved
MICS (Medical Implant Communication Service) band by USA Federal
Communications Commission (FCC). Devices of WBANs conform to this
IEEE standard.
This specification defines details to enable transmission of IPv6
packets, method of forming link-local and statelessly autoconfigured
IPv6 addresses on WBANs.
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 https://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."
Akbar, et al. Expires October 30, 2018 [Page 1]
Internet-Draft IPv6 over WBANs April 2018
This Internet-Draft will expire on October 30, 2018.
Copyright Notice
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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Frame Format and Addressing Modes . . . . . . . . . . . . 3
1.2. Why 6lo is required for IEEE 802.15.6 . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Topology and Scope of Communication . . . . . . . . . . . . . 5
4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 6
5. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 7
6. Specification of IPv6 over WBAN . . . . . . . . . . . . . . . 7
6.1. Stateless Address Autoconfiguration . . . . . . . . . . . 8
6.2. IPv6 Link-Local Address . . . . . . . . . . . . . . . . . 8
6.3. Unicast and Multicast Address Mapping . . . . . . . . . . 8
6.4. Header Compression . . . . . . . . . . . . . . . . . . . 9
6.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security and Privacy Considerations . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Patient monitoring use case - Spoke Hub . . . . . . 11
Appendix B. Patient monitoring use case - Connected . . . . . . 13
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Wireless Body Area Networks (WBANs) are comprised of devices that
conform to the [IEEE802.15.6], standard by the IEEE. IEEE 802.15.6
provides specification for the MAC layer to access the channel. The
coordinator divides the channel into superframe time structures to
Akbar, et al. Expires October 30, 2018 [Page 2]
Internet-Draft IPv6 over WBANs April 2018
allocate resources [SURVEY-WBAN] [MAC-WBAN]. Superframes are bounded
by equal length beacons through the coordinator. Usually beacons are
sent at beacon periods except inactive superframes or limited by
regulation.
Task group for 802.15.6 was established by IEEE in November 2007 for
standardisation of WBANs and it was approved in 2012. This standard
works in and around human body and focus on operating at lower
frequencies and short range. The focus of this document is to design
a communication standard for MAC and physical layer to support
different applications, namely, medical and no-medical applications.
Medical applications refer to collection of vital information in real
time (monitoring) for diagnoses and treatment of various diseases
with help of different sensors (accelerometer, temperature, BP and
EMG etc.). It defines a MAC layer that can operate with three
different PHY layers i.e. human body communication (HBC), ultra-
wideband (UWB) and Narrowband (NB). IEEE 802.15.6 provides
specification for MAC layer to access the channel. The coordinator
divides the channel into superframe time structures to allocate
resources. Superframes are bounded by equal length beacons through
coordinator. The purpose of the draft is to highlight the need of
IEEE 802.15.6 for WBASNs and its integration issues while connecting
it with IPv6 network. The use cases are provided to elaborate the
scenarios with implantable and wearable biomedical sensors. 6lowpan
provides IPv6 connectivity for IEEE 802.15.4; however, it does not
work with IEEE 802.15.6 due to the difference in frame format in
terms of size and composition.
1.1. Frame Format and Addressing Modes
Figure 1 shows the general MAC frame format consisting of a 56-bit
header, variable length frame body, and 18-bit FrameCheck Sequence
(FCS). The maximum length of the frame body is 255 octets. The MAC
header further consists of 32-bit frame control, 8-bit recipient
Identification (ID), 8-bit sender ID, and 8-bit WBAN ID fields. The
frame control field carries control information including the type of
frame, that is, beacon, acknowledgement, or other control frames.
The recipient and sender ID fields contain the address information of
the recipient and the sender of the data frame, respectively. The
WBAN ID contains information on the WBAN in which the transmission is
active. The first 8-bit field in the MAC frame body carries message
freshness information required for nonce construction and replay
detection. The frame payload field carries data frames, and the last
32-bit Message Integrity Code (MIC) carries information about the
authenticity and integrity of the frame. The IEEE 802.15.6 standard
supports two kinds of addresses:
Akbar, et al. Expires October 30, 2018 [Page 3]
Internet-Draft IPv6 over WBANs April 2018
1. 8-bit short address, which is the sender ID. This address is
located in the MAC header used for communication.
2. 48-bit EUI-48 address, which is used for the association process.
For some certain frame types, e.g. Security Association frames,
this MAC address exists inside the MAC payload, for the node
joining process.
Octets 7 0-255 2
+--------+------------------+--------+
| MAC | MAC frame body | |
| header |Variable length: | FCS |
| | 0-255 bytes | |
+--------+------------------+--------+
<--MHR--><--------X--------><---FTR-->
/ \
/ \
/ \
+---------+------------+-------------+--------------+
| Frame | Recipient | Sender | Ban |
| control | ID | ID | ID |
+---------+------------+-------------+--------------+
Octets <---4----><-----1-----><------1-----><-------1------>
Figure 1: The general MAC frame format of IEEE 802.15.6
1.2. Why 6lo is required for IEEE 802.15.6
Based on the characteristics defined in the overview section, the
following sections elaborate on the main problems with IP for WBANs.
The requirement for IPv6 connectivity within WBANs is driven by the
following:
o The number of devices in WBANs makes network auto configuration
and statelessness highly desirable. And for this, IPv6 has
(default auto-configuration as a) ready solutions.
o The large number of devices poses the need for a large address
space, moreover a WBAN may consist of 256 nodes maximum and IPv6
is helpful to solve this address space limitation.
o Given the limited packet size of WBANs, the IPv6 address format
allows subsuming of IEEE 802.15.6 addresses if so desired.
Applications within WBANs are expected to originate small packets.
Adding all layers for IP connectivity should still allow
transmission in one frame, without incurring excessive
fragmentation and reassembly. Furthermore, protocols must be
Akbar, et al. Expires October 30, 2018 [Page 4]
Internet-Draft IPv6 over WBANs April 2018
designed or chosen so that the individual "control/protocol
packets" fit within a single 802.15.6 frame. Along these lines,
IPv6's requirement of sub-IP reassembly may pose challenges for
low-end WBANs healthcare devices that do not have enough RAM or
storage for a 1280-octet packet [RFC2460].
o Simple interconnectivity to other IP networks including the
Internet.
o However, given the limited packet size, headers for IPv6 and
layers above must be compressed whenever possible.
2. Conventions and Terminology
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 [RFC2119].
3. Topology and Scope of Communication
This is a standard for short-range, wireless communication in the
vicinity of, or inside, a human body (but not limited to humans). It
uses existing industrial scientific medical (ISM) bands as well as
frequency bands approved by national medical and/or regulatory
authorities. Support for quality of service (QoS), extremely low
power, and data rates from 10Kbps to 10 Mbps is required while
simultaneously complying with strict non-interference guidelines
where needed. The Table 1 shows a comparison of WBAN and other
available technologies in terms of data rate and power consumption.
Akbar, et al. Expires October 30, 2018 [Page 5]
Internet-Draft IPv6 over WBANs April 2018
+----------------+---------------+-----------------+----------------+
| Standard | Provided data | Power | Battery |
| | rate | requirement | lifetime |
+----------------+---------------+-----------------+----------------+
| 802.11 ac | 700 Mbps | 100 mW - 1000 | Hours - days |
| (WiFi) | | mW | |
| | | | |
| Bluetooth | 1Mbps - 10 | 4 mW - 100 mW | Days - weeks |
| | Mbps | | |
| | | | |
| Wibree | 600 Kbps | 2 mW - 10 mW | Weeks - months |
| | maximum | | |
| | | | |
| ZigBee | 250 Kbps | 3 mW - 10 mW | Weeks - months |
| | | | |
| 802.15.4 | 250 Kbps | 3 mW - 10 mW | Weeks - months |
| | maximum | | |
| | | | |
| 802.15.6 | 1Kbps - 10 | 0.1 mW - 2 mW | Months - years |
| | Mbps | | |
+----------------+---------------+-----------------+----------------+
Table 1: Comparison of WBAN
Data rates, typically up to 10Mbps, can be offered to satisfy an
evolutionary set of entertainment and healthcare services. Current
personal area networks (PANs) do not meet the medical (proximity to
human tissue) and relevant communication regulations for some
application environments. They also do not support the combination
of reliability, QoS, low power, data rate, and non-interference
required to broadly address the breadth of body area network (BAN)
applications.
The IEEE 802.15.6 working group has considered WBANs to operate in
either a one-hop or two-hop star topology with the node in the centre
of the star being placed on a location like the waist. Two feasible
types of data transmission exist in the one-hop star topology:
transmission from the device to the coordinator and transmission from
the coordinator to the device. The communication methods that exist
in the star topology are beacon mode and non-beacon mode. In a two-
hop start WBAN, a relay-capable node may be used to exchange data
frames between a node and the hub.
4. Protocol Stack
The IPv6 over IEEE 802.15.6 protocol stack is presented in Figure 2.
It contains six elements from bottom to top including IEEE 802.15.6
PHY layer, IEEE 802.15.6 MAC layer, Adaptation layer for IPv6 over
Akbar, et al. Expires October 30, 2018 [Page 6]
Internet-Draft IPv6 over WBANs April 2018
IEEE 802.15.6, IPv6 layer, TCP/UDP layer and Application layer.The
adaptation layer supports the mechanisms like stateless address auto-
configuration, header compression and fragmentation and reassembly.
+----------------------------------------+
| Application Layer |
+----------------------------------------+
| TCP/UDP |
+----------------------------------------+
| |
| IPv6 |
| |
+----------------------------------------+
| Adaptation layer for IPv6 over 802.15.6|
+----------------------------------------+
| MAC Layer |
| (IEEE 802.15.6) |
+----------------------------------------+
| PHY Layer |
| (IEEE 802.15.6) |
+----------------------------------------+
Figure 2: Protocol stack for IPv6 over IEEE 802.15.4
5. Maximum Transmission Unit (MTU)
The IPv6 packets have the MTU of 1280 octects and its expects from
every link layer to send data by following this MTU or greater. Thus
maximum Transmission Unit (MTU) of MAC layer describes the
implementation of fragmentation and reassembly mechanism for the
adaption IPv6 layer over IEEE 802.15.6.
The IEEE 802.15.6 has the MTU of 256 octects, if we consider link
layer security overhead (16 octects for AES-128) leaves 240 octects
which is not sufficient to complete a IPv6 packet.Therefore, an
adaption layer below IP layer is required to manage fragmentation and
reassembly issues.
6. Specification of IPv6 over WBAN
Due to stringent QoS requirements in WBAN, a 6lo adaption layer is
needed to support the transmission of IPv6 packets.6 LoWPAN standards
[RFC4944], [RFC6775] and [RFC6282] provides useful information
including link-local IPv6 address,stateless address auto-
configuration, unicast and multicast address mapping,header
compression and fragmentation and reassembly. These standards are
reffered in the specifications of 6lo adaptation layer which is
illustrated in the following following subsections:
Akbar, et al. Expires October 30, 2018 [Page 7]
Internet-Draft IPv6 over WBANs April 2018
6.1. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 Interface Identifier.
This specification distinguishes between two types of IIDs, MAC-
address-derived and semantically opaque.
IPv6 addresses may be autoconfigured from IIDs that may again be
constructed from link-layer address information to save memory in
devices and to facilitate efficient IP header compression as per
[RFC6282]. The 64-bit IID for link-local address SHALL be derived by
utilizing 8-bit node address and 8-bit BAN ID (part of MAC header) as
follows:
IID: 0x0000:00FF:FE00:YYXX
Where YY is the BAN ID, XX is the node address. As this generated
IID is not golbally unique, the "Universal/Local" (U/L) bit (7th bit)
SHALL be set to zero. The use of BAN ID and node address guarantees
the uniqueness of an IID inside a WBAN network. Note that this MAC-
address-derived IID varies when a node changes connection from one
BAN coordinator to another.
Considering the privacy issue mentioned in section 8, a semantically
opaque IID having 64 bits of entropy is RECOMMENDED for each globally
scoped address and MAY be locally generated according to the method
introduced in [RFC7217]
6.2. IPv6 Link-Local Address
The IPv6 link-local address [RFC4291] for an IEEE 802.15.6 interface
is generated by appending the interface identifier to the prefix
FE80::/64.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 3: IPv6 Link Local Address in IEEE 802.15.6
6.3. Unicast and Multicast Address Mapping
The address resolution procedure for mapping IPv6 unicast addresses
into IEEE 802.15.6 link-layer addresses follows the general
description in section 7.2 of [RFC4861], unless otherwise specified.
Multicast address mapping is not supported in IEEE 802.15.6.
Akbar, et al. Expires October 30, 2018 [Page 8]
Internet-Draft IPv6 over WBANs April 2018
6.4. Header Compression
The IEEE 802.15.6 PHY layer supports a maximum PSDU (PHY Service Data
Unit) of 256 octets. Because of the limited PHY payload, header
compression at 6lo adaptation layer is of great importance and MUST
be applied. The compression of IPv6 datagrams within IEEE 802.15.6
frames refers to [RFC6282], which updates [RFC4944].Multiple header
compression stacks are defined in RFC6282 which specifies the
fragmentation methods for IPv6 datagrams on top of IEEE
802.15.4;however, for IEEE 802.15.6, a LoWPAN encapsulated LoWPAN_HC1
compressed IPv6 datagram can be used as IEEE 802.15.6 does not
require mesh header due to IEEE 802.15.6 communication
scope.Moreover, static header compression techniques of [RFC7400] can
also be used as header compression.
6.5. Fragmentation and Reassembly
IEEE 802.15.6 provides Fragmentation and reassembly (FAR) for payload
of 256 bytes. FAR as defined in [RFC4944], which specifies the
fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4 MUST
be adapted to work with IEEE 802.15.6. All headers MUST be
compressed according to [RFC4944] encoding formats, but the default
MTU of IEEE 802.15.6 is 256 bytes which MUST be considered.
7. IANA Considerations
[TBD]
8. Security and Privacy Considerations
IPv6 over WBAN's applications often require confidentiality and
integrity protection. This can be provided at the application,
transport, network, and/or at the link. IEEE 802.15.6 considers the
security as a key requirement for healthcare applications and defines
a complete framework. This framework defines three levels of
security which can be used according to requirements. Overall, it
covers privacy, confidentiality, encryption and authentication.
AES-64 is preffered for encryption due to its efficiency.
IP addresses may be used to track devices on the Internet; such
devices can in turn be linked to individuals and their activities.
Depending on the application and the actual use pattern, this may be
undesirable. To impede tracking, globally unique and non-changing
characteristics of IP addresses should be avoided, e.g., by
frequently changing the global prefix and avoiding unique link-layer-
derived IIDs in addresses. For this concern, a 64-bit semantically
opaque IID is RECOMMENDED to be generated for global communication.
The MAC-address-derived IID, when used for global communication,
Akbar, et al. Expires October 30, 2018 [Page 9]
Internet-Draft IPv6 over WBANs April 2018
should be evaluated based on the using scenario in order to guarantee
a short enough lifetime according to [RFC8065].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
Akbar, et al. Expires October 30, 2018 [Page 10]
Internet-Draft IPv6 over WBANs April 2018
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>.
9.2. Informative References
[IEEE802.15.6]
"IEEE Standard, 802.15.6-2012 - IEEE Standard for Local
and metropolitan area networks - Part 15.6: Wireless Body
Area Networks", 2012,
<https://standards.ieee.org/findstds/
standard/802.15.6-2012.html>.
[SURVEY-WBAN]
Diffie, W., Samaneh Movassaghi, Mehran Abolhasan, Justin
Lipman, David Smith, and Abbas Jamalipour, "Wireless body
area networks: A survey", Communications Surveys and
Tutorials, IEEE , vol. 16, no. 3, pp. 1658-1686, 2014.
[MAC-WBAN]
Minglei Shu, Dongfeng Yuan, Chongqing Zhang, Yinglong
Wang, and Changfang Chen, "A MAC Protocol for Medical
Monitoring Applications of Wireless Body Area Networks.",
Sensors , vol. 15, no. 6, 2015.
Appendix A. Patient monitoring use case - Spoke Hub
Refer following diagram:
Akbar, et al. Expires October 30, 2018 [Page 11]
Internet-Draft IPv6 over WBANs April 2018
########
# @ EEG #
## | @ # Hearing
# | | #
# | |#
# | #|
##### | |## ###
# | | @ ## Motion Sensor
Positioning# @ | / / #
# \ |ECG / / #
# \ | @ | / #
# \ | / / / #
# ## \ |/ // ## #
# ## \ ||// ## #
# # # \ |||| # # @ # BP
# # # \|||| # # / ##
# ## # |||| # #/ ##
SPO2# @ ## # Coordinator # /## #
# \ ## ## +-+ / ## ##
# ------+--------| |-------/ # # #
## ## # +-+ ## # ##
## ## # //\ # # ##
### # # // \ # ## ###
## # # // \ # # ## ##
# # # // \ # # #
### # # # // ## \ # # ###
# ### # // # # \ # # # ###
### # // # # | # # ###
# // # ## | #
Glucose Sensor # @ / # # | #
## | ## # | #
# / # # | #
#/ # # | #
Emg#@ # # | #
# # ## | #
## # | #
# # # | #
# # #\ #
# # # | #
# # # @ # Motion Sensor
## # ## ##
## #
Figure 4: Patient monitoring use case - Spoke Hub
Akbar, et al. Expires October 30, 2018 [Page 12]
Internet-Draft IPv6 over WBANs April 2018
Appendix B. Patient monitoring use case - Connected
Refer following diagram:
########
# @ EEG #
## |\-----@ # Hearing
# | \#
# | # |
# | ## |Motion Sensor
####### | ##|####
# | | ##
Positioning# @ | @ #
# /\ ECG| \ #
# / \----------@ \ #
# / | #
# / ## ## | #
# / # # # # @ # BP
#/ ## # # ## | ##
SPO2# @ ## # # ## | #
# \ # # # #| #
## ## \ # ## | # ##
## # \ # # | # ## ##
### # # # \ ## # | # ###
# ### # \ # # # | # # ###
### # | # # # | # ###
# | # ## # |
Glucose Sensor # @ # # # |
# / # # # /
#| ## # #/
#/ # # #|
Emg#@ # # #|
# \ # # #|
# \ # # #|
# \# ## #|
## \ # #|
# #\ # #|
# # \ # #|
# # \ # #|
# # \ ## #/
# # \ ## /
# # \ ## /#
## # \ | #
# # # \/ #
# # # @ # Motion Sensor
## #
Figure 5: Patient monitoring use case - Connected
Akbar, et al. Expires October 30, 2018 [Page 13]
Internet-Draft IPv6 over WBANs April 2018
Appendix C. Changes
Compared with version-00, this updated draft is no longer all
informative. Two main changes have been made as below:
1. Introduction part of 802.15.6 is simplified and more focused on
the features that relates to the 6lo-WBAN adaptation layer, e.g.
MAC frame format including MAC address and MTU, topology and
scope of communication, and why the 6lo-WBAN adaptation layer is
needed.
2. The 6lo-WBAN adaptation layer is specified in this draft titled
as "Specification of IPv6 over WBAN" that lists the main features
needs to be added in the 6lo adaptation layer including the
formation of IID, IPv6 link-local address, unicast address
mapping, header compression, and fragmentation and reassembly.
These parts have never been mentioned in other documents related
to WBAN, and in this version, we provide a guidance for such IPv6
enabled WBAN implementations.
Authors' Addresses
Muhammad Sajjad Akbar
Bournemouth University
Fern Barrow, Dorset
Poole BH12 5BB
United Kingdom
Email: makbar@bournemouth.ac.uk
Abdur Rashid Sangi
Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District
Huaian 223001
P.R. China
Email: sangi_bahrian@yahoo.com
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: zhangmingui@huawei.com
Akbar, et al. Expires October 30, 2018 [Page 14]
Internet-Draft IPv6 over WBANs April 2018
Jianqiang Hou
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86 15852944235
Email: houjianqiang@huawei.com
Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara 95050
Unites States
Email: charliep@computer.org
Alexandre Petrescu
CEA, LIST
CEA Saclay
Gif-sur-Yvette, Ile-de-France 91190
France
Phone: +33169089223
Email: alexandre.petrescu@cea.fr
Naveed Bin Rais
Ajman University
University Street,Al jerf 1
Ajman 346
United Arab Emirates
Email: naveedbinrais@gmail.com
Akbar, et al. Expires October 30, 2018 [Page 15]
