idnits 2.17.1 draft-hong-6lo-use-cases-02.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 (July 8, 2016) is 2821 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 813, 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 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-05 == 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-03 == Outdated reference: A later version (-08) exists of draft-ietf-lwig-energy-efficient-04 == Outdated reference: A later version (-15) exists of draft-ietf-roll-applicability-ami-13 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: January 9, 2017 UPC/i2cat 6 Y-H. Choi 7 ETRI 8 D-Y. Ko 9 SKtelecom 10 July 8, 2016 12 IPv6 over Constrained Node Networks(6lo) Applicability & Use cases 13 draft-hong-6lo-use-cases-02 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 spaces 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 January 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 10.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 Running IPv6 on constrained node networks has different features due 95 to the characteristics of constrained node networks such as small 96 packet size, short link-layer address, low bandwidth, network 97 topology, low power, low cost, and large number of devices [RFC4919]. 98 For example, because some IEEE 802.15.4 link layers have a frame size 99 of 127 octets and IPv6 requires an MTU of 1280 bytes, an appropriate 100 fragmentation and reassembly adaptation layer must be provided at the 101 layer of below IPv6. Also, the limited size of IEEE 802.15.4 frame 102 and low energy consumption requirements make the need for header 103 compression. IETF 6lowpan (IPv6 over Low powerWPAN) working group 104 published [RFC4944], an adaptation layer for sending IPv6 packets 105 over IEEE 802.15.4, [RFC6282], compression format for IPv6 datagrams 106 over IEEE 802.15.4-based networks, and [RFC6775], Neighbor Discovery 107 Optimization for 6lowpan. 109 As IoT (Internet of Things) services become more popular, various 110 link layer technologies such as Bluetooth Low Energy (Bluetooth LE), 111 ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - 112 Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near 113 Field Communication (NFC), and LTE Machine Type Communication are 114 actively used. And the need of transmission of IPv6 packets over 115 these link layer technologies is required. A number of IPv6-over-foo 116 documents have been developed in the IETF 6lo (IPv6 over Networks of 117 Resource-constrained Nodes) and 6tisch (IPv6 over the TSCH mode of 118 IEEE 802.15.4e) working group. 120 In the 6lowpan working group, the [RFC6568], "Design and Application 121 Spaces for 6LoWPANs" was published and it describes potential 122 application scenarios and use cases for low-power wireless personal 123 area networks. In this document, various design space dimension such 124 as deployment, network size, power source, connectivity, multi-hop 125 communication, traffic pattern, security level, mobility, and QoS 126 were analyzed. And it described a fundamental set of 6lowpan 127 application scenarios and use cases: Industrial monitoring-Hospital 128 storage rooms, Structural monitoring-Bridge safety monitoring, 129 Connected home-Home Automation, Healthcare-Healthcare at home by 130 tele-assistance, Vehicle telematics-telematics, and Agricultural 131 monitoring-Automated vineyard. 133 Even though the [RFC6568] describes some potential application 134 scenarios and use cases and it lists the design space in the context 135 of 6lowpan, it does not cover the different use cases and design 136 space in the context of the 6lo working group. The RFC6568 assumed 137 that the link layer technology is the IEEE802.15.4 and the described 138 application scenarios and use cases were based on the IEEE 802.15.4 139 technologies. Due to various link layer technologies such as ITU-T 140 G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, and IEEE 141 802.15.4e(6tisch), potential application possible scenarios and use 142 cases of 6lo will go beyond over the RFC6568. 144 This document provides the use cases of 6lo, considering the 145 following: 147 o 6lo applicability and use cases MAY be uniquely different to those 148 of 6lowpan. 150 o 6lo applicability and use cases SHOULD cover various IoT related 151 wire/wireless link layer technologies providing practical 152 information of such technologies. 154 o 6lo applicability and use cases MAY describe characteristics and 155 typical use cases of each link layer technology, and then 6lo use 156 cases's applicability. 158 2. Conventions and Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 3. 6lo Link layer technologies 166 3.1. ITU-T G.9959 168 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 169 Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID 170 network identifier is assigned by a network controller and how an 171 8-bit NodeID host identifier is allocated to each node. NodeIDs are 172 unique within the network identified by the HomeID. The G.9959 173 HomeID represents an IPv6 subnet that is identified by one or more 174 IPv6 prefixes [RFC7428]. 176 3.2. Bluetooth Low Energy 178 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 179 4.1, and developed even further in successive versions. Bluetooth 180 SIG has also published Internet Protocol Support Profile (IPSP). The 181 IPSP enables discovery of IP-enabled devices and establishment of 182 link-layer connection for transporting IPv6 packets. IPv6 over 183 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 184 newer. 186 Devices such as mobile phones, notebooks, tablets and other handheld 187 computing devices which will include Bluetooth 4.1 chipsets will also 188 have the low-energy variant of Bluetooth. Bluetooth LE will also be 189 included in many different types of accessories that collaborate with 190 mobile devices such as phones, tablets and notebook computers. An 191 example of a use case for a Bluetooth LE accessory is a heart rate 192 monitor that sends data via the mobile phone to a server on the 193 Internet [RFC7668]. 195 3.3. DECT-ULE 197 DECT ULE is a low power air interface technology that is designed to 198 support both circuit switched services, such as voice communication, 199 and packet mode data services at modest data rate. 201 The DECT ULE protocol stack consists of the PHY layer operating at 202 frequencies in the 1880 - 1920 MHz frequency band depending on the 203 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 204 allocated by use of FDMA/TDMA/TDD technics. 206 In its generic network topology, DECT is defined as a cellular 207 network technology. However, the most common configuration is a star 208 network with a single Fixed Parts (FP) defining the network with a 209 number of Portable Parts (PP) attached. The MAC layer supports 210 traditional DECT as this is used for services like discovery, 211 pairing, security features etc. All these features have been reused 212 from DECT. 214 The DECT ULE device can switch to the ULE mode of operation, 215 utilizing the new ULE MAC layer features. The DECT ULE Data Link 216 Control (DLC) provides multiplexing as well as segmentation and re- 217 assembly for larger packets from layers above. The DECT ULE layer 218 also implements per-message authentication and encryption. The DLC 219 layer ensures packet integrity and preserves packet order, but 220 delivery is based on best effort. 222 The current DECT ULE MAC layer standard supports low bandwidth data 223 broadcast. However the usage of this broadcast service has not yet 224 been standardized for higher layers [I-D.ietf-6lo-dect-ule]. 226 3.4. Master-Slave/Token-Passing 228 MS/TP is a contention-free access method for the RS-485 physical 229 layer, which is used extensively in building automation networks. 230 This specification defines the frame format for transmission of IPv6 231 [RFC2460] packets and the method of forming link-local and 232 statelessly autoconfigured IPv6 addresses on MS/TP networks. The 233 general approach is to adapt elements of the 6LoWPAN [RFC4944] 234 specification to constrained wired networks. 236 An MS/TP device is typically based on a low-cost microcontroller with 237 limited processing power and memory. Together with low data rates 238 and a small address space, these constraints are similar to those 239 faced in 6LoWPAN networks and suggest some elements of that solution 240 might be leveraged. MS/TP differs significantly from 6LoWPAN in at 241 least three respects: a) MS/TP devices typically have a continuous 242 source of power, b) all MS/TP devices on a segment can communicate 243 directly so there are no hidden node or mesh routing issues, and c) 244 recent changes to MS/TP provide support for large payloads, 245 eliminating the need for link-layer fragmentation and reassembly. 247 MS/TP is designed to enable multidrop networks over shielded twisted 248 pair wiring. It can support a data rate of 115,200 baud on segments 249 up to 1000 meters in length, or segments up to 1200 meters in length 250 at lower baud rates. An MS/TP link requires only a UART, an RS-485 251 transceiver with a driver that can be disabled, and a 5ms resolution 252 timer. These features make MS/TP a cost-effective field bus for the 253 most numerous and least expensive devices in a building automation 254 network [I-D.ietf-6lo-6lobac]. 256 3.5. NFC 258 NFC technology enables simple and safe two-way interactions between 259 electronic devices, allowing consumers to perform contactless 260 transactions, access digital content, and connect electronic devices 261 with a single touch. NFC complements many popular consumer level 262 wireless technologies, by utilizing the key elements in existing 263 standards for contactless card technology (ISO/IEC 14443 A&B and 264 JIS-X 6319-4). NFC can be compatible with existing contactless card 265 infrastructure and it enables a consumer to utilize one device across 266 different systems. 268 Extending the capability of contactless card technology, NFC also 269 enables devices to share information at a distance that is less than 270 10 cm with a maximum communication speed of 424 kbps. Users can 271 share business cards, make transactions, access information from a 272 smart poster or provide credentials for access control systems with a 273 simple touch. 275 NFC's bidirectional communication ability is ideal for establishing 276 connections with other technologies by the simplicity of touch. In 277 addition to the easy connection and quick transactions, simple data 278 sharing is also available [I-D.ietf-6lo-nfc]. 280 3.6. LTE MTC 282 LTE category defines the overall performance and capabilities of the 283 UE(User Equipment). For example, the maximum down rate of category 1 284 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 285 There are many categories in LTE standard. 3GPP standards defined the 286 category 0 to be used for low rate IoT service in release 12. Since 287 category 1 and category 0 could be used for low rate IoT service, we 288 call LTE MTC[LTE_MTC]. 290 LTE MTC have the advantages compared to above category 2 to be used 291 for low rate IoT service such as low power and low cost. 293 The below figure shows the primary characteristics of LTE MTC. 295 +------------+---------------------+-------------------+ 296 | Category | Max. Date Rate Down | Max. Date Rate Up | 297 +------------+---------------------+-------------------+ 298 | Category 0 | 1.0 Mbit/s | 1.0 Mbit/s | 299 | | | | 300 | Category 1 | 10.3 Mbit/s | 5.2 Mbit/s | 301 +------------+---------------------+-------------------+ 303 Table 1: Primary characteristics of LTE MTC 305 3.7. IEEE 802.15.4e 307 The Timeslotted Channel Hopping (TSCH) mode was introduced in the 308 IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are 309 synchronized. Time is sliced up into timeslots. The duration of a 310 timeslot, typically 10ms, is large enough for a node to send a full- 311 sized frame to its neighbor, and for that neighbor to send back an 312 acknowledgment to indicate successful reception. Timeslot are 313 grouped into one of more slotframes, which repeat over time. 315 All the communication in the network is orchestrated by a 316 communication schedule which indicates to each node what to do in 317 each of the timeslots of a slotframe: transmit, listen or sleep. The 318 communication schedule can be built so that the right amount of link- 319 layer resources (the cells in the schedule) are scheduled to satisfy 320 the communication needs of the applications running on the network, 321 while keeping the energy consumption of the nodes very low. Cells 322 can be scheduled in a collision-free way, introducing a high level of 323 determinism to the network. 325 A TSCH network exploits channel hopping: subsequent packets exchanged 326 between neighbor nodes are done so on a different frequency. This 327 means that, if a frame isn't received, the transmitter node will re- 328 transmitted the frame on a different frequency. The resulting 329 "channel hopping" efficiently combats external interference and 330 multi-path fading. 332 The main benefits of IEEE 802.15.4 TSCH are: 334 - ultra high reliability. Off-the-shelf commercial products offer 335 over 99.999% end-to-end reliability. 337 - ultra low-power consumption. Off-the-shelf commercial products 338 offer over a decade of battery lifetime. 340 4. 6lo Deployment Scenarios 342 In this clause, we will describe some 6lo deployment scenrios such as 343 Smart Grid activity in WiSun 345 [TBD] 347 5. Design Space 349 The [RFC6568] lists the dimensions used to describe the design space 350 of wireless sensor networks in the context of the 6LoWPAN working 351 group. The design space is already limited by the unique 352 characteristics of a LoWPAN (e.g., low power, short range, low bit 353 rate). In the RFC 6568, the following design space dimensions are 354 described; Deployment, Network size, Power source, Connectivity, 355 Multi-hop communication, Traffic pattern, Mobility, Quality of 356 Service (QoS). 358 The design space dimensions of 6lo are a little different to those of 359 the RFC 6568 due to the different characteristics of 6lo link layer 360 technologies. The following design space dimensions can be 361 considered. 363 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 364 in an organized manner. The bootstrapping has different 365 characteristics of each link layer technologies. 367 o Topology: Topology of 6lo networks may inherently follow the 368 characteristics of each link layer technology. Point-to-point, 369 star, tree or mesh topologies can be configured. 371 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 372 characteristics of each link layer technologies. Some link layer 373 technologies may support L2-mesh and some may not support. 375 o Multi-link subnet, single subnet: The selection of multi-link 376 subnet and single subnet depends on connectivity and the number of 377 6lo nodes. 379 o Data rate: Originally, the link layer technologies of 6lo have low 380 rate of data transmission. But, by adjusting the MTU, it can 381 deliver higher data rate. 383 o Buffering requirements: Some 6lo use case may require more data 384 rate than the link layer technology support. In this case, a 385 buffering mechanism to manage the date is required. 387 o Security Requirements: Some 6lo use case can transfer some 388 important and personal data between 6lo nodes. In this case, 389 high-level security support is required. 391 o Mobility across 6lo networks and subnets: The movement of 6lo 392 nodes is dependent on the 6lo use case. If the 6lo nodes can move 393 or moved around, it requires the mobility management mechanism. 395 o Time synchronization requirements: The requirement of time 396 synchronization of the upper layer service is dependent on the 6lo 397 use case. For some 6lo use case related to health service, the 398 measured data must be recorded with exact time and must be 399 transferred with time synchronization. 401 o Reliability and QoS: Some 6lo use case requires high reliability, 402 for example real-time service or health-related services. 404 o Traffic patterns: 6lo use case may various traffic patterns. Some 405 6lo use case may require short data length and randomly. Some 6lo 406 use case may require continuous data and periodic data 407 transmission. 409 o Security Bootstrapping: Without the external operations, 6lo nodes 410 must have the security bootstrapping mechanism. 412 o Power use strategy: to enable certain use cases, there may be 413 requirements on the class of energy availability and the strategy 414 followed for using power for communication [RFC7228]. Each link 415 layer technology defines a particular power use strategy which may 416 be tuned [I-D.ietf-lwig-energy-efficient]. 418 o Energy limitation: The energy limitation class [RFC7228] is 419 specific to each use case, and may or may not be related to the 420 power use strategy. 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 6.2. Use case of Bluetooth Low Energy: Smartphone-Based Interaction 491 with Constrained Devices 493 The key feature behind the current high Bluetooth LE momentum is its 494 support in a large majority of smartphones in the market. Bluetooth 495 LE can be used to allow the interaction between the smartphone and 496 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 497 the main radio interface currently available in wearables. Since a 498 smartphone typically has several radio interfaces that provide 499 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 500 gateway for nearby devices such as sensors, actuators or wearables. 501 Bluetooth LE may be used in several domains, including healthcare, 502 sports/wellness and home automation. 504 Example: Bluetooth LE-based Body Area Network for fitness 506 A person wears a smartwatch for fitness purposes. The smartwatch has 507 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 508 temperature, etc.), a display, and a Bluetooth LE radio interface. 509 The smartwatch can show fitness-related statistics on its display. 510 However, when a paired smartphone is in the range of the smartwatch, 511 the latter can report almost real-time measurements of its sensors to 512 the smartphone, which can forward the data to a cloud service on the 513 Internet. In addition, the smartwatch can receive notifications 514 (e.g. alarm signals) from the cloud service via the smartphone. On 515 the other hand, the smartphone may locally generate messages for the 516 smartwatch, such as e-mail reception or calendar notifications. 518 The functionality supported by the smartwatch may be complemented by 519 other devices such as other on-body sensors, wireless headsets or 520 head-mounted displays. All such devices may connect to the 521 smartphone creating a star topology network whereby the smartphone is 522 the central component. 524 Dominant parameters in home automation scenarios with Bluetooth LE: 526 o Deployment/Bootstrapping: Pre-planned. 528 o Topology: Star topology. 530 o L2-mesh or L3-mesh: No. 532 o Multi-link subnet, single subnet: Multi-link subnet. 534 o Data rate: TBD. 536 o Buffering requirements: Low requirement. 538 o Security requirements: For health-critical information, data 539 privacy and security must be provided. Encryption is required. 540 Some types of notifications sent by the smartphone may not need. 542 o Mobility: Low. 544 o Time Synchronization: the link layer, which is based on TDMA, 545 provides a basis for time synchronization. 547 o Reliability and QoS: a relatively low ratio of message losses is 548 acceptable for periodic sensor readings. End-to-end latency of 549 sensor readings should be low for critical notifications or 550 alarms, generated by either the smartphone or an Internet cloud 551 service. 553 o Traffic patterns: periodic (sensor readings) and aperiodic 554 (smartphone-generated notifications). 556 o Security Bootstrapping: Required. 558 6.3. Use case of DECT-ULE: Smart Home 560 DECT is a technology widely used for wireless telephone 561 communications in residential scenarios. Since DECT-ULE is a low- 562 power variant of DECT, DECT-ULE can be used to connect constrained 563 devices such as sensors and actuators to a Fixed Part, a device that 564 typically acts as a base station for wireless telephones. Therefore, 565 DECT-ULE is specially suitable for the connected home space in 566 application areas such as home automation, smart metering, safety, 567 healthcare, etc. 569 Example: use of DECT-ULE for Smart Metering 571 The smart electricity meter of a home is equipped with a DECT-ULE 572 transceiver. This device is in the coverage range of the Fixed Part 573 of the home. The Fixed Part can act as a router connected to the 574 Internet. This way, the smart meter can transmit electricity 575 consumption readings through the DECT-ULE link with the Fixed Part, 576 and the latter can forward such readings to the utility company using 577 Wide Area Network (WAN) links. The meter can also receive queries 578 from the utility company or from an advanced energy control system 579 controlled by the user, which may also be connected to the Fixed Part 580 via DECT-ULE. 582 Dominant parameters in smart metering scenarios with DECT-ULE: 584 o Deployment/Bootstrapping: Pre-planned. 586 o Topology: Star topology. 588 o L2-mesh or L3-mesh: No. 590 o Multi-link subnet, single subnet: Multi-link subnet. 592 o Data rate: Small data rate, infrequent transmissions. 594 o Buffering requirements: Low requirement. 596 o Security requirements: Data privacy and security must be provided. 597 Encryption is required. 599 o Mobility: No. 601 o Time Synchronization: TBD. 603 o Reliability and QoS: bounded latency, stringent reliability 604 service agreements [I-D.ietf-roll-applicability-ami]. 606 o Traffic patterns: Periodic (meter reading notifications sent by 607 the meter) and aperiodic (user- or company-triggered queries to 608 the meter, and messages triggered by local events such as power 609 outage or leak detection [I-D.ietf-roll-applicability-ami]). 611 o Security Bootstrapping: required. 613 6.4. Use case of MS/TP: 615 [TBD] 617 Example: [TBD] 619 6.5. Use case of NFC: Alternative Secure Transfer 621 According to applications, various secured data can be handled and 622 transferred. Depending on security level of the data, methods for 623 transfer can be alternatively selected. The personal data having 624 serious issues should be transferred securely, but data transfer by 625 using Wi-Fi and Bluetooth connections cannot always be secure because 626 of their a little long radio frequency range. Hackers can overhear 627 the personal data transfer behind hidden areas. Therefore, methods 628 need to be alternatively selected to transfer secured data. Voice 629 and video data, which are not respectively secure and requires long 630 transmission range, can be transferred by 3G/4G technologies, such as 631 WCDMA, GSM, and LTE. Big size data, which are not secure and 632 requires high speed and broad bandwidth, can be transferred by Wi-Fi 633 and wired network technologies. However, the personal data, which 634 pose serious issues if mishandled while transferred in wireless 635 domain, can be securely transferred by NFC technology. It has very 636 short frequency range - nearly single touch communication. 638 Example: Secure Transfer by Using NFC in Healthcare Services with 639 Tele-Assistance 641 A senior citizen who lives alone wears one to several wearable 6lo 642 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 643 densely installed at home for movement detection. An LoWPAN Border 644 Router (LBR) at home will send the sensed information to a connected 645 healthcare center. Portable base stations with LCDs may be used to 646 check the data at home, as well. Data is gathered in both periodic 647 and event-driven fashion. In this application, event-driven data can 648 be very time-critical. In addition, privacy also becomes a serious 649 issue in this case, as the sensed data is very personal. 651 While the senior citizen is provided audio and video healthcare 652 services by a tele-assistance based on LTE connections, the senior 653 citizen can alternatively use NFC connections to transfer the 654 personal sensed data to the tele-assistance. At this moment, hidden 655 hackers can overhear the data based on the LTE connection, but they 656 cannot gather the personal data over the NFC connection. 658 +-------------+ +-------------+ 659 |voice & video|....... LTE connection ......>|voice & video| 660 | data |<...... LTE connection .......| data | 661 +-------------+ +-------------+ 662 | sensed data |....... NFC connection ......>| | 663 | |<...... NFC connection .......| personal | 664 | | | result data | 665 +-------------+ +-------------+ 666 (patient) (tele-assistance) 668 Figure 1: Alternative Secure Transfer in Healthcare Services 670 Dominant parameters in secure transfer by using NFC in healthcare 671 services: 673 o Deployment/Bootstrapping: Pre-planned. MP2P/P2MP (data 674 collection), P2P (local diagnostic). 676 o Topology: Small, NFC-enabled device connected to the Internet. 678 o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be 679 configured. 681 o Multi-link subnet, single subnet: a Single-hop for gateway; 682 patient's body network is mesh topology. 684 o Data rate: Small data rate. 686 o Buffering requirements: Low requirement. 688 o Security requirements: Data privacy and security must be provided. 689 Encryption is required. 691 o Mobility: Moderate (patient's mobility). 693 o Time Synchronization: Highly required. 695 o Reliability and QoS: High level of reliability support (life-or- 696 death implication), role-based. 698 o Traffic patterns: Short data length and periodic (randomly). 700 o Security Bootstrapping: Highly required. 702 o Other Issues: Plug-and-play configuration is required for mainly 703 non-technical end-users. Real-time data acquisition and analysis 704 are important. Efficient data management is needed for various 705 devices that have different duty cycles, and for role-based data 706 control. Reliability and robustness of the network are also 707 essential. 709 6.6. Use case of LTE MTC 711 Wireless link layer technologies can be divided short range 712 connectivity and long range connectivity. BLE, ITU-T G.9959 713 (Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity. 714 LTE MTC is used for long range connectivity. And there is another 715 long range connectivity technology. It is LPWAN(Low Power Wide Area 716 Network) technology such as LoRa, Sigfox and etc. Therefore, the use 717 case of LTE MTC could be used in LPWAN. 719 Example: Use of wireless backhaul for LoRa gateway 721 LoRa is the most promising technology of LPWAN. LoRa network 722 architecture has a star of star topology. LoRa gateway relay the 723 messages from LoRa end device to application server and vice versa. 724 LoRa gateway can has two types of backhaul, wired and wireless 725 backhaul. 727 If LoRa gateway has wireless backhaul, it should have LTE modem. 728 Since the modem cost of LTE MTC is cheaper than the modem cost of 729 above LTE category 2, it is helpful to design to use LTE MTC. Since 730 the maximum date rate of LoRa end device is 50kbps, it is sufficient 731 to use LTE MTC without using category 2. 733 Dominant parameters in LoRa gateway scenarios with above example: 735 o Deployment/Bootstrapping: Pre-planned. 737 o Topology: Star topology. 739 o L2-mesh or L3-mesh: No. 741 o Multi-link subnet, single subnet: Single subnet. 743 o Data rate: depends on 3GPP specification. 745 o Buffering requirements: High requirement. 747 o Security requirements: No, because data security is already 748 provided in LoRa specification. 750 o Mobility: Static. 752 o Time Synchronization: Highly required. 754 o Reliability and QoS: TBD. 756 o Traffic patterns: Random. 758 o Security Bootstrapping: required. 760 Example: Use of controlling car 762 Car sharing service becomes more popular. Customers wish to control 763 the car with smart phone application. For example, customers wish to 764 lock/unlock the car door with smart phone application, because 765 customers may not have a car key. Customers wish to blow with smart 766 phone application to locate the car easily. 768 Therefore, rental car should have a long range connectivity capable 769 modem such as LoRa end device and LTE UE. However, LoRa may not be 770 used because LoRa has low reliability and may not is supported in 771 indoor environment such as basement parking lot. And since the 772 message of controlling car is very small, it is sufficient to use LTE 773 MTC but above category 2. 775 Dominant parameters in controlling car scenarios with above example: 777 o Deployment/Bootstrapping: Pre-planned. 779 o Topology: Star topology. 781 o L2-mesh or L3-mesh: No. 783 o Multi-link subnet, single subnet: Single subnet. 785 o Data rate: depends on 3GPP specification. 787 o Buffering requirements: High requirement. 789 o Security requirements: High requirement. 791 o Mobility: Always dynamic . 793 o Time Synchronization: Highly required. 795 o Reliability and QoS: TBD. 797 o Traffic patterns: Random. 799 o Security Bootstrapping: required. 801 6.7. Use case of IEEE 802.15.4e: 803 [TBD] 805 Example: [TBD] 807 7. IANA Considerations 809 There are no IANA considerations related to this document. 811 8. Security Considerations 813 [TBD] 815 9. Acknowledgements 817 Carles Gomez has been funded in part by the Spanish Government 818 (Ministerio de Educacion, Cultura y Deporte) through the Jose 819 Castillejo grant CAS15/00336. His contribution to this work has been 820 carried out during his stay as a visiting scholar at the Computer 821 Laboratory of the University of Cambridge. 823 10. References 825 10.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 833 over Low-Power Wireless Personal Area Networks (6LoWPANs): 834 Overview, Assumptions, Problem Statement, and Goals", 835 RFC 4919, DOI 10.17487/RFC4919, August 2007, 836 . 838 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 839 "Transmission of IPv6 Packets over IEEE 802.15.4 840 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 841 . 843 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 844 Routing Requirements in Low-Power and Lossy Networks", 845 RFC 5826, DOI 10.17487/RFC5826, April 2010, 846 . 848 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 849 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 850 DOI 10.17487/RFC6282, September 2011, 851 . 853 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 854 Application Spaces for IPv6 over Low-Power Wireless 855 Personal Area Networks (6LoWPANs)", RFC 6568, 856 DOI 10.17487/RFC6568, April 2012, 857 . 859 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 860 Bormann, "Neighbor Discovery Optimization for IPv6 over 861 Low-Power Wireless Personal Area Networks (6LoWPANs)", 862 RFC 6775, DOI 10.17487/RFC6775, November 2012, 863 . 865 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 866 Constrained-Node Networks", RFC 7228, 867 DOI 10.17487/RFC7228, May 2014, 868 . 870 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 871 over ITU-T G.9959 Networks", RFC 7428, 872 DOI 10.17487/RFC7428, February 2015, 873 . 875 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 876 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 877 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 878 . 880 10.2. Informative References 882 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 883 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 884 December 1998, . 886 [I-D.ietf-6lo-dect-ule] 887 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 888 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 889 Energy", draft-ietf-6lo-dect-ule-05 (work in progress), 890 May 2016. 892 [I-D.ietf-6lo-6lobac] 893 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 894 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 895 6lo-6lobac-05 (work in progress), June 2016. 897 [I-D.ietf-6lo-nfc] 898 Hong, Y. and J. Youn, "Transmission of IPv6 Packets over 899 Near Field Communication", draft-ietf-6lo-nfc-03 (work in 900 progress), March 2016. 902 [I-D.ietf-lwig-energy-efficient] 903 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 904 Efficient Features of Internet of Things Protocols", 905 draft-ietf-lwig-energy-efficient-04 (work in progress), 906 February 2016. 908 [I-D.ietf-roll-applicability-ami] 909 Cam-Winget, N., Hui, J., and D. Popa, "Applicability 910 Statement for the Routing Protocol for Low Power and Lossy 911 Networks (RPL) in AMI Networks", draft-ietf-roll- 912 applicability-ami-13 (work in progress), April 2016. 914 [G.9959] "International Telecommunication Union, "Short range 915 narrow-band digital radiocommunication transceivers - PHY 916 and MAC layer specifications", ITU-T Recommendation", 917 January 2015. 919 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership 920 Project; Technical Specification Group Radio Access 921 Network; Evolved Universal Terrestrial Radio Access 922 (E-UTRA); User Equipment (UE) radio access capabilities 923 (Release 13)", December 2015. 925 Authors' Addresses 927 Yong-Geun Hong 928 ETRI 929 161 Gajeong-Dong Yuseung-Gu 930 Daejeon 305-700 931 Korea 933 Phone: +82 42 860 6557 934 Email: yghong@etri.re.kr 936 Carles Gomez 937 Universitat Politecnica de Catalunya/Fundacio i2cat 938 C/Esteve Terradas, 7 939 Castelldefels 08860 940 Spain 942 Email: carlesgo@entel.upc.edu 943 Younghwan Choi 944 ETRI 945 218 Gajeongno, Yuseong 946 Daejeon 305-700 947 Korea 949 Phone: +82 42 860 1429 950 Email: yhc@etri.re.kr 952 Deoknyong Ko 953 SKtelecom 954 9-1 Byundang-gu Sunae-dong, Seongnam-si 955 Gyeonggi-do 13595 956 Korea 958 Phone: +82 10 3356 8052 959 Email: engineer@sk.com