idnits 2.17.1 draft-sajjad-6lo-wban-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 13, 2017) is 2509 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 525, but not defined == Unused Reference: 'RFC4944' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-6top-sf0' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'I-D.satish-6tisch-6top-sf1' is defined on line 562, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-05) exists of draft-ietf-6tisch-6top-sf0-02 == Outdated reference: A later version (-04) exists of draft-satish-6tisch-6top-sf1-02 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group MS. Akbar 3 Internet-Draft Bournemouth University 4 Intended status: Informational R. Bin Rais 5 Expires: December 15, 2017 Ajman University 6 AR. Sangi 7 Individual Contributor 8 M. Zhang 9 Huawei Technologies 10 C. Perkins 11 Futurewei 12 June 13, 2017 14 Transmission of IPv6 Packets over Wireless Body Area Networks (WBANs) 15 draft-sajjad-6lo-wban-00 17 Abstract 19 Wireless Body Area Networks (WBANs) intend to facilitate use cases 20 related to medical field. IEEE 802.15.6 defines PHY and MAC layer 21 and is designed to deal with better penetration through the human 22 tissue without creating any damage to human tissues with the approved 23 MICS (Medical Implant Communication Service) band by USA Federal 24 Communications Commission (FCC). Devices in WBANs conform to this 25 IEEE standard. 27 This specification defines details to enable transmission of IPv6 28 packets, method of forming link-local and statelessly autoconfigured 29 IPv6 addresses on WBANs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 15, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 67 3. Use cases for IEEE 802.15.6 . . . . . . . . . . . . . . . . . 3 68 3.1. Hospital Patient Monitoring . . . . . . . . . . . . . . . 3 69 3.2. Patient monitoring for Chronic Diseases . . . . . . . . . 5 70 3.3. Elderly Patient Monitoring . . . . . . . . . . . . . . . 5 71 4. Why 6lo is required for IEEE 802.15.6 . . . . . . . . . . . . 5 72 4.1. IPv6 Connectivity requirements . . . . . . . . . . . . . 5 73 4.2. Limited Packet Size . . . . . . . . . . . . . . . . . . . 6 74 4.3. Topology requirements . . . . . . . . . . . . . . . . . . 6 75 5. Scope/Purpose . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Layer 2 Overview . . . . . . . . . . . . . . . . . . . . . . 7 77 6.1. Frame format . . . . . . . . . . . . . . . . . . . . . . 8 78 6.2. Frequency bands . . . . . . . . . . . . . . . . . . . . . 8 79 6.3. Channel modes of IEEE 802.15.6 . . . . . . . . . . . . . 10 80 7. --IETF to standardize-- . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 11.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Appendix A. Patient monitoring use case - Spoke Hub . . . . . . 13 88 Appendix B. Patient monitoring use case - Connected . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 Wireless Body Area Networks (WBANs) are comprised of devices that 94 conform to the [IEEE802.15.6], standard by the IEEE. IEEE 802.15.6 95 provides specification for the MAC layer to access the channel. The 96 coordinator divides the channel into superframe time structures to 97 allocate resources [SURVEY-WBAN] [MAC-WBAN]. Superframes are bounded 98 by equal length beacons through the coordinator. Usually beacons are 99 sent at beacon periods except inactive superframes or limited by 100 regulation. This standard works under following three channel access 101 modes. 103 Task group for 802.15.6 was established by IEEE in November 2007 for 104 standardisation of WBANs and it was approved in 2012. This standard 105 works in and around human body and focus on operating at lower 106 frequencies and short range. The focus of this standard is to design 107 a communication standard for MAC and physical layer to support 108 different applications, namely, medical and no-medical applications. 109 Medical applications refer to collection of vital information in real 110 time (monitoring) for diagnoses and treatment of various diseases 111 with help of different sensors (accelerometer, temperature, BP and 112 EMG etc.). It defines a MAC layer that can operate with three 113 different PHY layers i.e. human body communication (HBC), ultra- 114 wideband (UWB) and Narrowband (NB). IEEE 802.15.6 provides 115 specification for MAC layer to access the channel. The coordinator 116 divides the channel into superframe time structures to allocate 117 resources. Superframes are bounded by equal length beacons through 118 coordinator. The purpose of the draft is to highlight the need of 119 IEEE 802.15.6 for WBASNs and its integration issues while connecting 120 it with IPv6 network. The use cases are provided to elaborate the 121 scenarios with implantable and wearable biomedical sensors. 6lowpan 122 provides IPv6 connectivity for IEEE 802.15.4; however, it will not 123 work with IEEE 802.15.6 due to the difference in frame format in 124 terms of size and composition. 126 2. Conventions and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. Use cases for IEEE 802.15.6 134 3.1. Hospital Patient Monitoring 136 In the hospital environment, several levels of patient monitoring 137 services are required as different patients needs different 138 monitoring services e.g., a patient in Intensive Care Unit (ICU) 139 requires high prioritized periodic data services with limited delay 140 and high throughput than the patient in a normal ward. Usually, a 141 patient is equipped with multiple sensors that measure vital signals 142 like heart activity, muscle movements, blood pressure, body oxygen 143 level and brain stimulation via integrated sensors i.e., 144 (Electrocardiography), BP (Blood Pressure) monitor, EMG 145 (Electromyography), pulse oximeter and EEG (Electroencephalography) 146 etc. These sensors are categorized as wearable and implantable 147 sensors, hence we are assuming that equipped sensors are mixture of 148 wearable and implantable sensors which creates restriction to use 149 IEEE 802.15.6 as it is designed to deal with better penetration 150 through the human tissue without creating any damage to human tissues 151 with the approved MICS band by USA Federal Communications Commission 152 (FCC). In a hospital use case scenario, the initial data generated 153 by numerous biomedical sensor nodes is collected by a central 154 coordinator. 156 In this case, Table 3 presents the summary of traffic patterns for 157 different biomedical sensor nodes attached to human body with data 158 generation rate, required data rate from channel and QoS 159 requirements. 161 +----------+----------+---------+-----------+-----------+-----------+ 162 | Sensor | Data Gen | Require | Delay Req | Power Con | Reliabili | 163 | Nodes | eration | d Data | uirement | sumption | ty Requir | 164 | | Interval | Rate | | | ement | 165 | | | (Kbps) | | | | 166 +----------+----------+---------+-----------+-----------+-----------+ 167 | ECG | 4 ms | 34 | <125ms | Low | High | 168 | | | | | | | 169 | EMG | 6 ms | 19.6 | <125ms | Low | High | 170 | | | | | | | 171 | EEG | 4 ms | 19.6 | <125ms | Low | High | 172 | | | | | | | 173 | SpO2 | 10 ms | 13.2 | <250ms | Low | Medium | 174 | (Pulse O | | | | | | 175 | ximeter) | | | | | | 176 | | | | | | | 177 | BP | 10 ms | 13.2 | <250ms | Medium | Medium | 178 | | | | | | | 179 | Respirat | 40 ms | 3.2 | <250ms | Medium | Medium | 180 | ion | | | | | | 181 | | | | | | | 182 | Skin tem | 60 s | 2.27 | <250ms | Low | Medium | 183 | perature | | | | | | 184 | | | | | | | 185 | Glucose | 250 s | 0.528 | <250ms | Medium | Medium | 186 | sensor | | | | | | 187 +----------+----------+---------+-----------+-----------+-----------+ 189 Table 1: Traffic patterns and requirements of sensor nodes 191 3.2. Patient monitoring for Chronic Diseases 193 For a chronic disease patient, the formal procedure of routine visits 194 is required to monitor the progress, development of complications or 195 relapse of the disease. The questions like what, how and when to 196 monitor are really crucial for disease treatment. In this context, 197 various biosensors can be used for monitoring the patient's 198 physiological conditions which brings relevant information on a 199 regular basis. Appendix A and B shows patient monitoring use case 200 scenario for WBAN. 202 3.3. Elderly Patient Monitoring 204 The fast growth in the elderly population will produce a considerable 205 shortage of healthcare experts in the near future. WBAN delivers a 206 highly cost effective solution to monitor the physiological 207 parameters of the elderly persons by seamless integration of their 208 daily routine activities. Moreover, the physician can monitor the 209 health conditions of an elderly person remotely by the courtesy of 210 WBANs. 212 4. Why 6lo is required for IEEE 802.15.6 214 Based on the characteristics defined in the overview section, the 215 following sections elaborate on the main problems with IP for WBANs. 217 4.1. IPv6 Connectivity requirements 219 The requirement for IPv6 connectivity within WBANs is driven by the 220 following: 222 o The number of devices in WBANs makes network auto configuration 223 and statelessness highly desirable. And for this, IPv6 has 224 (default auto-configuration as a) ready solutions. 226 o The large number of devices poses the need for a large address 227 space, moreover a WBAN may consist of 256 nodes maximum and IPv6 228 is helpful to solve addressing issues. 230 o Given the limited packet size of WBANs, the IPv6 address format 231 allows subsuming of IEEE 802.15.6 addresses if so desired. 233 o Simple interconnectivity to other IP networks including the 234 Internet. 236 o However, given the limited packet size, headers for IPv6 and 237 layers above must be compressed whenever possible. 239 However, given the limited packet size, headers for IPv6 and layers 240 above must be compressed whenever possible. 242 4.2. Limited Packet Size 244 Applications within WBANs are expected to originate small packets. 245 Adding all layers for IP connectivity should still allow transmission 246 in one frame, without incurring excessive fragmentation and 247 reassembly. Furthermore, protocols must be designed or chosen so 248 that the individual "control/protocol packets" fit within a single 249 802.15.6 frame. Along these lines, IPv6's requirement of sub-IP 250 reassembly may pose challenges for low-end WBANs healthcare devices 251 that do not have enough RAM or storage for a 1280-octet packet 252 [RFC2460]. 254 4.3. Topology requirements 256 The IEEE 802.15.6 working group has considered WBANs to operate in 257 either a one-hop or two-hop star topology with the node in the centre 258 of the star being placed on a location like the waist. Two feasible 259 types of data transmission exist in the one-hop star topology: 260 transmission from the device to the coordinator and transmission from 261 the coordinator to the device. The communication methods that exist 262 in the star topology are beacon mode and non-beacon mode. In a two- 263 hop start WBAN, a relay-capable node may be used to exchange data 264 frames between a node and the hub. 266 5. Scope/Purpose 268 This is a standard for short-range, wireless communication in the 269 vicinity of, or inside, a human body (but not limited to humans). It 270 uses existing industrial scientific medical (ISM) bands as well as 271 frequency bands approved by national medical and/or regulatory 272 authorities. Support for quality of service (QoS), extremely low 273 power, and data rates from 10Kbps to 10 Mbps is required while 274 simultaneously complying with strict non-interference guidelines 275 where needed. The Table 1 shows a comparison of WBAN and other 276 available technologies in terms of data rate and power consumption. 278 +----------------+---------------+-----------------+----------------+ 279 | Standard | Provided data | Power | Battery | 280 | | rate | requirement | lifetime | 281 +----------------+---------------+-----------------+----------------+ 282 | 802.11 ac | 700 Mbps | 100 mW - 1000 | Hours - days | 283 | (WiFi) | | mW | | 284 | | | | | 285 | Bluetooth | 1Mbps - 10 | 4 mW - 100 mW | Days - weeks | 286 | | Mbps | | | 287 | | | | | 288 | Wibree | 600 Kbps | 2 mW - 10 mW | Weeks - months | 289 | | maximum | | | 290 | | | | | 291 | ZigBee | 250 Kbps | 3 mW - 10 mW | Weeks - months | 292 | | | | | 293 | 802.15.4 | 250 Kbps | 3 mW - 10 mW | Weeks - months | 294 | | maximum | | | 295 | | | | | 296 | 802.15.6 | 1Kbps - 10 | 0.1 mW - 2 mW | Months - years | 297 | | Mbps | | | 298 +----------------+---------------+-----------------+----------------+ 300 Table 2: Comparison of WBAN 302 The purpose of this document is to provide an international standard 303 for a short-range (i.e., about human body range), low power, and 304 highly reliable wireless communication for use in close proximity to, 305 or inside, a human body. Data rates, typically up to 10Mbps, can be 306 offered to satisfy an evolutionary set of entertainment and 307 healthcare services. Current personal area networks (PANs) do not 308 meet the medical (proximity to human tissue) and relevant 309 communication regulations for some application environments. They 310 also do not support the combination of reliability, QoS, low power, 311 data rate, and non-interference required to broadly address the 312 breadth of body area network (BAN) applications. 314 6. Layer 2 Overview 316 All nodes and hubs (coordinator in 802.15.4) are to be organized into 317 logical sets, referred to as body area networks (BANs) in this 318 specification, and coordinated by their respective hubs for medium 319 access and power management as illustrated in Table 1. There is to 320 be one and only one hub in a BAN, whereas the number of nodes in a 321 BAN is to range from zero to mMaxBANSize. In a one-hop star BAN 322 [SURVEY-WBAN][RFC7326], frame exchanges are to occur directly between 323 nodes and the hub of the BAN. In a two-hop extended star BAN, the 324 hub and a node are to exchange frames optionally via a relay-capable 325 node. Some of the characteristics of WBANs are as follows: 327 6.1. Frame format 329 Figure 1 shows the general MAC frame format consisting of a 56-bit 330 header, variable length frame body, and 18-bit FrameCheck Sequence 331 (FCS). The maximum length of the frame body is 255 octets. The MAC 332 header further consists of 32-bit frame control, 8-bit recipient 333 Identification (ID), 8-bit sender ID, and 8-bit WBAN ID fields. The 334 frame control field carries control information including the type of 335 frame, that is, beacon, acknowledgement, or other control frames. 336 The recipient and sender ID fields contain the address information of 337 the recipient and the sender of the data frame, respectively. The 338 WBAN ID contains information on the WBAN in which the transmission is 339 active. The first 8-bit field in the MAC frame body carries message 340 freshness information required for nonce construction and replay 341 detection. The frame payload field carries data frames, and the last 342 32-bit Message Integrity Code (MIC) carries information about the 343 authenticity and integrity of the frame. 345 Octets 7 0-255 2 346 +--------+------------------+--------+ 347 | MAC | MAC frame body | | 348 | header |Variable length: | FCS | 349 | | 0-255 bytes | | 350 +--------+------------------+--------+ 351 <--MHR--><--------X--------><---FTR--> 352 / \ 353 / \ 354 / \ 355 +---------+------------+-------------+--------------+ 356 | Frame | Recipitent | Sender | Ban | 357 | control | ID | ID | ID | 358 +---------+------------+-------------+--------------+ 359 Octets <--------><-----------><------------><--------------> 361 Figure 1: The general MAC frame format of IEEE 802.15.6 363 6.2. Frequency bands 365 The USA Federal Communications Commission (FCC) and communication 366 authorities of other countries have allocated the MICS band at 367 402-405 MHz with 300 KHz channels to enable wireless communication 368 with implanted medical devices [[[REFERENCE TO BE ADDED]]]. This 369 leads to better penetration through the human tissue compared to 370 higher frequencies, high level of mobility, comfort and better 371 patient care in implant to implant (S1), implant to body surface (S2) 372 and implant to external (S3) scenarios. Additionally, the 402-405 373 MHz frequencies offers conducive propagation characteristics for the 374 transmission of radio signals in the human body and do not cause 375 severe interference for other radio operations in the same band. In 376 fact, the MICs band is an unlicensed, ultra-low power, mobile radio 377 service for transmitting data to support therapeutic or diagnostic 378 operation related to implant medical devices and is internationally 379 available. It is specifically chosen to provide low-power, small 380 size, fast data transfer as well as a long communication range 381 [SURVEY-WBAN][MAC-WBAN]. The frequency range of the MICS band allows 382 high-level integration with the radio frequency IC (RFIC) technology, 383 which leads to miniaturization and low power consumption. The PHY 384 layer of IEEE 802.15.6 is responsible for the following tasks: 385 activation and deactivation of the radio transceiver, Clear channel 386 assessment (CCA) within the current channel and data transmission and 387 reception. The choice of the physical layer depends on the target 388 application: medical/non-medical, in, on and off-body. The PHY layer 389 provides a procedure for transforming a physical layer service data 390 unit (PSDU) into a physical layer protocol data unit (PPDU). IEEE 391 802.15.6 has specified three different physical layers: Human Body 392 Communication (HBC), Narrow Band (NB) and Ultra-Wide Band (UWB). 393 Various frequency bands are supported and shown in Table 2. 395 +---------------+-----------------+-----------+ 396 | Communication | Frequency | Bandwidth | 397 +---------------+-----------------+-----------+ 398 | HBC | 16 MHz | 4 MHz | 399 | | | | 400 | HBC | 27 MHz | 4 MHz | 401 | | | | 402 | NB | 402-405 MHz | 300 KHz | 403 | | | | 404 | NB | 420-450 MHz | 300 KHz | 405 | | | | 406 | NB | 863-870 MHz | 400 KHz | 407 | | | | 408 | NB | 902-928 MHz | 500 KHz | 409 | | | | 410 | NB | 956-956 MHz | 400 KHz | 411 | | | | 412 | NB | 2360-2400 MHz | 1 MHz | 413 | | | | 414 | NB | 2400-2438.5 MHz | 1 MHz | 415 | | | | 416 | UWB | 13.2-4.7 GHz | 499 MHz | 417 | | | | 418 | UWB | 6.2-10.3 GHz | 499 MHz | 419 +---------------+-----------------+-----------+ 421 Table 3: Frequency bands and Channel bandwidth of IEEE 802.15.6 423 6.3. Channel modes of IEEE 802.15.6 425 o Beacon Mode with Beacon Period Superframe Boundaries: 427 Beacons are sent at beacon periods by the coordinator and the 428 superframe structure is managed by the coordinator by using beacon 429 frames. The Physical Protocol Data Unit (PPDU) frame of Narrowband 430 (NB) consists of a PHY Service Data Unit (PSDU) and Physical Layer 431 Convergence Procedure (PLCP). PLCP preamble supports the receiver 432 for synchronization process and considers as first module being send 433 at given symbol rate. PLCP header sends decoding information for the 434 receiver and it is transmitted after PLCP preamble. PSDU is last 435 module of PPDU and consists of MAC header, Frame Check Sequence (FCS) 436 and MAC frame body. PSDU is transmitted after PLCP with help of 437 available frequency band with specific data rates. Different 438 modulations schemes can be used with NB, namely, Differential Binary 439 Phase-shift Keying (DBPSK), Differential Quadrature Phase-shift 440 Keying (DQPSK) and Differential 8-Phase-shift Keying (D8PSK). NB 441 uses seven frequency bands and operates under different data rates 442 and modulation schemes. Medical Implant Communication Service (MICS) 443 is the first licensed band of NB and used for implant communication 444 with range of 402-405 MHz in most countries. Lower frequencies 445 possess less attenuation and shadowing effect from body. Wireless 446 Telemetry Medical Services (WMTS) is another license band and used 447 for telemetry services. Although, Industrial, Scientific and Medical 448 (ISM) band is free worldwide but it generates high probability of 449 interference for IEEE 802.15.4 and IEEE 802.15.6 devices and 450 considered as 7th license-free band. The 6th band (2360-2400 MHz) is 451 used for medical devices instead of ISM band and offers less 452 interference. 454 The superframe structure consists of several phases: exclusive access 455 phase 1 (EAP 1), random access phase 1 (RAP1), type I/II phase, an 456 EAP 2, RAP 2 and contention access phase (CAP). CSMA/CA or slotted 457 Aloha is used by EAPs, RAPs and CAPs. For emergency services and 458 high priority data, the EAP 1 and EAP 2 are used, whereas, CAP, RAP 1 459 and RAP 2 are used for regular data traffic. Type I/II are used for 460 bi-link allocation intervals, up-link and down-link allocation 461 intervals and delay bi-link intervals. For resource allocation, the 462 type I/II polling is used. 464 A node's backoff counter value is set to a random integer number in 465 the range [1,CW (Contention Window)], where CW (default value is 466 CWmin) belongs to CWmin and CWmax which is dependent on user 467 priority. When the algorithm starts, node begins counter decrement 468 by one for every idle CSMA/CA slot duration (slot duration is equal 469 to Pcsma/CA slot length). A node considers a CSMA/CA slot idle if 470 the channel has been idle between start of slot and pCCATime. When 471 the backoff counter reaches zero, the node transmits the data frame. 472 In case the channel is busy because of some other frame transmission, 473 then node locks its backoff counter until the channel gets idle. The 474 value of CW get double in case of even number of failures until it 475 reaches CWmax [CHALLENGES-WBAN] [RFC7548]. 477 o Beacon Mode with Superframe Boundaries: 479 For this mode, the coordinator provides an unscheduled polled 480 allocation and each node establishes its own schedule. Different 481 access mechanisms are used in superframe phases: schedule access 482 (connection oriented and contention-free access), improvised and 483 unscheduled access (connectionless and contention free access) and 484 random access (CSMA/CA or slotted Aloha based). 486 o Beacon Mode without Superframe Boundaries: 488 In this channel access mode, beacons are not transmitted and channel 489 is assigned by using polling mechanism. 491 7. --IETF to standardize-- 493 This draft intend to standardize IEEE 802.15.6 for WBANs, 494 specifically for implantable and wearable sensors. By standardizing 495 means that integration of frame format need to be done i.e., how the 496 IEEE 802.15.6 frame format will communicate with IPv6? How 6LoWPAN 497 can accommodate this different frame format? The purpose of the 498 mentioned use cases is to highlight the importance of the standard. 500 The 6LoWPAN is used to provide integration between IEEE 802.15.4 and 501 IPv6. The details are mentioned in [RFC7548]. The 6LoWPAN concept 502 originated with the purpose of connectivity of internet protocol with 503 low-power smaller devices so they could claim to be part of Internet 504 of Things (IoT) Networks. 506 The 6LoWPAN group has defined encapsulation and header compression 507 mechanisms that allow ipv6 packets to be sent and received over IEEE 508 802.15.4 based networks, similarly the draft intent to define these 509 mechanisms for IEEE 802.15.6. The 6LoWPAN can not be used with IEEE 510 802.15.6 due to frame size differences of IEEE 802.15.4 and IEEE 511 802.15.6. 513 8. IANA Considerations 515 [TBD] 517 9. Security Considerations 519 IPv6 over WBAN's applications often require confidentiality and 520 integrity protection. This can be provided at the application, 521 transport, network, and/or at the link. 523 10. Acknowledgements 525 [TBD] 527 11. References 529 11.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, 533 DOI 10.17487/RFC2119, March 1997, 534 . 536 [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. 537 Sehgal, "Management of Networks with Constrained Devices: 538 Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, 539 . 541 [RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek, 542 "Energy Management Framework", RFC 7326, 543 DOI 10.17487/RFC7326, September 2014, 544 . 546 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 547 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 548 December 1998, . 550 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 551 "Transmission of IPv6 Packets over IEEE 802.15.4 552 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 553 . 555 11.2. Informative References 557 [I-D.ietf-6tisch-6top-sf0] 558 Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, 559 "6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf- 560 6tisch-6top-sf0-02 (work in progress), October 2016. 562 [I-D.satish-6tisch-6top-sf1] 563 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 564 Anand, "Scheduling Function One (SF1) for hop-by-hop 565 Scheduling in 6tisch Networks", draft-satish-6tisch-6top- 566 sf1-02 (work in progress), August 2016. 568 [IEEE802.15.6] 569 "IEEE Standard, 802.15.6-2012 - IEEE Standard for Local 570 and metropolitan area networks - Part 15.6: Wireless Body 571 Area Networks", 2012, 572 . 575 [SURVEY-WBAN] 576 Diffie, W., Samaneh Movassaghi, Mehran Abolhasan, Justin 577 Lipman, David Smith, and Abbas Jamalipour, "Wireless body 578 area networks: A survey", Communications Surveys and 579 Tutorials, IEEE , vol. 16, no. 3, pp. 1658-1686, 2014. 581 [MAC-WBAN] 582 Minglei Shu, Dongfeng Yuan, Chongqing Zhang, Yinglong 583 Wang, and Changfang Chen, "A MAC Protocol for Medical 584 Monitoring Applications of Wireless Body Area Networks.", 585 Sensors , vol. 15, no. 6, 2015. 587 [CHALLENGES-WBAN] 588 Riccardo Cavallari, Flavia Martelli, Ramona Rosini, Chiara 589 Buratti, and Roberto Verdone, "A Survey on Wireless Body 590 Area Networks: Technologies and Design Challenges.", IEEE 591 Communications Surveys and Tutorials , vol. 16, no. 3, 592 pp. 1635-1657, 2014. 594 Appendix A. Patient monitoring use case - Spoke Hub 596 Refer following diagram: 598 ######## 599 # @ EEG # 600 ## | @ # Hearing 601 # | | # 602 # | |# 603 # | #| 604 ##### | |## ### 605 # | | @ ## Motion Sensor 606 Positioning# @ | / / # 607 # \ |ECG / / # 608 # \ | @ | / # 609 # \ | / / / # 610 # ## \ |/ // ## # 611 # ## \ ||// ## # 612 # # # \ |||| # # @ # BP 613 # # # \|||| # # / ## 614 # ## # |||| # #/ ## 615 SPO2# @ ## # Coordinator # /## # 616 # \ ## ## +-+ / ## ## 617 # ------+--------| |-------/ # # # 618 ## ## # +-+ ## # ## 619 ## ## # //\ # # ## 620 ### # # // \ # ## ### 621 ## # # // \ # # ## ## 622 # # # // \ # # # 623 ### # # # // ## \ # # ### 624 # ### # // # # \ # # # ### 625 ### # // # # | # # ### 626 # // # ## | # 627 Glucose Sensor # @ / # # | # 628 ## | ## # | # 629 # / # # | # 630 #/ # # | # 631 Emg#@ # # | # 632 # # ## | # 633 ## # | # 634 # # # | # 635 # # #\ # 636 # # # | # 637 # # # @ # Motion Sensor 638 ## # ## ## 639 ## # 641 Figure 2: Patient monitoring use case - Spoke Hub 643 Appendix B. Patient monitoring use case - Connected 645 Refer following diagram: 647 ######## 648 # @ EEG # 649 ## |\-----@ # Hearing 650 # | \# 651 # | # | 652 # | ## |Motion Sensor 653 ####### | ##|#### 654 # | | ## 655 Positioning# @ | @ # 656 # /\ ECG| \ # 657 # / \----------@ \ # 658 # / | # 659 # / ## ## | # 660 # / # # # # @ # BP 661 #/ ## # # ## | ## 662 SPO2# @ ## # # ## | # 663 # \ # # # #| # 664 ## ## \ # ## | # ## 665 ## # \ # # | # ## ## 666 ### # # # \ ## # | # ### 667 # ### # \ # # # | # # ### 668 ### # | # # # | # ### 669 # | # ## # | 670 Glucose Sensor # @ # # # | 671 # / # # # / 672 #| ## # #/ 673 #/ # # #| 674 Emg#@ # # #| 675 # \ # # #| 676 # \ # # #| 677 # \# ## #| 678 ## \ # #| 679 # #\ # #| 680 # # \ # #| 681 # # \ # #| 682 # # \ ## #/ 683 # # \ ## / 684 # # \ ## /# 685 ## # \ | # 686 # # # \/ # 687 # # # @ # Motion Sensor 688 ## # 690 Figure 3: Patient monitoring use case - Connected 692 Authors' Addresses 694 Muhammad Sajjad Akbar 695 Bournemouth University 696 Fern Barrow, Dorset 697 Poole BH12 5BB 698 United Kingdom 700 Email: makbar@bournemouth.ac.uk 702 Naveed Bin Rais 703 Ajman University 704 University Street,Al jerf 1 705 Ajman 346 706 United Arab Emirates 708 Email: naveedbinrais@gmail.com 710 Abdur Rashid Sangi 711 Individual Contributor 713 Email: sangi_bahrian@yahoo.com 715 Mingui Zhang 716 Huawei Technologies 717 No. 156 Beiqing Rd. Haidian District 718 Beijing 100095 719 China 721 Email: zhangmingui@huawei.com 723 Charles E. Perkins 724 Futurewei 725 2330 Central Expressway 726 Santa Clara 95050 727 Unites States 729 Email: charliep@computer.org