idnits 2.17.1 draft-hong-6lo-use-cases-03.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 date (October 30, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 842, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4919 ** Downref: Normative reference to an Informational RFC: RFC 5826 ** Downref: Normative reference to an Informational RFC: RFC 6568 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-07 == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-05 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-05 == Outdated reference: A later version (-08) exists of draft-ietf-lwig-energy-efficient-05 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group Y-G. Hong 3 Internet-Draft ETRI 4 Intended status: Standards Track C. Gomez 5 Expires: May 3, 2017 UPC/i2cat 6 Y-H. Choi 7 ETRI 8 D-Y. Ko 9 SKtelecom 10 October 30, 2016 12 IPv6 over Constrained Node Networks(6lo) Applicability & Use cases 13 draft-hong-6lo-use-cases-03 15 Abstract 17 This document describes the applicability of IPv6 over constrained 18 node networks (6lo) and use cases. It describes the practical 19 deployment scenarios of 6lo technologies with the consideration of 20 6lo link layer technologies and identifies the requirements. In 21 addition to IEEE 802.15.4, various link layer technologies such as 22 ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, and IEEE 23 802.15.4e(6tisch) are widely used at constrained node networks for 24 typical services. Based on these link layer technologies, IPv6 over 25 networks of resource-constrained nodes has various and practical use 26 cases. To efficiently implement typical services, the applicability 27 and consideration of several design space dimensions are described. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 65 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 66 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 4 68 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.4. Master-Slave/Token-Passing . . . . . . . . . . . . . . . 5 70 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.7. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . 7 73 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 8 74 5. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 10 77 6.2. Use case of Bluetooth Low Energy: Smartphone-Based 78 Interaction with Constrained Devices . . . . . . . . . . 11 79 6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 13 80 6.4. Use case of MS/TP: . . . . . . . . . . . . . . . . . . . 14 81 6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 14 82 6.6. Use case of LTE MTC . . . . . . . . . . . . . . . . . . . 16 83 6.7. Use case of IEEE 802.15.4e: . . . . . . . . . . . . . . . 18 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 10.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 Running IPv6 on constrained node networks has different features from 95 general node networks due to the characteristics of constrained node 96 networks such as small packet size, short link-layer address, low 97 bandwidth, network topology, low power, low cost, and large number of 98 devices [RFC4919]. For example, because some IEEE 802.15.4 link 99 layers have a frame size of 127 octets and IPv6 requires the layer 100 below to support an MTU of 1280 bytes, an appropriate fragmentation 101 and reassembly adaptation layer must be provided at the layer of 102 below IPv6. Also, the limited size of IEEE 802.15.4 frame and low 103 energy consumption requirements make the need for header compression. 104 IETF 6lowpan (IPv6 over Low powerWPAN) working group published, an 105 adaptation layer for sending IPv6 packets over IEEE 802.15.4 106 [RFC4944], compression format for IPv6 datagrams over IEEE 107 802.15.4-based networks [RFC6282], and Neighbor Discovery 108 Optimization for 6lowpan [RFC6775]. 110 As IoT (Internet of Things) services become more popular, various 111 link layer technologies such as Bluetooth Low Energy (Bluetooth LE), 112 ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - 113 Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near 114 Field Communication (NFC), and LTE Machine Type Communication are 115 actively used. And the transmission of IPv6 packets over these link 116 layer technologies is required. A number of IPv6-over-foo documents 117 have been developed in the IETF 6lo (IPv6 over Networks of Resource- 118 constrained Nodes) and 6tisch (IPv6 over the TSCH mode of IEEE 119 802.15.4e) working groups. 121 In the 6lowpan working group, the [RFC6568], "Design and Application 122 Spaces for 6LoWPANs" was published and it describes potential 123 application scenarios and use cases for low-power wireless personal 124 area networks. In this document, various design space dimensions 125 such as deployment, network size, power source, connectivity, multi- 126 hop communication, traffic pattern, security level, mobility, and QoS 127 were analyzed. And it described a fundamental set of 6lowpan 128 application scenarios and use cases: Industrial monitoring-Hospital 129 storage rooms, Structural monitoring-Bridge safety monitoring, 130 Connected home-Home Automation, Healthcare-Healthcare at home by 131 tele-assistance, Vehicle telematics-telematics, and Agricultural 132 monitoring-Automated vineyard. 134 Even though the [RFC6568] describes some potential application 135 scenarios and use cases and it lists the design space in the context 136 of 6lowpan, it does not cover the different use cases and design 137 space in the context of the 6lo working group. The RFC6568 assumed 138 that the link layer technology is the IEEE802.15.4 and the described 139 application scenarios and use cases were based on the IEEE 802.15.4 140 technologies. Due to various link layer technologies such as ITU-T 141 G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, and IEEE 142 802.15.4e(6tisch), potential application scenarios and use cases of 143 6lo will go beyond the RFC6568. 145 This document provides the applicability and use cases of 6lo, 146 considering the following: 148 o 6lo applicability and use cases MAY be uniquely different from 149 those of 6lowpan. 151 o 6lo applicability and use cases SHOULD cover various IoT related 152 wire/wireless link layer technologies providing practical 153 information of such technologies. 155 o 6lo applicability and use cases SHOULD describe characteristics 156 and typical use cases of each link layer technology, and then 6lo 157 use cases's applicability. 159 2. Conventions and Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 3. 6lo Link layer technologies 167 3.1. ITU-T G.9959 169 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 170 Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID 171 network identifier is assigned by a network controller and how an 172 8-bit NodeID host identifier is allocated to each node. NodeIDs are 173 unique within the network identified by the HomeID. The G.9959 174 HomeID represents an IPv6 subnet that is identified by one or more 175 IPv6 prefixes [RFC7428]. 177 3.2. Bluetooth Low Energy 179 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 180 4.1, and developed even further in successive versions. Bluetooth 181 SIG has also published Internet Protocol Support Profile (IPSP). The 182 IPSP enables discovery of IP-enabled devices and establishment of 183 link-layer connection for transporting IPv6 packets. IPv6 over 184 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 185 newer. 187 Devices such as mobile phones, notebooks, tablets and other handheld 188 computing devices which will include Bluetooth 4.1 chipsets will 189 probably also have the low-energy variant of Bluetooth. Bluetooth LE 190 will also be included in many different types of accessories that 191 collaborate with mobile devices such as phones, tablets and notebook 192 computers. An example of a use case for a Bluetooth LE accessory is 193 a heart rate monitor that sends data via the mobile phone to a server 194 on the Internet [RFC7668]. 196 3.3. DECT-ULE 198 DECT ULE is a low power air interface technology that is designed to 199 support both circuit switched services, such as voice communication, 200 and packet mode data services at modest data rate. 202 The DECT ULE protocol stack consists of the PHY layer operating at 203 frequencies in the 1880 - 1920 MHz frequency band depending on the 204 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 205 allocated by use of FDMA/TDMA/TDD techniques. 207 In its generic network topology, DECT is defined as a cellular 208 network technology. However, the most common configuration is a star 209 network with a single Fixed Part (FP) defining the network with a 210 number of Portable Parts (PP) attached. The MAC layer supports 211 traditional DECT as this is used for services like discovery, 212 pairing, security features etc. All these features have been reused 213 from DECT. 215 The DECT ULE device can switch to the ULE mode of operation, 216 utilizing the new ULE MAC layer features. The DECT ULE Data Link 217 Control (DLC) provides multiplexing as well as segmentation and re- 218 assembly for larger packets from layers above. The DECT ULE layer 219 also implements per-message authentication and encryption. The DLC 220 layer ensures packet integrity and preserves packet order, but 221 delivery is based on best effort. 223 The current DECT ULE MAC layer standard supports low bandwidth data 224 broadcast. However the usage of this broadcast service has not yet 225 been standardized for higher layers [I-D.ietf-6lo-dect-ule]. 227 3.4. Master-Slave/Token-Passing 229 MS/TP is a contention-free access method for the RS-485 physical 230 layer, which is used extensively in building automation networks. 232 An MS/TP device is typically based on a low-cost microcontroller with 233 limited processing power and memory. Together with low data rates 234 and a small address space, these constraints are similar to those 235 faced in 6LoWPAN networks and suggest some elements of that solution 236 might be leveraged. MS/TP differs significantly from 6LoWPAN in at 237 least three respects: a) MS/TP devices typically have a continuous 238 source of power, b) all MS/TP devices on a segment can communicate 239 directly so there are no hidden node or mesh routing issues, and c) 240 recent changes to MS/TP provide support for large payloads, 241 eliminating the need for link-layer fragmentation and reassembly. 243 MS/TP is designed to enable multidrop networks over shielded twisted 244 pair wiring. It can support a data rate of 115,200 baud on segments 245 up to 1000 meters in length, or segments up to 1200 meters in length 246 at lower baud rates. An MS/TP link requires only a UART, an RS-485 247 transceiver with a driver that can be disabled, and a 5ms resolution 248 timer. These features make MS/TP a cost-effective field bus for the 249 most numerous and least expensive devices in a building automation 250 network [I-D.ietf-6lo-6lobac]. 252 3.5. NFC 254 NFC technology enables simple and safe two-way interactions between 255 electronic devices, allowing consumers to perform contactless 256 transactions, access digital content, and connect electronic devices 257 with a single touch. NFC complements many popular consumer level 258 wireless technologies, by utilizing the key elements in existing 259 standards for contactless card technology (ISO/IEC 14443 A&B and 260 JIS-X 6319-4). NFC can be compatible with existing contactless card 261 infrastructure and it enables a consumer to utilize one device across 262 different systems. 264 Extending the capability of contactless card technology, NFC also 265 enables devices to share information at a distance that is less than 266 10 cm with a maximum communication speed of 424 kbps. Users can 267 share business cards, make transactions, access information from a 268 smart poster or provide credentials for access control systems with a 269 simple touch. 271 NFC's bidirectional communication ability is ideal for establishing 272 connections with other technologies by the simplicity of touch. In 273 addition to the easy connection and quick transactions, simple data 274 sharing is also available [I-D.ietf-6lo-nfc]. 276 3.6. LTE MTC 278 LTE category defines the overall performance and capabilities of the 279 UE(User Equipment). For example, the maximum down rate of category 1 280 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 281 There are many categories in LTE standard. 3GPP standards defined the 282 category 0 to be used for low rate IoT service in release 12. Since 283 category 1 and category 0 could be used for low rate IoT service, 284 these categories are called LTE MTC (Machine Type Communication) 285 [LTE_MTC]. 287 LTE MTC have the advantages compared to above category 2 to be used 288 for low rate IoT service such as low power and low cost. 290 The below figure shows the primary characteristics of LTE MTC. 292 +------------+---------------------+-------------------+ 293 | Category | Max. Date Rate Down | Max. Date Rate Up | 294 +------------+---------------------+-------------------+ 295 | Category 0 | 1.0 Mbit/s | 1.0 Mbit/s | 296 | | | | 297 | Category 1 | 10.3 Mbit/s | 5.2 Mbit/s | 298 +------------+---------------------+-------------------+ 300 Table 1: Primary characteristics of LTE MTC 302 3.7. IEEE 802.15.4e 304 The Timeslotted Channel Hopping (TSCH) mode was introduced in the 305 IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are 306 synchronized. Time is sliced up into timeslots. The duration of a 307 timeslot, typically 10ms, is large enough for a node to send a full- 308 sized frame to its neighbor, and for that neighbor to send back an 309 acknowledgment to indicate successful reception. Timeslots are 310 grouped into one of more slotframes, which repeat over time. 312 All the communication in the network is orchestrated by a 313 communication schedule which indicates to each node what to do in 314 each of the timeslots of a slotframe: transmit, listen or sleep. The 315 communication schedule can be built so that the right amount of link- 316 layer resources (the cells in the schedule) are scheduled to satisfy 317 the communication needs of the applications running on the network, 318 while keeping the energy consumption of the nodes very low. Cells 319 can be scheduled in a collision-free way, introducing a high level of 320 determinism to the network. 322 A TSCH network exploits channel hopping: subsequent packets exchanged 323 between neighbor nodes are done so on a different frequency. This 324 means that, if a frame isn't received, the transmitter node will re- 325 transmitt the frame on a different frequency. The resulting "channel 326 hopping" efficiently combats external interference and multi-path 327 fading. 329 The main benefits of IEEE 802.15.4 TSCH are: 331 - ultra high reliability. Off-the-shelf commercial products offer 332 over 99.999% end-to-end reliability. 334 - ultra low-power consumption. Off-the-shelf commercial products 335 offer over a decade of battery lifetime. 337 4. 6lo Deployment Scenarios 339 In this clause, we will describe some 6lo deployment scenrios such as 340 Smart Grid activity in WiSun 342 [TBD] 344 5. Design Space 346 The [RFC6568] lists the dimensions used to describe the design space 347 of wireless sensor networks in the context of the 6LoWPAN working 348 group. The design space is already limited by the unique 349 characteristics of a LoWPAN (e.g., low power, short range, low bit 350 rate). In the RFC 6568, the following design space dimensions are 351 described; Deployment, Network size, Power source, Connectivity, 352 Multi-hop communication, Traffic pattern, Mobility, Quality of 353 Service (QoS). 355 The design space dimensions of 6lo are a little different from those 356 of the RFC 6568 due to the different characteristics of 6lo link 357 layer technologies. The following design space dimensions can be 358 considered. 360 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 361 in an organized manner. The bootstrapping has different 362 characteristics for each link layer technology. 364 o Topology: Topology of 6lo networks may inherently follow the 365 characteristics of each link layer technology. Point-to-point, 366 star, tree or mesh topologies can be configured, depending on the 367 link layer technology considered. 369 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 370 characteristics of each link layer technology. Some link layer 371 technologies may support L2-mesh and some may not support. 373 o Multi-link subnet, single subnet: The selection of multi-link 374 subnet and single subnet depends on connectivity and the number of 375 6lo nodes. 377 o Data rate: Originally, the link layer technologies of 6lo have low 378 rate of data transmission. But, by adjusting the MTU, it can 379 deliver higher data rate. 381 o Buffering requirements: Some 6lo use case may require more data 382 rate than the link layer technology support. In this case, a 383 buffering mechanism to manage the data is required. 385 o Security Requirements: Some 6lo use case can involve transferring 386 some important and personal data between 6lo nodes. In this case, 387 high-level security support is required. 389 o Mobility across 6lo networks and subnets: The movement of 6lo 390 nodes is dependent on the 6lo use case. If the 6lo nodes can move 391 or moved around, it requires a mobility management mechanism. 393 o Time synchronization requirements: The requirement of time 394 synchronization of the upper layer service is dependent on the 6lo 395 use case. For some 6lo use case related to health service, the 396 measured data must be recorded with exact time and must be 397 transferred with time synchronization. 399 o Reliability and QoS: Some 6lo use case requires high reliability, 400 for example real-time service or health-related services. 402 o Traffic patterns: 6lo use cases may involve various traffic 403 patterns. For example, some 6lo use case may require short data 404 length and random transmission. Some 6lo use case may require 405 continuous data and periodic data transmission. 407 o Security Bootstrapping: Without the external operations, 6lo nodes 408 must have the security bootstrapping mechanism. 410 o Power use strategy: to enable certain use cases, there may be 411 requirements on the class of energy availability and the strategy 412 followed for using power for communication [RFC7228]. Each link 413 layer technology defines a particular power use strategy which may 414 be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected 415 to be familiar with RFC 7228 terminology. 417 o Update firmware requirements: Most 6lo uses case will need a 418 mechanism for updating firmware. In these cases support for over 419 the air updates are required, probably in a broadcast mode when 420 bandwith is low and the number of identical devices is high. 422 6. 6lo Use Cases 424 6.1. Use case of ITU-T G.9959: Smart Home 426 Z-Wave is one of the main technologies that may be used to enable 427 smart home applications. Born as a proprietary technology, Z-Wave 428 was specifically designed for this use case. Recently, the Z-Wave 429 radio interface (physical and MAC layers) has been standardized as 430 the ITU-T G.9959 specification. 432 Example: Use of ITU-T G.9959 for Home Automation 434 Variety of home devices (e.g. light dimmers/switches, plugs, 435 thermostats, blinds/curtains and remote controls) are augmented with 436 ITU-T G.9959 interfaces. A user may turn on/off or may control home 437 appliances by pressing a wall switch or by pressing a button in a 438 remote control. Scenes may be programmed, so that after a given 439 event, the home devices adopt a specific configuration. Sensors may 440 also periodically send measurements of several parameters (e.g. gas 441 presence, light, temperature, humidity, etc.) which are collected at 442 a sink device, or may generate commands for actuators (e.g. a smoke 443 sensor may send an alarm message to a safety system). 445 The devices involved in the described scenario are nodes of a network 446 that follows the mesh topology, which is suitable for path diversity 447 to face indoor multipath propagation issues. The multihop paradigm 448 allows end-to-end connectivity when direct range communication is not 449 possible. Security support is required, specially for safety-related 450 communication. When a user interaction (e.g. a button press) 451 triggers a message that encapsulates a command, if the message is 452 lost, the user may have to perform further interactions to achieve 453 the desired effect (e.g. a light is turned off). A reaction to a 454 user interaction will be perceived by the user as immediate as long 455 as the reaction takes place after less than 0.5 seconds [RFC5826]. 457 Dominant parameters in home automation scenarios with ITU-T G.9959: 459 o Deployment/Bootstrapping: Pre-planned. 461 o Topology: Mesh topology. 463 o L2-mesh or L3-mesh: ITU-T G.9959 provides support for L2-mesh, and 464 L3-mesh can also be used (the latter requires an IP-based routing 465 protocol). 467 o Multi-link subnet, single subnet: Multi-link subnet. 469 o Data rate: Small data rate, infrequent transmissions. 471 o Buffering requirements: Low requirement. 473 o Security requirements: Data privacy and security must be provided. 474 Encryption is required. 476 o Mobility: Most devices are static. A few devices (e.g. remote 477 control) are portable. 479 o Time Synchronization: TBD. 481 o Reliability and QoS: Moderate to high level of reliability 482 support. Actions as a result of human-generated traffic should 483 occur after less than 0.5 seconds. 485 o Traffic patterns: Periodic (sensor readings) and aperiodic (user- 486 triggered interaction). 488 o Security Bootstrapping: Required. 490 o Power use strategy: Mix of P1 (Low-power) devices and P9 (Always- 491 on) devices. 493 o Update firmware requirements: TBD. 495 6.2. Use case of Bluetooth Low Energy: Smartphone-Based Interaction 496 with Constrained Devices 498 The key feature behind the current high Bluetooth LE momentum is its 499 support in a large majority of smartphones in the market. Bluetooth 500 LE can be used to allow the interaction between the smartphone and 501 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 502 the main radio interface currently available in wearables. Since a 503 smartphone typically has several radio interfaces that provide 504 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 505 gateway for nearby devices such as sensors, actuators or wearables. 506 Bluetooth LE may be used in several domains, including healthcare, 507 sports/wellness and home automation. 509 Example: Bluetooth LE-based Body Area Network for fitness 511 A person wears a smartwatch for fitness purposes. The smartwatch has 512 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 513 temperature, etc.), a display, and a Bluetooth LE radio interface. 514 The smartwatch can show fitness-related statistics on its display. 515 However, when a paired smartphone is in the range of the smartwatch, 516 the latter can report almost real-time measurements of its sensors to 517 the smartphone, which can forward the data to a cloud service on the 518 Internet. In addition, the smartwatch can receive notifications 519 (e.g. alarm signals) from the cloud service via the smartphone. On 520 the other hand, the smartphone may locally generate messages for the 521 smartwatch, such as e-mail reception or calendar notifications. 523 The functionality supported by the smartwatch may be complemented by 524 other devices such as other on-body sensors, wireless headsets or 525 head-mounted displays. All such devices may connect to the 526 smartphone creating a star topology network whereby the smartphone is 527 the central component. 529 Dominant parameters in fitness scenarios with Bluetooth LE: 531 o Deployment/Bootstrapping: Pre-planned. 533 o Topology: Star topology. 535 o L2-mesh or L3-mesh: No. 537 o Multi-link subnet, single subnet: Multi-link subnet. 539 o Data rate: TBD. 541 o Buffering requirements: Low requirement. 543 o Security requirements: For health-critical information, data 544 privacy and security must be provided. Encryption is required. 545 Some types of notifications sent by the smartphone may not need. 547 o Mobility: Low. 549 o Time Synchronization: the link layer, which is based on TDMA, 550 provides a basis for time synchronization. 552 o Reliability and QoS: a relatively low ratio of message losses is 553 acceptable for periodic sensor readings. End-to-end latency of 554 sensor readings should be low for critical notifications or 555 alarms, generated by either the smartphone or an Internet cloud 556 service. 558 o Traffic patterns: periodic (sensor readings) and aperiodic 559 (smartphone-generated notifications). 561 o Security Bootstrapping: Required. 563 o Power use strategy: P1 (Low-power) devices. 565 o Update firmware requirements: TBD. 567 6.3. Use case of DECT-ULE: Smart Home 569 DECT is a technology widely used for wireless telephone 570 communications in residential scenarios. Since DECT-ULE is a low- 571 power variant of DECT, DECT-ULE can be used to connect constrained 572 devices such as sensors and actuators to a Fixed Part, a device that 573 typically acts as a base station for wireless telephones. Therefore, 574 DECT-ULE is specially suitable for the connected home space in 575 application areas such as home automation, smart metering, safety, 576 healthcare, etc. 578 Example: use of DECT-ULE for Smart Metering 580 The smart electricity meter of a home is equipped with a DECT-ULE 581 transceiver. This device is in the coverage range of the Fixed Part 582 of the home. The Fixed Part can act as a router connected to the 583 Internet. This way, the smart meter can transmit electricity 584 consumption readings through the DECT-ULE link with the Fixed Part, 585 and the latter can forward such readings to the utility company using 586 Wide Area Network (WAN) links. The meter can also receive queries 587 from the utility company or from an advanced energy control system 588 controlled by the user, which may also be connected to the Fixed Part 589 via DECT-ULE. 591 Dominant parameters in smart metering scenarios with DECT-ULE: 593 o Deployment/Bootstrapping: Pre-planned. 595 o Topology: Star topology. 597 o L2-mesh or L3-mesh: No. 599 o Multi-link subnet, single subnet: Multi-link subnet. 601 o Data rate: Small data rate, infrequent transmissions. 603 o Buffering requirements: Low requirement. 605 o Security requirements: Data privacy and security must be provided. 606 Encryption is required. 608 o Mobility: No. 610 o Time Synchronization: TBD. 612 o Reliability and QoS: bounded latency, stringent reliability 613 service agreements [I-D.ietf-roll-applicability-ami]. 615 o Traffic patterns: Periodic (meter reading notifications sent by 616 the meter) and aperiodic (user- or company-triggered queries to 617 the meter, and messages triggered by local events such as power 618 outage or leak detection [I-D.ietf-roll-applicability-ami]). 620 o Security Bootstrapping: required. 622 o Power use strategy: P0 (Normally-off) for devices with long sleep 623 intervals (i.e. greater than ~10 seconds) which then may need to 624 resynchronize again, and P1 (Low-power) for short sleep intervals. 625 P9 (Always-on) for the Fixed Part (FP), which is the central node 626 in the star topology. 628 o Update firmware requirements: TBD. 630 6.4. Use case of MS/TP: 632 [TBD] 634 Example: [TBD] 636 o Power use strategy: P9 (Always-on). 638 6.5. Use case of NFC: Alternative Secure Transfer 640 According to applications, various secured data can be handled and 641 transferred. Depending on security level of the data, methods for 642 transfer can be alternatively selected. The personal data having 643 serious issues should be transferred securely, but data transfer by 644 using Wi-Fi and Bluetooth connections cannot always be secure because 645 of their a little long radio frequency range. Hackers can overhear 646 the personal data transfer behind hidden areas. Therefore, methods 647 need to be alternatively selected to transfer secured data. Voice 648 and video data, which are not respectively secure and requires long 649 transmission range, can be transferred by 3G/4G technologies, such as 650 WCDMA, GSM, and LTE. Big size data, which are not secure and 651 requires high speed and broad bandwidth, can be transferred by Wi-Fi 652 and wired network technologies. However, the personal data, which 653 pose serious issues if mishandled while transferred in wireless 654 domain, can be securely transferred by NFC technology. It has very 655 short frequency range - nearly single touch communication. 657 Example: Secure Transfer by Using NFC in Healthcare Services with 658 Tele-Assistance 660 A senior citizen who lives alone wears one to several wearable 6lo 661 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 662 densely installed at home for movement detection. An LoWPAN Border 663 Router (LBR) at home will send the sensed information to a connected 664 healthcare center. Portable base stations with LCDs may be used to 665 check the data at home, as well. Data is gathered in both periodic 666 and event-driven fashion. In this application, event-driven data can 667 be very time-critical. In addition, privacy also becomes a serious 668 issue in this case, as the sensed data is very personal. 670 While the senior citizen is provided audio and video healthcare 671 services by a tele-assistance based on LTE connections, the senior 672 citizen can alternatively use NFC connections to transfer the 673 personal sensed data to the tele-assistance. At this moment, hidden 674 hackers can overhear the data based on the LTE connection, but they 675 cannot gather the personal data over the NFC connection. 677 +-------------+ +-------------+ 678 |voice & video|....... LTE connection ......>|voice & video| 679 | data |<...... LTE connection .......| data | 680 +-------------+ +-------------+ 681 | sensed data |....... NFC connection ......>| | 682 | |<...... NFC connection .......| personal | 683 | | | result data | 684 +-------------+ +-------------+ 685 (patient) (tele-assistance) 687 Figure 1: Alternative Secure Transfer in Healthcare Services 689 Dominant parameters in secure transfer by using NFC in healthcare 690 services: 692 o Deployment/Bootstrapping: Pre-planned. MP2P/P2MP (data 693 collection), P2P (local diagnostic). 695 o Topology: Small, NFC-enabled device connected to the Internet. 697 o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be 698 configured. 700 o Multi-link subnet, single subnet: a single hop for gateway; 701 patient's body network is mesh topology. 703 o Data rate: Small data rate. 705 o Buffering requirements: Low requirement. 707 o Security requirements: Data privacy and security must be provided. 708 Encryption is required. 710 o Mobility: Moderate (patient's mobility). 712 o Time Synchronization: Highly required. 714 o Reliability and QoS: High level of reliability support (life-or- 715 death implication), role-based. 717 o Traffic patterns: Short data length and periodic (randomly). 719 o Security Bootstrapping: Highly required. 721 o Other Issues: Plug-and-play configuration is required for mainly 722 non-technical end-users. Real-time data acquisition and analysis 723 are important. Efficient data management is needed for various 724 devices that have different duty cycles, and for role-based data 725 control. Reliability and robustness of the network are also 726 essential. 728 o Power use strategy: TBD. 730 o Update firmware requirements: TBD. 732 6.6. Use case of LTE MTC 734 Wireless link layer technologies can be divided into short range 735 connectivity and long range connectivity. BLE, ITU-T G.9959 736 (Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity. 737 LTE MTC is used for long range connectivity. And there is another 738 long range connectivity technology. It is LPWAN (Low Power Wide Area 739 Network) technology such as LoRa, Sigfox, etc. Therefore, the use 740 case of LTE MTC could be used in LPWAN. 742 Example: Use of wireless backhaul for LoRa gateway 744 LoRa is one of the most promising technologies of LPWAN. LoRa 745 network architecture has a star of star topology. LoRa gateway relay 746 the messages from LoRa end device to application server and vice 747 versa. LoRa gateway can has two types of backhaul, wired and 748 wireless backhaul. 750 If LoRa gateway has wireless backhaul, it should have LTE modem. 751 Since the modem cost of LTE MTC is cheaper than the modem cost of 752 above LTE category 2, it is helpful to design to use LTE MTC. Since 753 the maximum date rate of LoRa end device is 50kbps, it is sufficient 754 to use LTE MTC without using category 2. 756 Dominant parameters in LoRa gateway scenarios with above example: 758 o Deployment/Bootstrapping: Pre-planned. 760 o Topology: Star topology. 762 o L2-mesh or L3-mesh: No. 764 o Multi-link subnet, single subnet: Single subnet. 766 o Data rate: depends on 3GPP specification. 768 o Buffering requirements: High requirement. 770 o Security requirements: No, because data security is already 771 provided in LoRa specification. 773 o Mobility: Static. 775 o Time Synchronization: Highly required. 777 o Reliability and QoS: TBD. 779 o Traffic patterns: Random. 781 o Security Bootstrapping: required. 783 o Power use strategy: P9 (Always-on). 785 o Update firmware requirements: TBD. 787 Example: Use of controlling car 789 Car sharing services are becoming more popular. Customers wish to 790 control the car with smart phone application. For example, customers 791 wish to lock/unlock the car door with smart phone application, 792 because customers may not have a car key. Customers wish to blow 793 with smart phone application to locate the car easily. 795 Therefore, rental car should have a long range connectivity capable 796 modem such as LoRa end device and LTE UE. However, LoRa may not be 797 used because LoRa has low reliability and may not be supported in an 798 indoor environment such as a basement parking lot. And since message 799 size for car control is very small, it is sufficient to use LTE MTC 800 but category 2. 802 Dominant parameters in controlling car scenarios with above example: 804 o Deployment/Bootstrapping: Pre-planned. 806 o Topology: Star topology. 808 o L2-mesh or L3-mesh: No. 810 o Multi-link subnet, single subnet: Single subnet. 812 o Data rate: depends on 3GPP specification. 814 o Buffering requirements: High requirement. 816 o Security requirements: High requirement. 818 o Mobility: Always dynamic . 820 o Time Synchronization: Highly required. 822 o Reliability and QoS: TBD. 824 o Traffic patterns: Random. 826 o Security Bootstrapping: required. 828 o Power use strategy: P1 (Low-power). 830 6.7. Use case of IEEE 802.15.4e: 832 [TBD] 834 Example: [TBD] 836 7. IANA Considerations 838 There are no IANA considerations related to this document. 840 8. Security Considerations 842 [TBD] 844 9. Acknowledgements 846 Carles Gomez has been funded in part by the Spanish Government 847 (Ministerio de Educacion, Cultura y Deporte) through the Jose 848 Castillejo grant CAS15/00336. His contribution to this work has been 849 carried out in part during his stay as a visiting scholar at the 850 Computer Laboratory of the University of Cambridge. 852 Samita Chakrabarti, Thomas Watteyne, Pascal Thubert, Abdur Rashid 853 Sangi, Xavier Vilajosana, Daniel Migault, and Take Aanstoot have 854 provided valuable feedback for this draft. 856 10. References 858 10.1. Normative References 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 866 over Low-Power Wireless Personal Area Networks (6LoWPANs): 867 Overview, Assumptions, Problem Statement, and Goals", 868 RFC 4919, DOI 10.17487/RFC4919, August 2007, 869 . 871 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 872 "Transmission of IPv6 Packets over IEEE 802.15.4 873 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 874 . 876 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 877 Routing Requirements in Low-Power and Lossy Networks", 878 RFC 5826, DOI 10.17487/RFC5826, April 2010, 879 . 881 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 882 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 883 DOI 10.17487/RFC6282, September 2011, 884 . 886 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 887 Application Spaces for IPv6 over Low-Power Wireless 888 Personal Area Networks (6LoWPANs)", RFC 6568, 889 DOI 10.17487/RFC6568, April 2012, 890 . 892 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 893 Bormann, "Neighbor Discovery Optimization for IPv6 over 894 Low-Power Wireless Personal Area Networks (6LoWPANs)", 895 RFC 6775, DOI 10.17487/RFC6775, November 2012, 896 . 898 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 899 Constrained-Node Networks", RFC 7228, 900 DOI 10.17487/RFC7228, May 2014, 901 . 903 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 904 over ITU-T G.9959 Networks", RFC 7428, 905 DOI 10.17487/RFC7428, February 2015, 906 . 908 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 909 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 910 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 911 . 913 10.2. Informative References 915 [I-D.ietf-6lo-dect-ule] 916 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 917 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 918 Energy", draft-ietf-6lo-dect-ule-07 (work in progress), 919 October 2016. 921 [I-D.ietf-6lo-6lobac] 922 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 923 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 924 6lo-6lobac-05 (work in progress), June 2016. 926 [I-D.ietf-6lo-nfc] 927 Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 928 Packets over Near Field Communication", draft-ietf-6lo- 929 nfc-05 (work in progress), October 2016. 931 [I-D.ietf-lwig-energy-efficient] 932 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 933 Efficient Features of Internet of Things Protocols", 934 draft-ietf-lwig-energy-efficient-05 (work in progress), 935 October 2016. 937 [I-D.ietf-roll-applicability-ami] 938 Cam-Winget, N., Hui, J., and D. Popa, "Applicability 939 Statement for the Routing Protocol for Low Power and Lossy 940 Networks (RPL) in AMI Networks", draft-ietf-roll- 941 applicability-ami-15 (work in progress), October 2016. 943 [G.9959] "International Telecommunication Union, "Short range 944 narrow-band digital radiocommunication transceivers - PHY 945 and MAC layer specifications", ITU-T Recommendation", 946 January 2015. 948 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership 949 Project; Technical Specification Group Radio Access 950 Network; Evolved Universal Terrestrial Radio Access 951 (E-UTRA); User Equipment (UE) radio access capabilities 952 (Release 13)", December 2015. 954 Authors' Addresses 956 Yong-Geun Hong 957 ETRI 958 161 Gajeong-Dong Yuseung-Gu 959 Daejeon 305-700 960 Korea 962 Phone: +82 42 860 6557 963 Email: yghong@etri.re.kr 965 Carles Gomez 966 Universitat Politecnica de Catalunya/Fundacio i2cat 967 C/Esteve Terradas, 7 968 Castelldefels 08860 969 Spain 971 Email: carlesgo@entel.upc.edu 973 Younghwan Choi 974 ETRI 975 218 Gajeongno, Yuseong 976 Daejeon 305-700 977 Korea 979 Phone: +82 42 860 1429 980 Email: yhc@etri.re.kr 981 Deoknyong Ko 982 SKtelecom 983 9-1 Byundang-gu Sunae-dong, Seongnam-si 984 Gyeonggi-do 13595 985 Korea 987 Phone: +82 10 3356 8052 988 Email: engineer@sk.com