idnits 2.17.1 draft-ietf-6lo-use-cases-01.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 (March 12, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 1144, but not defined == 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 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-00 == 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: 0 errors (**), 0 flaws (~~), 9 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: Informational C. Gomez 5 Expires: September 13, 2017 UPC/i2cat 6 Y-H. Choi 7 ETRI 8 D-Y. Ko 9 SKtelecom 10 AR. Sangi 11 Huawei Technologies 12 Take. Aanstoot 13 Modio AB 14 March 12, 2017 16 IPv6 over Constrained Node Networks(6lo) Applicability & Use cases 17 draft-ietf-6lo-use-cases-01 19 Abstract 21 This document describes the applicability of IPv6 over constrained 22 node networks (6lo) and use cases. It describes the practical 23 deployment scenarios of 6lo technologies with the consideration of 24 6lo link layer technologies and identifies the requirements. In 25 addition to IEEE 802.15.4, various link layer technologies such as 26 ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, PLC (IEEE 27 1901), and IEEE 802.15.4e(6tisch) are widely used at constrained node 28 networks for typical services. Based on these link layer 29 technologies, IPv6 over networks of resource-constrained nodes has 30 various and practical use cases. To efficiently implement typical 31 services, the applicability and consideration of several design space 32 dimensions are described. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 69 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 70 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4 72 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.7. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.8. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . 8 78 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9 79 5. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 11 82 6.2. Use case of Bluetooth LE: Smartphone-Based Interaction 83 with Constrained Devices . . . . . . . . . . . . . . . . 13 84 6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 14 85 6.4. Use case of MS/TP: Management of District Heating . . . . 15 86 6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 17 87 6.6. Use case of LTE MTC: Gateway for Wireless Backhaul 88 Network . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.7. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 21 90 6.8. Use case of IEEE 802.15.4e: Industrial Automation . . . . 24 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 96 10.2. Informative References . . . . . . . . . . . . . . . . . 27 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Introduction 101 Running IPv6 on constrained node networks has different features from 102 general node networks due to the characteristics of constrained node 103 networks such as small packet size, short link-layer address, low 104 bandwidth, network topology, low power, low cost, and large number of 105 devices [RFC4919]. For example, because some IEEE 802.15.4 link 106 layers have a frame size of 127 octets and IPv6 requires the layer 107 below to support an MTU of 1280 bytes, an appropriate fragmentation 108 and reassembly adaptation layer must be provided at the layer below 109 IPv6. Also, the limited size of IEEE 802.15.4 frame and low energy 110 consumption requirements make the need for header compression. IETF 111 6lowpan (IPv6 over Low powerWPAN) working group published, an 112 adaptation layer for sending IPv6 packets over IEEE 802.15.4 113 [RFC4944], compression format for IPv6 datagrams over IEEE 114 802.15.4-based networks [RFC6282], and Neighbor Discovery 115 Optimization for 6lowpan [RFC6775]. 117 As IoT (Internet of Things) services become more popular, various 118 link layer technologies such as Bluetooth Low Energy (Bluetooth LE), 119 ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - 120 Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near 121 Field Communication (NFC), Power Line Communication (PLC), and LTE 122 Machine Type Communication are actively used. And the transmission 123 of IPv6 packets over these link layer technologies is required. A 124 number of IPv6-over-foo documents have been developed in the IETF 6lo 125 (IPv6 over Networks of Resource-constrained Nodes) and 6tisch (IPv6 126 over the TSCH mode of IEEE 802.15.4e) working groups. 128 In the 6lowpan working group, the [RFC6568], "Design and Application 129 Spaces for 6LoWPANs" was published and it describes potential 130 application scenarios and use cases for low-power wireless personal 131 area networks. In this document, various design space dimensions 132 such as deployment, network size, power source, connectivity, multi- 133 hop communication, traffic pattern, security level, mobility, and QoS 134 were analyzed. And it described a fundamental set of 6lowpan 135 application scenarios and use cases: Industrial monitoring-Hospital 136 storage rooms, Structural monitoring-Bridge safety monitoring, 137 Connected home-Home automation and Smart grid assistance, Healthcare- 138 Healthcare at home by tele-assistance, Vehicle telematics-telematics, 139 and Agricultural monitoring-Automated vineyard. 141 Even though the [RFC6568] describes some potential application 142 scenarios and use cases and it lists the design space in the context 143 of 6lowpan, it does not cover the different use cases and design 144 space in the context of the 6lo working group. The [RFC6568] assumed 145 that the link layer technology is the IEEE802.15.4 and the described 146 application scenarios and use cases were based on the IEEE 802.15.4 147 technologies. Due to various link layer technologies such as ITU-T 148 G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, Power Line 149 Communication (PLC), and IEEE 802.15.4e(6tisch), potential 150 application scenarios and use cases of 6lo will go beyond the 151 [RFC6568]. 153 This document provides the applicability and use cases of 6lo, 154 considering the following aspects: 156 o 6lo applicability and use cases MAY be uniquely different from 157 those of 6lowpan. 159 o 6lo applicability and use cases SHOULD cover various IoT related 160 wire/wireless link layer technologies providing practical 161 information of such technologies. 163 o 6lo applicability and use cases SHOULD describe characteristics 164 and typical use cases of each link layer technology, and then 6lo 165 use cases's applicability. 167 2. Conventions and Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. 6lo Link layer technologies 175 3.1. ITU-T G.9959 177 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 178 Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID 179 network identifier is assigned by a network controller and how an 180 8-bit NodeID host identifier is allocated to each node. NodeIDs are 181 unique within the network identified by the HomeID. The G.9959 182 HomeID represents an IPv6 subnet that is identified by one or more 183 IPv6 prefixes [RFC7428]. 185 3.2. Bluetooth LE 187 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 188 4.1, and developed even further in successive versions. Bluetooth 189 SIG has also published Internet Protocol Support Profile (IPSP). The 190 IPSP enables discovery of IP-enabled devices and establishment of 191 link-layer connection for transporting IPv6 packets. IPv6 over 192 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 193 newer. 195 Devices such as mobile phones, notebooks, tablets and other handheld 196 computing devices which will include Bluetooth 4.1 chipsets will 197 probably also have the low-energy variant of Bluetooth. Bluetooth LE 198 will also be included in many different types of accessories that 199 collaborate with mobile devices such as phones, tablets and notebook 200 computers. An example of a use case for a Bluetooth LE accessory is 201 a heart rate monitor that sends data via the mobile phone to a server 202 on the Internet [RFC7668]. 204 3.3. DECT-ULE 206 DECT ULE is a low power air interface technology that is designed to 207 support both circuit switched services, such as voice communication, 208 and packet mode data services at modest data rate. 210 The DECT ULE protocol stack consists of the PHY layer operating at 211 frequencies in the 1880 - 1920 MHz frequency band depending on the 212 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 213 allocated by use of FDMA/TDMA/TDD techniques. 215 In its generic network topology, DECT is defined as a cellular 216 network technology. However, the most common configuration is a star 217 network with a single Fixed Part (FP) defining the network with a 218 number of Portable Parts (PP) attached. The MAC layer supports 219 traditional DECT as this is used for services like discovery, 220 pairing, security features etc. All these features have been reused 221 from DECT. 223 The DECT ULE device can switch to the ULE mode of operation, 224 utilizing the new ULE MAC layer features. The DECT ULE Data Link 225 Control (DLC) provides multiplexing as well as segmentation and re- 226 assembly for larger packets from layers above. The DECT ULE layer 227 also implements per-message authentication and encryption. The DLC 228 layer ensures packet integrity and preserves packet order, but 229 delivery is based on best effort. 231 The current DECT ULE MAC layer standard supports low bandwidth data 232 broadcast. However the usage of this broadcast service has not yet 233 been standardized for higher layers [I-D.ietf-6lo-dect-ule]. 235 3.4. MS/TP 237 MS/TP is a contention-free access method for the RS-485 physical 238 layer, which is used extensively in building automation networks. 240 An MS/TP device is typically based on a low-cost microcontroller with 241 limited processing power and memory. Together with low data rates 242 and a small address space, these constraints are similar to those 243 faced in 6lowpan networks and suggest some elements of that solution 244 might be leveraged. MS/TP differs significantly from 6lowpan in at 245 least three aspects: a) MS/TP devices typically have a continuous 246 source of power, b) all MS/TP devices on a segment can communicate 247 directly so there are no hidden node or mesh routing issues, and c) 248 recent changes to MS/TP provide support for large payloads, 249 eliminating the need for link-layer fragmentation and reassembly. 251 MS/TP is designed to enable multidrop networks over shielded twisted 252 pair wiring, although not according to standards, in lower speeds, 253 normally 9600 bit/s, re-purposed telecom wiring is widely in use, 254 keeping deployment cost down. It can support a data rate of 115,200 255 baud on segments up to 1000 meters in length, or segments up to 1200 256 meters in length at lower baud rates. An MS/TP link requires only a 257 UART, an RS-485 transceiver with a driver that can be disabled, and a 258 5ms resolution timer. These features make MS/TP a cost-effective and 259 very reliable field bus for the most numerous and least expensive 260 devices in a building automation network [I-D.ietf-6lo-6lobac]. 262 3.5. NFC 264 NFC technology enables simple and safe two-way interactions between 265 electronic devices, allowing consumers to perform contactless 266 transactions, access digital content, and connect electronic devices 267 with a single touch. NFC complements many popular consumer level 268 wireless technologies, by utilizing the key elements in existing 269 standards for contactless card technology (ISO/IEC 14443 A&B and 270 JIS-X 6319-4). NFC can be compatible with existing contactless card 271 infrastructure and it enables a consumer to utilize one device across 272 different systems. 274 Extending the capability of contactless card technology, NFC also 275 enables devices to share information at a distance that is less than 276 10 cm with a maximum communication speed of 424 kbps. Users can 277 share business cards, make transactions, access information from a 278 smart poster or provide credentials for access control systems with a 279 simple touch. 281 NFC's bidirectional communication ability is ideal for establishing 282 connections with other technologies by the simplicity of touch. In 283 addition to the easy connection and quick transactions, simple data 284 sharing is also available [I-D.ietf-6lo-nfc]. 286 3.6. LTE MTC 288 LTE category defines the overall performance and capabilities of the 289 UE(User Equipment). For example, the maximum down rate of category 1 290 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 291 There are many categories in LTE standard. 3GPP standards defined the 292 category 0 to be used for low rate IoT service in release 12. Since 293 category 1 and category 0 could be used for low rate IoT service, 294 these categories are called LTE MTC (Machine Type Communication) 295 [LTE_MTC]. 297 LTE MTC offer advantages in comparison to above category 2 and is 298 appropriate to be used for low rate IoT services such as low power 299 and low cost. 301 The below figure shows the primary characteristics of LTE MTC. 303 +------------+---------------------+-------------------+ 304 | Category | Max. Data Rate Down | Max. Data Rate Up | 305 +------------+---------------------+-------------------+ 306 | Category 0 | 1.0 Mbit/s | 1.0 Mbit/s | 307 | | | | 308 | Category 1 | 10.3 Mbit/s | 5.2 Mbit/s | 309 +------------+---------------------+-------------------+ 311 Table 1: Primary characteristics of LTE MTC 313 3.7. PLC 315 Unlike other dedicated communication infrastructure, the required 316 medium (power conductor) is widely available indoors and outdoors. 317 Moreover, wire d technologies are more susceptible to cause 318 interference but are more rel iable than their wireless counterparts. 319 PLC is a data transmission techniq ue that utilizes power conductors 320 as medium. 322 The below figure shows some available open standards defining PLC. 324 +-------------+-----------------+------------+-----------+----------+ 325 | PLC Systems | Frequency Range | Type | Data Rate | Distance | 326 +-------------+-----------------+------------+-----------+----------+ 327 | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | 328 | | | | | | 329 | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | 330 | | | | | | 331 | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | 332 +-------------+-----------------+------------+-----------+----------+ 334 Table 2: Some Available Open Standards in PLC 336 [IEEE1901] defines broadband variant of PLC but is effective within 337 short range. This standard addresses the requirements of 338 applications with high data rate such as: Internet, HDTV, Audio, 339 Gaming etc. Broadband operates on OFDM (Orthogonal Frequency 340 Division Multiplexing) modulation. 342 [IEEE1901.2] defines narrowband variant of PLC with less data rate 343 but significantly higher transmission range that could be used in an 344 indoor or even an outdoor environment. It supports operating either 345 in Low Voltage (LV) or High Voltage (HV) segment of PLC domain. It 346 is applicable to typical IoT applications such as: Building 347 Automation, Renewable Energy, Advanced Metering, Street Lighting, 348 Electric Vehicle, Smart Grid etc. Narrowband operates either on FSK 349 (Frequency Shift Keying), S (Spread) FSK, BPSK (Binary Phase Shift 350 Keying), SS (Spread Spectrum) or OFDM modulation. Moreover, IEEE 351 1901.2 standard is based on the 802.15.4 MAC sub-layer and fully 352 endorses the security scheme defined in 802.15.4. [RFC8036]. 354 Specific applications come with requirement of diversity. Although 355 IEEE1901 offers higher data rate but is not applicable for long 356 distance scenario due to losses in higher frequencies. On the other 357 hand, IEEE1901.2 is not applicable for real-time services due to low 358 data rate. The IEEE 1901.1 WG is working on a new standard, namely 359 [IEEE1901.1], that provides extended transmission range as compared 360 to IEEE1901 and higher data rate than IEEE1901.2 [IEEE1901.2]. More 361 intelligent IoT financial services are emerging such as: Self Service 362 Terminal, Bank Transfer, Scratch Card, POS (point of sale) etc. and 363 require extensive data transfers. This standard is also known as 364 PLC-IoT and operates on OFDM modulation e.g. FTT (Fast Fourier 365 Transform) and/or wavelet OFDM. 367 3.8. IEEE 802.15.4e 369 The Timeslotted Channel Hopping (TSCH) mode was introduced in the 370 IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are 371 synchronized. Time is sliced up into timeslots. The duration of a 372 timeslot, typically 10ms, is large enough for a node to send a full- 373 sized frame to its neighbor, and for that neighbor to send back an 374 acknowledgment to indicate successful reception. Timeslots are 375 grouped into one of more slotframes, which repeat over time. 377 All the communication in the network is orchestrated by a 378 communication schedule which indicates to each node what to do in 379 each of the timeslots of a slotframe: transmit, listen or sleep. The 380 communication schedule can be built so that the right amount of link- 381 layer resources (the cells in the schedule) are scheduled to satisfy 382 the communication needs of the applications running on the network, 383 while keeping the energy consumption of the nodes very low. Cells 384 can be scheduled in a collision-free way, introducing a high level of 385 determinism to the network. 387 A TSCH network exploits channel hopping: subsequent packets exchanged 388 between neighbor nodes are done on a different frequency. This means 389 that, if a frame isn't received, the transmitter node will re- 390 transmitt the frame on a different frequency. The resulting "channel 391 hopping" efficiently combats external interference and multi-path 392 fading. 394 The main benefits of IEEE 802.15.4 TSCH are: 396 - ultra high reliability. Off-the-shelf commercial products offer 397 over 99.999% end-to-end reliability. 399 - ultra low-power consumption. Off-the-shelf commercial products 400 offer over a decade of battery lifetime. 402 4. 6lo Deployment Scenarios 404 In this clause, we will describe some 6lo deployment scenarios such 405 as Smart Grid activity in WiSun 407 [TBD] 409 5. Design Space 411 The [RFC6568] lists the dimensions used to describe the design space 412 of wireless sensor networks in the context of the 6lowpan working 413 group. The design space is already limited by the unique 414 characteristics of a LoWPAN (e.g., low power, short range, low bit 415 rate). In the RFC 6568, the following design space dimensions are 416 described; Deployment, Network size, Power source, Connectivity, 417 Multi-hop communication, Traffic pattern, Mobility, Quality of 418 Service (QoS). 420 The design space dimensions of 6lo are a little different from those 421 of the RFC 6568 due to the different characteristics of 6lo link 422 layer technologies. The following design space dimensions can be 423 considered. 425 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 426 in an organized manner. The bootstrapping has different 427 characteristics for each link layer technology. 429 o Topology: Topology of 6lo networks may inherently follow the 430 characteristics of each link layer technology. Point-to-point, 431 star, tree or mesh topologies can be configured, depending on the 432 link layer technology considered. 434 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 435 characteristics of each link layer technology. Some link layer 436 technologies may support L2-mesh and some may not support. 438 o Multi-link subnet, single subnet: The selection of multi-link 439 subnet and single subnet depends on connectivity and the number of 440 6lo nodes. 442 o Data rate: Originally, the link layer technologies of 6lo have low 443 rate of data transmission. But, by adjusting the MTU, it can 444 deliver higher data rate. 446 o Buffering requirements: Some 6lo use case may require more data 447 rate than the link layer technology support. In this case, a 448 buffering mechanism to manage the data is required. 450 o Security Requirements: Some 6lo use case can involve transferring 451 some important and personal data between 6lo nodes. In this case, 452 high-level security support is required. 454 o Mobility across 6lo networks and subnets: The movement of 6lo 455 nodes is dependent on the 6lo use case. If the 6lo nodes can move 456 or moved around, it requires a mobility management mechanism. 458 o Time synchronization requirements: The requirement of time 459 synchronization of the upper layer service is dependent on the 6lo 460 use case. For some 6lo use case related to health service, the 461 measured data must be recorded with exact time and must be 462 transferred with time synchronization. 464 o Reliability and QoS: Some 6lo use case requires high reliability, 465 for example real-time service or health-related services. 467 o Traffic patterns: 6lo use cases may involve various traffic 468 patterns. For example, some 6lo use case may require short data 469 length and random transmission. Some 6lo use case may require 470 continuous data and periodic data transmission. 472 o Security Bootstrapping: Without the external operations, 6lo nodes 473 must have the security bootstrapping mechanism. 475 o Power use strategy: to enable certain use cases, there may be 476 requirements on the class of energy availability and the strategy 477 followed for using power for communication [RFC7228]. Each link 478 layer technology defines a particular power use strategy which may 479 be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected 480 to be familiar with RFC 7228 terminology. 482 o Update firmware requirements: Most 6lo use cases will need a 483 mechanism for updating firmware. In these cases support for over 484 the air updates are required, probably in a broadcast mode when 485 bandwith is low and the number of identical devices is high. 487 6. 6lo Use Cases 489 6.1. Use case of ITU-T G.9959: Smart Home 491 Z-Wave is one of the main technologies that may be used to enable 492 smart home applications. Born as a proprietary technology, Z-Wave 493 was specifically designed for this particular use case. Recently, 494 the Z-Wave radio interface (physical and MAC layers) has been 495 standardized as the ITU-T G.9959 specification. 497 Example: Use of ITU-T G.9959 for Home Automation 499 Variety of home devices (e.g. light dimmers/switches, plugs, 500 thermostats, blinds/curtains and remote controls) are augmented with 501 ITU-T G.9959 interfaces. A user may turn on/off or may control home 502 appliances by pressing a wall switch or by pressing a button in a 503 remote control. Scenes may be programmed, so that after a given 504 event, the home devices adopt a specific configuration. Sensors may 505 also periodically send measurements of several parameters (e.g. gas 506 presence, light, temperature, humidity, etc.) which are collected at 507 a sink device, or may generate commands for actuators (e.g. a smoke 508 sensor may send an alarm message to a safety system). 510 The devices involved in the described scenario are nodes of a network 511 that follows the mesh topology, which is suitable for path diversity 512 to face indoor multipath propagation issues. The multihop paradigm 513 allows end-to-end connectivity when direct range communication is not 514 possible. Security support is required, specially for safety-related 515 communication. When a user interaction (e.g. a button press) 516 triggers a message that encapsulates a command, if the message is 517 lost, the user may have to perform further interactions to achieve 518 the desired effect (e.g. a light is turned off). A reaction to a 519 user interaction will be perceived by the user as immediate as long 520 as the reaction takes place within 0.5 seconds [RFC5826]. 522 Dominant parameters in home automation scenarios with ITU-T G.9959: 524 o Deployment/Bootstrapping: Pre-planned. 526 o Topology: Mesh topology. 528 o L2-mesh or L3-mesh: ITU-T G.9959 provides support for L2-mesh, and 529 L3-mesh can also be used (the latter requires an IP-based routing 530 protocol). 532 o Multi-link subnet, single subnet: Multi-link subnet. 534 o Data rate: Small data rate, infrequent transmissions. 536 o Buffering requirements: Low requirement. 538 o Security requirements: Data privacy and security must be provided. 539 Encryption is required. 541 o Mobility: Most devices are static. A few devices (e.g. remote 542 control) are portable. 544 o Time Synchronization: TBD. 546 o Reliability and QoS: Moderate to high level of reliability 547 support. Actions as a result of human-generated traffic should 548 occur after less than 0.5 seconds. 550 o Traffic patterns: Periodic (sensor readings) and aperiodic (user- 551 triggered interaction). 553 o Security Bootstrapping: Required. 555 o Power use strategy: Mix of P1 (Low-power) devices and P9 (Always- 556 on) devices. 558 o Update firmware requirements: TBD. 560 6.2. Use case of Bluetooth LE: Smartphone-Based Interaction with 561 Constrained Devices 563 The key feature behind the current high Bluetooth LE momentum is its 564 support in a large majority of smartphones in the market. Bluetooth 565 LE can be used to allow the interaction between the smartphone and 566 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 567 the main radio interface currently available in wearables. Since a 568 smartphone typically has several radio interfaces that provide 569 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 570 gateway for nearby devices such as sensors, actuators or wearables. 571 Bluetooth LE may be used in several domains, including healthcare, 572 sports/wellness and home automation. 574 Example: Use of Bluetooth LE-based Body Area Network for fitness 576 A person wears a smartwatch for fitness purposes. The smartwatch has 577 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 578 temperature, etc.), a display, and a Bluetooth LE radio interface. 579 The smartwatch can show fitness-related statistics on its display. 580 However, when a paired smartphone is in the range of the smartwatch, 581 the latter can report almost real-time measurements of its sensors to 582 the smartphone, which can forward the data to a cloud service on the 583 Internet. In addition, the smartwatch can receive notifications 584 (e.g. alarm signals) from the cloud service via the smartphone. On 585 the other hand, the smartphone may locally generate messages for the 586 smartwatch, such as e-mail reception or calendar notifications. 588 The functionality supported by the smartwatch may be complemented by 589 other devices such as other on-body sensors, wireless headsets or 590 head-mounted displays. All such devices may connect to the 591 smartphone creating a star topology network whereby the smartphone is 592 the central component. 594 Dominant parameters in fitness scenarios with Bluetooth LE: 596 o Deployment/Bootstrapping: Pre-planned. 598 o Topology: Star topology. 600 o L2-mesh or L3-mesh: No. 602 o Multi-link subnet, single subnet: Multi-link subnet. 604 o Data rate: TBD. 606 o Buffering requirements: Low requirement. 608 o Security requirements: For health-critical information, data 609 privacy and security must be provided. Encryption is required. 610 Some types of notifications sent by the smartphone may not need. 612 o Mobility: Low. 614 o Time Synchronization: the link layer, which is based on TDMA, 615 provides a basis for time synchronization. 617 o Reliability and QoS: a relatively low ratio of message losses is 618 acceptable for periodic sensor readings. End-to-end latency of 619 sensor readings should be low for critical notifications or 620 alarms, generated by either the smartphone or an Internet cloud 621 service. 623 o Traffic patterns: periodic (sensor readings) and aperiodic 624 (smartphone-generated notifications). 626 o Security Bootstrapping: Required. 628 o Power use strategy: P1 (Low-power) devices. 630 o Update firmware requirements: TBD. 632 6.3. Use case of DECT-ULE: Smart Home 634 DECT is a technology widely used for wireless telephone 635 communications in residential scenarios. Since DECT-ULE is a low- 636 power variant of DECT, DECT-ULE can be used to connect constrained 637 devices such as sensors and actuators to a Fixed Part, a device that 638 typically acts as a base station for wireless telephones. Therefore, 639 DECT-ULE is specially suitable for the connected home space in 640 application areas such as home automation, smart metering, safety, 641 healthcare, etc. 643 Example: Use of DECT-ULE for Smart Metering 645 The smart electricity meter of a home is equipped with a DECT-ULE 646 transceiver. This device is in the coverage range of the Fixed Part 647 of the home. The Fixed Part can act as a router connected to the 648 Internet. This way, the smart meter can transmit electricity 649 consumption readings through the DECT-ULE link with the Fixed Part, 650 and the latter can forward such readings to the utility company using 651 Wide Area Network (WAN) links. The meter can also receive queries 652 from the utility company or from an advanced energy control system 653 controlled by the user, which may also be connected to the Fixed Part 654 via DECT-ULE. 656 Dominant parameters in smart metering scenarios with DECT-ULE: 658 o Deployment/Bootstrapping: Pre-planned. 660 o Topology: Star topology. 662 o L2-mesh or L3-mesh: No. 664 o Multi-link subnet, single subnet: Multi-link subnet. 666 o Data rate: Small data rate, infrequent transmissions. 668 o Buffering requirements: Low requirement. 670 o Security requirements: Data privacy and security must be provided. 671 Encryption is required. 673 o Mobility: No. 675 o Time Synchronization: TBD. 677 o Reliability and QoS: bounded latency, stringent reliability 678 service agreements [RFC8036]. 680 o Traffic patterns: Periodic (meter reading notifications sent by 681 the meter) and aperiodic (user- or company-triggered queries to 682 the meter, and messages triggered by local events such as power 683 outage or leak detection [RFC8036]. 685 o Security Bootstrapping: required. 687 o Power use strategy: P0 (Normally-off) for devices with long sleep 688 intervals (i.e. greater than ~10 seconds) which then may need to 689 resynchronize again, and P1 (Low-power) for short sleep intervals. 690 P9 (Always-on) for the Fixed Part (FP), which is the central node 691 in the star topology. 693 o Update firmware requirements: TBD. 695 6.4. Use case of MS/TP: Management of District Heating 697 The key feature of MS/TP is it's ability to run on the same cabling 698 as BACnet and some use of ModBus, the defacto standard for low 699 bandwith industry communication. Specially Modbus has been around 700 since the 1980 and is still the standard for talking to fans, heat 701 pumps, water purifying equipment and everything else delivering 702 electricity, clean water and ventilation. 704 Example: Use of MS/TP for management of district heating 706 The mechanical room in the cellar of an apartment building gets 707 district heating and electricity from the utility providers. The 708 room has a Supervisory Control And Data Acquisition (SCADA) computer 709 talking to a centralized server and command center somewhere else 710 over IP, on the other hand it is controlling the heating, fans and 711 distribution panel over a 2-wire RS-485 based protocol to make sure 712 the logic controller for district heating keeps a constant 713 temperature at the tapwater, the logic controller for heat produktion 714 keeps the right radiator temperature depending on the weather and the 715 fans have a correct speed and are switched off in case district 716 heating fails to prevent cooling out the building and give certain 717 commands in case smoke is detected. Speed is not important, in this 718 usecase, 19,200 bit/s capable equipment is sold as high speed 719 communication capable. Reliability is important, this not working 720 will easily give millions of dollars of damage. Normally the setup 721 is that the SCADA device asks a question to a specific controlling 722 device, gets an answer from the controlling device, asks a new 723 question to some other device. 725 o Deployment/Bootstrapping: Pre-planned. 727 o Topology: Bus, master-slave, token-passing. 729 o Multi-link subnet, single subnet: [TBD], normally single. 731 o Data rate: Small data rate, frequent transmissions. 733 o Buffering requirements: Low. 735 o Security requirements: Security must be provided, authentication 736 is a must. 738 o Mobility: Highly static 740 o Time synchronization: Required. 742 o Reliability and QOS: High, Alerts have to arrive properly, timing 743 is not important. Implication of failing reliability has high 744 probability for life-or-death implications (fire-alarms) or 745 millions of dollars of liability (frozen water heating system in a 746 high rise building) 748 o Traffic patterns: Constant sensor readings and asking devices for 749 error reporting. 751 o Security Bootstrapping: Nice to have, not very important. 753 o Power use strategy: P9 755 o Update firmware requirements: Required. 757 6.5. Use case of NFC: Alternative Secure Transfer 759 According to applications, various secured data can be handled and 760 transferred. Depending on security level of the data, methods for 761 transfer can be alternatively selected. The personal data having 762 serious issues should be transferred securely, but data transfer by 763 using Wi-Fi and Bluetooth connections cannot always be secure because 764 of their a little long radio frequency range. Hackers can overhear 765 the personal data transfer behind hidden areas. Therefore, methods 766 need to be alternatively selected to transfer secured data. Voice 767 and video data, which are not respectively secure and requires long 768 transmission range, can be transferred by 3G/4G technologies, such as 769 WCDMA, GSM, and LTE. Big size data, which are not secure and 770 requires high speed and broad bandwidth, can be transferred by Wi-Fi 771 and wired network technologies. However, the personal data, which 772 pose serious issues if mishandled while transferred in wireless 773 domain, can be securely transferred by NFC technology. It has very 774 short frequency range - nearly single touch communication. 776 Example: Use of NFC for Secure Transfer in Healthcare Services with 777 Tele-Assistance 779 A senior citizen who lives alone wears one to several wearable 6lo 780 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 781 densely installed at home for movement detection. An LoWPAN Border 782 Router (LBR) at home will send the sensed information to a connected 783 healthcare center. Portable base stations with LCDs may be used to 784 check the data at home, as well. Data is gathered in both periodic 785 and event-driven fashion. In this application, event-driven data can 786 be very time-critical. In addition, privacy also becomes a serious 787 issue in this case, as the sensed data is very personal. 789 While the senior citizen is provided audio and video healthcare 790 services by a tele-assistance based on LTE connections, the senior 791 citizen can alternatively use NFC connections to transfer the 792 personal sensed data to the tele-assistance. At this moment, hidden 793 hackers can overhear the data based on the LTE connection, but they 794 cannot gather the personal data over the NFC connection. 796 +-------------+ +-------------+ 797 |voice & video|....... LTE connection ......>|voice & video| 798 | data |<...... LTE connection .......| data | 799 +-------------+ +-------------+ 800 | sensed data |....... NFC connection ......>| | 801 | |<...... NFC connection .......| personal | 802 | | | result data | 803 +-------------+ +-------------+ 804 (patient) (tele-assistance) 806 Figure 1: Alternative Secure Transfer in Healthcare Services 808 Dominant parameters in secure transfer by using NFC in healthcare 809 services: 811 o Deployment/Bootstrapping: Pre-planned. MP2P/P2MP (data 812 collection), P2P (local diagnostic). 814 o Topology: Small, NFC-enabled device connected to the Internet. 816 o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be 817 configured. 819 o Multi-link subnet, single subnet: a single hop for gateway; 820 patient's body network is mesh topology. 822 o Data rate: Small data rate. 824 o Buffering requirements: Low requirement. 826 o Security requirements: Data privacy and security must be provided. 827 Encryption is required. 829 o Mobility: Moderate (patient's mobility). 831 o Time Synchronization: Highly required. 833 o Reliability and QoS: High level of reliability support (life-or- 834 death implication), role-based. 836 o Traffic patterns: Short data length and periodic (randomly). 838 o Security Bootstrapping: Highly required. 840 o Other Issues: Plug-and-play configuration is required for mainly 841 non-technical end-users. Real-time data acquisition and analysis 842 are important. Efficient data management is needed for various 843 devices that have different duty cycles, and for role-based data 844 control. Reliability and robustness of the network are also 845 essential. 847 o Power use strategy: TBD. 849 o Update firmware requirements: TBD. 851 6.6. Use case of LTE MTC: Gateway for Wireless Backhaul Network 853 Wireless link layer technologies can be divided into short range 854 connectivity and long range connectivity. BLE, ITU-T G.9959 855 (Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity. 856 LTE MTC is used for long range connectivity. And there is another 857 long range connectivity technology. It is LPWAN (Low Power Wide Area 858 Network) technology such as LoRa, Sigfox, Wi-Sun etc. Therefore, the 859 use case of LTE MTC could be used in LPWAN. 861 Example: Use of LTE MTC for LoRa gateway 863 LoRa is one of the most promising technology of LPWAN. LoRa network 864 architecture has a star of star topology. LoRa gateway relay the 865 messages from LoRa end device to application server and vice versa. 866 LoRa gateway can have two types of backhaul, wired and wireless 867 backhaul. 869 If a LoRa gateway has wireless backhaul, it should have LTE modem. 870 Since the modem cost of LTE MTC is cheaper than the modem cost of 871 above LTE category 2, it is helpful to design to use LTE MTC. 872 Moreover, the maximum date rate of LoRa end device is 50kbps, it is 873 sufficient to use LTE MTC without using category 2. 875 Dominant parameters in LoRa gateway scenarios in above example: 877 o Deployment/Bootstrapping: Pre-planned. 879 o Topology: Star topology. 881 o L2-mesh or L3-mesh: No. 883 o Multi-link subnet, single subnet: Single subnet. 885 o Data rate: Depends on 3GPP specification. 887 o Buffering requirements: High requirement. 889 o Security requirements: No, because data security is already 890 provided in LoRa specification. 892 o Mobility: Static. 894 o Time Synchronization: Highly required. 896 o Reliability and QoS: TBD. 898 o Traffic patterns: Random. 900 o Security Bootstrapping: Required. 902 o Power use strategy: P9 (Always-on). 904 o Update firmware requirements: TBD. 906 Example: Use of LTE MTC for controlling car 908 Car sharing services are becoming more popular. Customers wish to 909 control the car with smart phone application. For example, customers 910 wish to lock/unlock the car door with smart phone application, 911 because customers may not have a car key. Customers wish to blow 912 with smart phone application to locate the car easily. 914 Therefore, rental car should have a long range connectivity capable 915 modem such as LoRa end device and LTE UE. However, LoRa may not be 916 used because LoRa has low reliability and may not be supported in an 917 indoor environment such as a basement parking lot. And since message 918 size for car control is very small, it is sufficient to use LTE MTC 919 instead of category 2. 921 Dominant parameters in controlling car scenarios in above example: 923 o Deployment/Bootstrapping: Pre-planned. 925 o Topology: Star topology. 927 o L2-mesh or L3-mesh: No. 929 o Multi-link subnet, single subnet: Single subnet. 931 o Data rate: Depends on 3GPP specification. 933 o Buffering requirements: High requirement. 935 o Security requirements: High requirement. 937 o Mobility: Always dynamic . 939 o Time Synchronization: Highly required. 941 o Reliability and QoS: TBD. 943 o Traffic patterns: Random. 945 o Security Bootstrapping: Required. 947 o Power use strategy: P1 (Low-power). 949 6.7. Use case of PLC: Smart Grid 951 Smart grid concept is based on numerous operational and energy 952 measuring sub-systems of an electric grid. It comprises of multiple 953 administrative levels/segments to provide connectivity among these 954 numerous components. Last mile connectivity is established over LV 955 segment, whereas connectivity over electricity distribution takes 956 place in HV segment. 958 Although other wired and wireless technologies are also used in Smart 959 Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, 960 Home Energy Management System - HEMS, Wide Area Situational Awareness 961 - WASA etc), PLC enjoys the advantage of existing (power conductor) 962 medium and better reliable data communication. PLC is a promising 963 wired communication technology in that the electrical power lines are 964 already there and the deployment cost can be comparable to wireless 965 technologies. The 6lo related scenarios lie in the low voltage PLC 966 networks with most applications in the area of Advanced Metering 967 Infrastructure, Vehicle-to-Grid communications, in-home energy 968 management and smart street lighting. 970 Example: Use of PLC for Advanced Metering Infrastructure 972 Household electricity meters transmit time-based data of electric 973 power consumption through PLC. Data concentrators receive all the 974 meter data in their corresponding living districts and send them to 975 the Meter Data Management System (MDMS) through WAN network (e.g. 976 Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- 977 way communications are enabled which means smart meters can do 978 actions like notification of electricity charges according to the 979 commands from the utility company. 981 With the existing power line infrastructure as communication medium, 982 cost on building up the PLC network is naturally saved, and more 983 importantly, labor operational costs can be minimized from a long- 984 term perspective. Furthermore, this AMI application speeds up 985 electricity charge, reduces losses by restraining power theft and 986 helps to manage the health of the grid based on line loss analysis. 988 Dominant parameters in smart grid scenarios with PLC: 990 o Deployment/Bootstrapping: Pre-planned. 992 o Topology: Tree topology. 994 o L2-mesh or L3-mesh: No. 996 o Multi-link subnet, single subnet: Single subnet. 998 o Data rate: Small data rate, infrequent transmissions. 1000 o Buffering requirements: Low requirement. 1002 o Security requirements: Data privacy and security must be provided. 1003 Encryption is required. 1005 o Mobility: Static. 1007 o Time Synchronization: Low requirement. 1009 o Reliability and QoS: a relatively low ratio of message losses is 1010 acceptable for periodic meter readings. 1012 o Traffic patterns: Periodic (upstream meter reading notifications 1013 sent by the meter) and aperiodic (utility company-triggered 1014 downstream queries and messages to the meter such as notification 1015 of electricity charges or leak detection). 1017 o Security Bootstrapping: Required. 1019 o Power use strategy: Mix of P1 (Low Power) devices and P9 (Always- 1020 on) devices. 1022 o Update firmware requirements: TBD. 1024 Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid 1026 Many sub-systems of Smart Grid require low data rate and narrowband 1027 variant (IEEE1901.2) of PLC fulfils such requirements. Recently, 1028 more complex scenarios are emerging that require higher data rates. 1029 (see Table 3). 1031 +--------------+----------+--------------+-------------+---------+ 1032 | Sub System | Security | Bandwidth | Reliability | Latency | 1033 +--------------+----------+--------------+-------------+---------+ 1034 | HEMS | High | 9.6-56kbps | 99% | <2000ms | 1035 | | | | | | 1036 | AMI-Node | High | 10-100kbps | 99% | <200ms | 1037 | | | | | | 1038 | AMI-Backhaul | High | 500kbps | 99% | <200ms | 1039 | | | | | | 1040 | WASA | High | 600-1500kbps | 99% | <200ms | 1041 +--------------+----------+--------------+-------------+---------+ 1043 Table 3: Some Sub Systems of Smart Grid 1045 WASA sub-system is an appropriate example that collects large amount 1046 of information about the current state of the grid over wide area 1047 from electric substations as well as power transmission lines. The 1048 collected feedback is used for monitoring, controlling and protecting 1049 all the sub-systems. 1051 Dominant parameters in WASA scenario with above example: 1053 o Deployment/Bootstrapping: Pre-planned. 1055 o Topology: TBD. 1057 o L2-mesh or L3-mesh: TBD. 1059 o Multi-link subnet, single subnet: TBD. 1061 o Data rate: TBD. 1063 o Buffering requirements: TBD. 1065 o Security requirements: TBD. 1067 o Mobility: TBD. 1069 o Time Synchronization: TBD. 1071 o Reliability and QoS: TBD. 1073 o Traffic patterns: TBD. 1075 o Security Bootstrapping: TBD. 1077 o Power use strategy: P9 (Always-on). 1079 o Update firmware requirements: TBD. 1081 6.8. Use case of IEEE 802.15.4e: Industrial Automation 1083 Typical scenario of Industrial Automation where sensor and actuators 1084 are connected through the time-slotted radio access (IEEE 802.15.4e). 1085 For that, there will be a point-to-point control signal exchange in 1086 between sensors and actuators to trigger the critical control 1087 information. In such scenarios, point-to-point traffic flows are 1088 significant to exchange the controlled information in between sensors 1089 and actuators within the constrained networks. 1091 Example: Use of IEEE 802.15.4e for P2P communication in closed-loop 1092 application 1094 AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P 1095 routing protocol to provide the hop-by-hop data transmission in 1096 closed-loop constrained networks. Scheduling Functions i.e. SF0 1097 [I-D.ietf-6tisch-6top-sf0] and SF1 [I-D.satish-6tisch-6top-sf1] is 1098 proposed to provide distributed neighbor-to-neighbor and end-to-end 1099 resource reservations, respectively for traffic flows in 1100 deterministic networks (6TiSCH). 1102 The potential scenarios that can make use of the end-to-end resource 1103 reservations can be in health-care and industrial applications. 1104 AODV-RPL and SF0/SF1 are the significant routing and resource 1105 reservation protocols for closed-loop applications in constrained 1106 networks. 1108 Dominant parameters in P2P scenarios with above example: 1110 o Deployment/Bootstrapping: Pre-planned. 1112 o Topology: TBD. 1114 o L2-mesh or L3-mesh: TBD. 1116 o Multi-link subnet, single subnet: TBD. 1118 o Data rate: TBD. 1120 o Buffering requirements: TBD. 1122 o Security requirements: TBD. 1124 o Mobility: TBD. 1126 o Time Synchronization: TBD. 1128 o Reliability and QoS: TBD. 1130 o Traffic patterns: TBD. 1132 o Security Bootstrapping: TBD. 1134 o Power use strategy: P9 (Always-on). 1136 o Update firmware requirements: TBD. 1138 7. IANA Considerations 1140 There are no IANA considerations related to this document. 1142 8. Security Considerations 1144 [TBD] 1146 9. Acknowledgements 1148 Carles Gomez has been funded in part by the Spanish Government 1149 (Ministerio de Educacion, Cultura y Deporte) through the Jose 1150 Castillejo grant CAS15/00336. His contribution to this work has been 1151 carried out in part during his stay as a visiting scholar at the 1152 Computer Laboratory of the University of Cambridge. 1154 Samita Chakrabarti, Thomas Watteyne, Pascal Thubert, Xavier 1155 Vilajosana, Daniel Migault, and Jianqiang HOU have provided valuable 1156 feedback for this draft. 1158 10. References 1160 10.1. Normative References 1162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1163 Requirement Levels", BCP 14, RFC 2119, 1164 DOI 10.17487/RFC2119, March 1997, 1165 . 1167 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1168 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1169 Overview, Assumptions, Problem Statement, and Goals", 1170 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1171 . 1173 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1174 "Transmission of IPv6 Packets over IEEE 802.15.4 1175 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1176 . 1178 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1179 Routing Requirements in Low-Power and Lossy Networks", 1180 RFC 5826, DOI 10.17487/RFC5826, April 2010, 1181 . 1183 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1184 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1185 DOI 10.17487/RFC6282, September 2011, 1186 . 1188 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 1189 Application Spaces for IPv6 over Low-Power Wireless 1190 Personal Area Networks (6LoWPANs)", RFC 6568, 1191 DOI 10.17487/RFC6568, April 2012, 1192 . 1194 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1195 Bormann, "Neighbor Discovery Optimization for IPv6 over 1196 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1197 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1198 . 1200 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1201 Constrained-Node Networks", RFC 7228, 1202 DOI 10.17487/RFC7228, May 2014, 1203 . 1205 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1206 over ITU-T G.9959 Networks", RFC 7428, 1207 DOI 10.17487/RFC7428, February 2015, 1208 . 1210 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1211 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1212 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1213 . 1215 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 1216 Statement for the Routing Protocol for Low-Power and Lossy 1217 Networks (RPL) in Advanced Metering Infrastructure (AMI) 1218 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 1219 . 1221 10.2. Informative References 1223 [I-D.ietf-6lo-dect-ule] 1224 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 1225 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 1226 Energy", draft-ietf-6lo-dect-ule-07 (work in progress), 1227 October 2016. 1229 [I-D.ietf-6lo-6lobac] 1230 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 1231 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 1232 6lo-6lobac-05 (work in progress), June 2016. 1234 [I-D.ietf-6lo-nfc] 1235 Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 1236 Packets over Near Field Communication", draft-ietf-6lo- 1237 nfc-05 (work in progress), October 2016. 1239 [I-D.ietf-lwig-energy-efficient] 1240 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 1241 Efficient Features of Internet of Things Protocols", 1242 draft-ietf-lwig-energy-efficient-05 (work in progress), 1243 October 2016. 1245 [I-D.ietf-roll-aodv-rpl] 1246 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 1247 Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 1248 Networks (LLNs)", draft-ietf-roll-aodv-rpl-00 (work in 1249 progress), December 2016. 1251 [I-D.ietf-6tisch-6top-sf0] 1252 Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, 1253 "6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf- 1254 6tisch-6top-sf0-02 (work in progress), October 2016. 1256 [I-D.satish-6tisch-6top-sf1] 1257 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 1258 Anand, "Scheduling Function One (SF1) for hop-by-hop 1259 Scheduling in 6tisch Networks", draft-satish-6tisch-6top- 1260 sf1-02 (work in progress), August 2016. 1262 [G.9959] "International Telecommunication Union, "Short range 1263 narrow-band digital radiocommunication transceivers - PHY 1264 and MAC layer specifications", ITU-T Recommendation", 1265 January 2015. 1267 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership 1268 Project; Technical Specification Group Radio Access 1269 Network; Evolved Universal Terrestrial Radio Access 1270 (E-UTRA); User Equipment (UE) radio access capabilities 1271 (Release 13)", December 2015. 1273 [IEEE1901] 1274 "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for 1275 Broadband over Power Line Networks: Medium Access Control 1276 and Physical Layer Specifications", 2010, 1277 . 1280 [IEEE1901.1] 1281 "IEEE Standard (work-in-progress), IEEE-SA Standards 1282 Board", . 1284 [IEEE1901.2] 1285 "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for 1286 Low-Frequency (less than 500 kHz) Narrowband Power Line 1287 Communications for Smart Grid Applications", 2013, 1288 . 1291 Authors' Addresses 1293 Yong-Geun Hong 1294 ETRI 1295 161 Gajeong-Dong Yuseung-Gu 1296 Daejeon 305-700 1297 Korea 1299 Phone: +82 42 860 6557 1300 Email: yghong@etri.re.kr 1302 Carles Gomez 1303 Universitat Politecnica de Catalunya/Fundacio i2cat 1304 C/Esteve Terradas, 7 1305 Castelldefels 08860 1306 Spain 1308 Email: carlesgo@entel.upc.edu 1309 Younghwan Choi 1310 ETRI 1311 218 Gajeongno, Yuseong 1312 Daejeon 305-700 1313 Korea 1315 Phone: +82 42 860 1429 1316 Email: yhc@etri.re.kr 1318 Deoknyong Ko 1319 SKtelecom 1320 9-1 Byundang-gu Sunae-dong, Seongnam-si 1321 Gyeonggi-do 13595 1322 Korea 1324 Phone: +82 10 3356 8052 1325 Email: engineer@sk.com 1327 Abdur Rashid Sangi 1328 Huawei Technologies 1329 No.156 Beiqing Rd. Haidian District 1330 Beijing 100095 1331 P.R. China 1333 Email: rashid.sangi@huawei.com 1335 Take Aanstoot 1336 Modio AB 1337 S:t Larsgatan 15, 582 24 1338 Linkoping 1339 Sweden 1341 Email: take@modio.se