idnits 2.17.1 draft-hong-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 21, 2016) is 2951 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 744, 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-03 == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-02 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-01 == 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-11 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: September 22, 2016 UPC/i2cat 6 Y-H. Choi 7 ETRI 8 D-Y. Ko 9 SKtelecom 10 March 21, 2016 12 Use cases for IPv6 over Networks of Resource-constrained Nodes 13 draft-hong-6lo-use-cases-01 15 Abstract 17 This document describes the characteristics of link layer 18 technologies that are used at constrained node networks and typical 19 use cases of IPv6 over networks of resource-constrained nodes. In 20 addition to IEEE 802.15.4, various link layer technologies such as 21 BLE, ITU-T G.9959 (Z-Wave), DECT-ULE, MS/TP, NFC, and LTE MTC are 22 widely used at constrained node networks for typical services. Based 23 on these link layer technologies, IPv6 over networks of resource- 24 constrained nodes has various and practical use cases. To 25 efficiently implement typical services, the applicability and 26 consideration of several design spaces are described. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 22, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 64 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 65 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 4 67 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4. Master-Slave/Token-Passing . . . . . . . . . . . . . . . 5 69 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Use case of NFC: Alternative Secure Transfer . . . . . . 8 74 5.2. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 10 75 5.3. Use case of Bluetooth Low Energy: Smartphone-Based 76 Interaction with Constrained Devices . . . . . . . . . . 12 77 5.4. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 13 78 5.5. Use case of LTE MTC . . . . . . . . . . . . . . . . . . . 14 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 9.2. Informative References . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 Running IPv6 on constrained node networks has different features due 90 to the characteristics of constrained node networks such as small 91 packet size, short link-layer address, low bandwidth, network 92 topology, low power, low cost, and large number of devices [RFC4919]. 94 For example, because some IEEE 802.15.4 link layers have a frame size 95 of 127 octets and IPv6 requires an MTU of 1280 bytes, an appropriate 96 fragmentation and reassembly adaptation layer must be provided at the 97 layer of below IPv6. Also, the limited size of IEEE 802.15.4 frame, 98 the length shortage of data delivery, and low energy consumption 99 requirements make the need for header compression. IETF 6lowpan 100 (IPv6 over Low powerWPAN) working group published [RFC4944], an 101 adaptation layer for sending IPv6 packets over IEEE 802.15.4, 102 [RFC6282], compression format for IPv6 datagrams over IEEE 103 802.15.4-based networks, and [RFC6775], Neighbor Discovery 104 Optimization for 6lowpan. 106 As IoT (Internet of Things) services become more popular, various 107 link layer technologies such as Bluetooth Low Energy (Bluetooth LE), 108 ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - 109 Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), and 110 Near Field Communication (NFC) are actively used. And the need of 111 transmission of IPv6 packets over these link layer technologies is 112 required. A number of IPv6-over-foo documents have been developed in 113 the IETF 6lo (IPv6 over Networks of Resource-constrained Nodes) and 114 6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e) working group. 116 In the 6lowpan working group, the [RFC6568], "Design and Application 117 Spaces for 6LoWPANs" was published and it describes potential 118 application scenarios and use cases for low-power wireless personal 119 area networks. In this document, various design space dimension such 120 as deployment, network size, power source, connectivity, multi-hop 121 communication, traffic pattern, security level, mobility, and QoS 122 were analyzed. And it described a fundamental set of 6lowpan 123 application scenarios and use cases: Industrial monitoring-Hospital 124 storage rooms, Structural monitoring-Bridge safety monitoring, 125 Connected home-Home Automation, Healthcare-Healthcare at home by 126 tele-assistance, Vehicle telematics-telematics, and Agricultural 127 monitoring-Automated vineyard. 129 Even though the [RFC6568] describes some potential application 130 scenarios and use cases and it lists the design space in the context 131 of 6lowpan, it does not cover the different use cases and design 132 space in the context of the 6lo working group. This document 133 provides the use cases of 6lo, considering the following: 135 o 6lo use cases MAY be uniquely different to the 6lowpan use cases. 137 o 6lo use cases SHOULD cover various IoT related wire/wireless link 138 layer technologies providing practical information of such 139 technologies. 141 o 6lo use cases MAY describe characteristics and typical use cases 142 of each link layer technology, and then 6lo use cases's 143 applicability. 145 2. Conventions and Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. 6lo Link layer technologies 153 3.1. ITU-T G.9959 155 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 156 Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID 157 network identifier is assigned by a network controller and how an 158 8-bit NodeID host identifier is allocated to each node. NodeIDs are 159 unique within the network identified by the HomeID. The G.9959 160 HomeID represents an IPv6 subnet that is identified by one or more 161 IPv6 prefixes [RFC7428]. 163 3.2. Bluetooth Low Energy 165 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 166 4.1, and developed even further in successive versions. Bluetooth 167 SIG has also published Internet Protocol Support Profile (IPSP), 168 which includes Internet Protocol Support Service (IPSS). The IPSP 169 enables discovery of IP-enabled devices and establishment of link- 170 layer connection for transporting IPv6 packets. IPv6 over Bluetooth 171 LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or newer. 173 Devices such as mobile phones, notebooks, tablets and other handheld 174 computing devices which will include Bluetooth 4.1 chipsets will also 175 have the low-energy variant of Bluetooth. Bluetooth LE will also be 176 included in many different types of accessories that collaborate with 177 mobile devices such as phones, tablets and notebook computers. An 178 example of a use case for a Bluetooth LE accessory is a heart rate 179 monitor that sends data via the mobile phone to a server on the 180 Internet [RFC7668]. 182 3.3. DECT-ULE 184 DECT ULE is a low power air interface technology that is designed to 185 support both circuit switched services, such as voice communication, 186 and packet mode data services at modest data rate. 188 The DECT ULE protocol stack consists of the PHY layer operating at 189 frequencies in the 1880 - 1920 MHz frequency band depending on the 190 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 191 allocated by use of FDMA/TDMA/TDD technics. 193 In its generic network topology, DECT is defined as a cellular 194 network technology. However, the most common configuration is a star 195 network with a single Fixed Parts (FP) defining the network with a 196 number of PP attached. The MAC layer supports traditional DECT as 197 this is used for services like discovery, pairing, security features 198 etc. All these features have been reused from DECT. 200 The DECT ULE device can switch to the ULE mode of operation, 201 utilizing the new ULE MAC layer features. The DECT ULE Data Link 202 Control (DLC) provides multiplexing as well as segmentation and re- 203 assembly for larger packets from layers above. The DECT ULE layer 204 also implements per-message authentication and encryption. The DLC 205 layer ensures packet integrity and preserves packet order, but 206 delivery is based on best effort. 208 The current DECT ULE MAC layer standard supports low bandwidth data 209 broadcast. However the usage of this broadcast service has not yet 210 been standardized for higher layers [I-D.ietf-6lo-dect-ule]. 212 3.4. Master-Slave/Token-Passing 214 MS/TP is a contention-free access method for the RS-485 physical 215 layer, which is used extensively in building automation networks. 216 This specification defines the frame format for transmission of IPv6 217 [RFC2460] packets and the method of forming link-local and 218 statelessly autoconfigured IPv6 addresses on MS/TP networks. The 219 general approach is to adapt elements of the 6LoWPAN [RFC4944] 220 specification to constrained wired networks. 222 An MS/TP device is typically based on a low-cost microcontroller with 223 limited processing power and memory. Together with low data rates 224 and a small address space, these constraints are similar to those 225 faced in 6LoWPAN networks and suggest some elements of that solution 226 might be leveraged. MS/TP differs significantly from 6LoWPAN in at 227 least three respects: a) MS/TP devices typically have a continuous 228 source of power, b) all MS/TP devices on a segment can communicate 229 directly so there are no hidden node or mesh routing issues, and c) 230 recent changes to MS/TP provide support for large payloads, 231 eliminating the need for link-layer fragmentation and reassembly. 233 MS/TP is designed to enable multidrop networks over shielded twisted 234 pair wiring. It can support a data rate of 115,200 baud on segments 235 up to 1000 meters in length, or segments up to 1200 meters in length 236 at lower baud rates. An MS/TP link requires only a UART, an RS-485 237 transceiver with a driver that can be disabled, and a 5ms resolution 238 timer. These features make MS/TP a cost-effective field bus for the 239 most numerous and least expensive devices in a building automation 240 network [I-D.ietf-6lo-6lobac]. 242 3.5. NFC 244 NFC technology enables simple and safe two-way interactions between 245 electronic devices, allowing consumers to perform contactless 246 transactions, access digital content, and connect electronic devices 247 with a single touch. NFC complements many popular consumer level 248 wireless technologies, by utilizing the key elements in existing 249 standards for contactless card technology (ISO/IEC 14443 A&B and 250 JIS-X 6319-4). NFC can be compatible with existing contactless card 251 infrastructure and it enables a consumer to utilize one device across 252 different systems. 254 Extending the capability of contactless card technology, NFC also 255 enables devices to share information at a distance that is less than 256 10 cm with a maximum communication speed of 424 kbps. Users can 257 share business cards, make transactions, access information from a 258 smart poster or provide credentials for access control systems with a 259 simple touch. 261 NFC's bidirectional communication ability is ideal for establishing 262 connections with other technologies by the simplicity of touch. In 263 addition to the easy connection and quick transactions, simple data 264 sharing is also available [I-D.ietf-6lo-nfc]. 266 3.6. LTE MTC 268 LTE category defines the overall performance and capabilities of the 269 UE(User Equipment). For example, the maximum down rate of category 1 270 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 271 There are many categories in LTE standard. 3GPP standards defined the 272 category 0 to be used for low rate IoT service in release 12. Since 273 category 1 and category 0 could be used for low rate IoT service, we 274 call LTE MTC[LTE_MTC]. 276 LTE MTC have the advantages compared to above category 2 to be used 277 for low rate IoT service such as low power and low cost. 279 The below figure shows the primary characteristics of LTE MTC. 281 +------------+---------------------+-------------------+ 282 | Category | Max. Date Rate Down | Max. Date Rate Up | 283 +------------+---------------------+-------------------+ 284 | Category 0 | 1.0 Mbit/s | 1.0 Mbit/s | 285 | | | | 286 | Category 1 | 10.3 Mbit/s | 5.2 Mbit/s | 287 +------------+---------------------+-------------------+ 289 Table 1: Primary characteristics of LTE MTC 291 4. Design Space 293 The [RFC6568] lists the dimensions used to describe the design space 294 of wireless sensor networks in the context of the 6LoWPAN working 295 group. The design space is already limited by the unique 296 characteristics of a LoWPAN (e.g., low power, short range, low bit 297 rate). In the RFC 6558, the following design space dimensions are 298 described; Deployment, Network size, Power source, Connectivity, 299 Multi-hop communication, Traffic pattern, Mobility, Quality of 300 Service (QoS). 302 The design space dimensions of 6lo are a little different to those of 303 the RFC 6558 due to the different characteristics of 6lo link layer 304 technologies. The following design space dimensions can be 305 considered. 307 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 308 in an organized manner. The bootstrapping has different 309 characteristics of each link layer technologies. 311 o Topology: Topology of 6lo networks may inherently follow the 312 characteristics of each link layer technology. Point-to-point, 313 star, tree or mesh topologies can be configured. 315 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 316 characteristics of each link layer technologies. Some link layer 317 technologies may support L2-mesh and some may not support. 319 o Multi-link subnet, single subnet: The selection of multi-link 320 subnet and single subnet depends on connectivity and the number of 321 6lo nodes. 323 o Data rate: Originally, the link layer technologies of 6lo have low 324 rate of data transmission. But, by adjusting the MTU, it can 325 deliver higher data rate. 327 o Buffering requirements: Some 6lo use case may require more data 328 rate than the link layer technology support. In this case, a 329 buffering mechanism to manage the date is required. 331 o Security Requirements: Some 6lo use case can transfer some 332 important and personal data between 6lo nodes. In this case, 333 high-level security support is required. 335 o Mobility across 6lo networks and subnets: The movement of 6lo 336 nodes is dependent on the 6lo use case. If the 6lo nodes can move 337 or moved around, it requires the mobility management mechanism. 339 o Time synchronization requirements: The requirement of time 340 synchronization of the upper layer service is dependent on the 6lo 341 use case. For some 6lo use case related to health service, the 342 measured data must be recorded with exact time and must be 343 transferred with time synchronization. 345 o Reliability and QoS: Some 6lo use case requires high reliability, 346 for example real-time service or health-related services. 348 o Traffic patterns: 6lo use case may various traffic patterns. Some 349 6lo use case may require short data length and randomly. Some 6lo 350 use case may require continuous data and periodic data 351 transmission. 353 o Security Bootstrapping: Without the external operations, 6lo nodes 354 must have the security bootstrapping mechanism. 356 o Power use strategy: to enable certain use cases, there may be 357 requirements on the class of energy availability and the strategy 358 followed for using power for communication [RFC7228]. Each link 359 layer technology defines a particular power use strategy which may 360 be tuned [I-D.ietf-lwig-energy-efficient]. 362 o Energy limitation: The energy limitation class [RFC7228] is 363 specific to each use case, and may or may not be related to the 364 power use strategy. 366 5. 6lo Use Cases 368 5.1. Use case of NFC: Alternative Secure Transfer 370 According to applications, various secured data can be handled and 371 transferred. Depending on security level of the data, methods for 372 transfer can be alternatively selected. The personal data having 373 serious issues should be transferred securely, but data transfer by 374 using Wi-Fi and Bluetooth connections cannot always be secure because 375 of their a little long radio frequency range. Hackers can overhear 376 the personal data transfer behind hidden areas. Therefore, methods 377 need to be alternatively selected to transfer secured data. Voice 378 and video data, which are not respectively secure and requires long 379 transmission range, can be transferred by 3G/4G technologies, such as 380 WCDMA, GSM, and LTE. Big size data, which are not secure and 381 requires high speed and broad bandwidth, can be transferred by Wi-Fi 382 and wired network technologies. However, the person data, which are 383 serious issues so requires secure transfer in wireless area, can be 384 securely transferred by NFC technology. It has very short frequency 385 range ? nearly single touch communication. 387 Example: Secure Transfer by Using NFC in Healthcare Services with 388 Tele-Assistance 390 A senior citizen who lives alone wears one to several wearable 6lo 391 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 392 densely installed at home for movement detection. An LoWPAN Border 393 Router (LBR) at home will send the sensed information to a connected 394 healthcare center. Portable base stations with LCDs may be used to 395 check the data at home, as well. Data is gathered in both periodic 396 and event-driven fashion. In this application, event-driven data can 397 be very time-critical. In addition, privacy also becomes a serious 398 issue in this case, as the sensed data is very personal. 400 While the senior citizen is provided audio and video healthcare 401 services by a tele-assistance based on LTE connections, the senior 402 citizen can alternatively use NFC connections to transfer the 403 personal sensed data to the tele-assistance. At this moment, hidden 404 hackers can overhear the data based on the LTE connection, but they 405 cannot gather the personal data over the NFC connection. 407 +-------------+ +-------------+ 408 |voice & video|....... LTE connection ......>|voice & video| 409 | data |<...... LTE connection .......| data | 410 +-------------+ +-------------+ 411 | sensed data |....... NFC connection ......>| | 412 | |<...... NFC connection .......| personal | 413 | | | result data | 414 +-------------+ +-------------+ 415 (patient) (tele-assistance) 417 Figure 1: Alternative Secure Transfer in Healthcare Services 419 Dominant parameters in secure transfer by using NFC in healthcare 420 services: 422 o Deployment/Bootstrapping: Pre-planned. MP2P/P2MP (data 423 collection), P2P (local diagnostic). 425 o Topology: Small, NFC-enabled device connected to the Internet. 427 o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be 428 configured. 430 o Multi-link subnet, single subnet: a Single-hop for gateway; 431 patient's body network is mesh topology. 433 o Data rate: Small data rate. 435 o Buffering requirements: Low requirement. 437 o Security requirements: Data privacy and security must be provided. 438 Encryption is required. 440 o Mobility: Moderate (patient's mobility). 442 o Time Synchronization: Highly required. 444 o Reliability and QoS: High level of reliability support (life-or- 445 death implication), role-based. 447 o Traffic patterns: Short data length and periodic (randomly). 449 o Security Bootstrapping: Highly required. 451 o Other Issues: Plug-and-play configuration is required for mainly 452 non-technical end-users. Real-time data acquisition and analysis 453 are important. Efficient data management is needed for various 454 devices that have different duty cycles, and for role-based data 455 control. Reliability and robustness of the network are also 456 essential. 458 5.2. Use case of ITU-T G.9959: Smart Home 460 Z-Wave is one of the main technologies that may be used to enable 461 smart home applications. Born as a proprietary technology, Z-Wave 462 was specifically designed for this use case. Recently, the Z-Wave 463 radio interface (physical and MAC layers) has been standardized as 464 the ITU-T G.9959 specification. 466 Example: Use of ITU-T G.9959 for Home Automation 468 Variety of home devices (e.g. light dimmers/switches, plugs, 469 thermostats,blinds/curtains and remote controls) are augmented with 470 ITU-T G.9959 interfaces. A user may turn on/off or may control home 471 appliances by pressing a wall switch or by pressing a button in a 472 remote control. Scenes may be programmed, so that after a given 473 event, the home devices adopt a specific configuration. Sensors may 474 also periodically send measurements of several parameters (e.g. gas 475 presence, light, temperature, humidity, etc.) which are collected at 476 a sink device, or may generate commands for actuators (e.g. a smoke 477 sensor may send an alarm message to a safety system). 479 The devices involved in the described scenario are nodes of a network 480 that follows the mesh topology, which is suitable for path diversity 481 to face indoor multipath propagation issues. The multihop paradigm 482 allows end-to-end connectivity when direct range communication is not 483 possible. Security support is required, specially for safety-related 484 communication. When a user interaction (e.g. a button press) 485 triggers a message that encapsulates a command, if the message is 486 lost, the user may have to perform further interactions to achieve 487 the desired effect (e.g. a light is turned off). A reaction to a 488 user interaction will be perceived by the user as immediate as long 489 as the reaction takes place after less than 0.5 seconds [RFC5826]. 491 Dominant parameters in home automation scenarios with ITU-T G.9959: 493 o Deployment/Bootstrapping: Pre-planned. 495 o Topology: Mesh topology. 497 o L2-mesh or L3-mesh: ITU-T G.9959 provides support for L2-mesh, and 498 L3-mesh can also be used (the latter requires an IP-based routing 499 protocol). 501 o Multi-link subnet, single subnet: Multi-link subnet. 503 o Data rate: Small data rate, infrequent transmissions. 505 o Buffering requirements: Low requirement. 507 o Security requirements: Data privacy and security must be provided. 508 Encryption is required. 510 o Mobility: Most devices are static. A few devices (e.g. remote 511 control) are portable. 513 o Time Synchronization: TBD. 515 o Reliability and QoS: Moderate to high level of reliability 516 support. Actions as a result of human-generated traffic should 517 occur after less than 0.5 seconds. 519 o Traffic patterns: Periodic (sensor readings) and aperiodic (user- 520 triggered interaction). 522 o Security Bootstrapping: Required. 524 5.3. Use case of Bluetooth Low Energy: Smartphone-Based Interaction 525 with Constrained Devices 527 The key feature behind the current high Bluetooth LE momentum is its 528 support in a large majority of smartphones in the market. Bluetooth 529 LE can be used to allow the interaction between the smartphone and 530 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 531 the main radio interface currently available in wearables. Since a 532 smartphone typically has several radio interfaces that provide 533 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 534 gateway for nearby devices such as sensors, actuators or wearables. 535 Bluetooth LE may be used in several domains, including healthcare, 536 sports/wellness and home automation. 538 Example: Bluetooth LE-based Body Area Network for fitness 540 A person wears a smartwatch for fitness purposes. The smartwatch has 541 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 542 temperature, etc.), a display, and a Bluetooth LE radio interface. 543 The smartwatch can show fitness-related statistics on its display. 544 However, when a paired smartphone is in the range of the smartwatch, 545 the latter can report almost real-time measurements of its sensors to 546 the smartphone, which can forward the data to a cloud service on the 547 Internet. In addition, the smartwatch can receive notifications 548 (e.g. alarm signals) from the cloud service via the smartphone. On 549 the other hand, the smartphone may locally generate messages for the 550 smartwatch, such as e-mail reception or calendar notifications. 552 The functionality supported by the smartwatch may be complemented by 553 other devices such as other on-body sensors, wireless headsets or 554 head-mounted displays. All such devices may connect to the 555 smartphone creating a star topology network whereby the smartphone is 556 the central component. 558 Dominant parameters in home automation scenarios with Bluetooth LE: 560 o Deployment/Bootstrapping: Pre-planned. 562 o Topology: Star topology. 564 o L2-mesh or L3-mesh: No. 566 o Multi-link subnet, single subnet: Multi-link subnet. 568 o Data rate: TBD. 570 o Buffering requirements: Low requirement. 572 o Security requirements: For health-critical information, data 573 privacy and security must be provided. Encryption is required. 574 Some types of notifications sent by the smartphone may not need. 576 o Mobility: Low. 578 o Time Synchronization: the link layer, which is based on TDMA, 579 provides a basis for time synchronization. 581 o Reliability and QoS: a relatively low ratio of message losses is 582 acceptable for periodic sensor readings. End-to-end latency of 583 sensor readings is not subject to stringent requirements. The 584 latency of should be low for critical notifications or alarms, 585 generated by either the smartphone or an Internet cloud service. 587 o Traffic patterns: periodic (sensor readings) and aperiodic 588 (smartphone-generated notifications). 590 o Security Bootstrapping: Required. 592 5.4. Use case of DECT-ULE: Smart Home 594 DECT is a technology widely used for wireless telephone communicatio 595 s in residential scenarios. Since DECT-ULE is a low-power variant of 596 DECT, DECT-ULE can be used to connect constrained devices such as 597 sensors and actuators to a Fixed Part, a device that typically acts 598 as a base station for wireless telephones. Therefore, DECT-ULE is 599 specially suitable for the connected home space in application areas 600 such as home automation, smart metering, safety, healthcare, etc. 602 Example: use of DECT-ULE for Smart Metering 604 The smart electricity meter of a home is equipped with a DECT-ULE 605 transceiver. This device is in the coverage range of the Fixed Part 606 of the home. The Fixed Part can act as a router connected to the 607 Internet. This way, the smart meter can transmit electricity 608 consumption readings through the DECT-ULE link with the Fixed Part, 609 and the latter can forward such readings to the utility company using 610 Wide Area Network (WAN) links. The meter can also receive queries 611 from the utility company or from an advanced energy control system 612 controlled by the user, which may also be connected to the Fixed Part 613 via DECT-ULE. 615 Dominant parameters in smart metering scenarios with DECT-ULE: 617 o Deployment/Bootstrapping: Pre-planned. 619 o Topology: Star topology. 621 o L2-mesh or L3-mesh: No. 623 o Multi-link subnet, single subnet: Multi-link subnet. 625 o Data rate: Small data rate, infrequent transmissions. 627 o Buffering requirements: Low requirement. 629 o Security requirements: Data privacy and security must be provided. 630 Encryption is required. 632 o Mobility: No. 634 o Time Synchronization: TBD. 636 o Reliability and QoS: bounded latency, stringent reliability 637 service agreements [I-D.ietf-roll-applicability-ami]. 639 o Traffic patterns: Periodic (meter reading notifications sent by 640 the meter) and aperiodic (user- or company-triggered queries to 641 the meter, and messages triggered by local events such as power 642 outage or leak detection [I-D.ietf-roll-applicability-ami]). 644 o Security Bootstrapping: required. 646 5.5. Use case of LTE MTC 648 Wireless link layer technologies can be divided short range 649 connectivity and long range connectivity. BLE, ITU-T G.9959 650 (Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity. 651 LTE MTC is used for long range connectivity. And there is another 652 long range connectivity technology. It is LPWAN(Low Power Wide Area 653 Network) technology such as LoRa, Sigfox and etc. Therefore, the use 654 case of LTE MTC should be compared to LPWAN. 656 Example: Use of wireless backhaul for LoRa gateway 658 LoRa is the most promising technology of LPWAN. LoRa network 659 architecture has a star of stat topology. LoRa gateway relay the 660 messages from LoRa end device to application server and vice versa. 661 LoRa gateway can has two types of backhaul, wired and wireless 662 backhaul. 664 If LoRa gateway has wireless backhaul, it should have LTE modem. 665 Since the modem cost of LTE MTC is cheaper than the modem cost of 666 above LTE category 2, it is helpful to design to use LTE MTC. Since 667 the maximum date rate of LoRa end device is 50kbps, it is sufficient 668 to use LTE MTC without using category 2. 670 Dominant parameters in LoRa gateway scenarios with above example: 672 o Deployment/Bootstrapping: Pre-planned. 674 o Topology: Star topology. 676 o L2-mesh or L3-mesh: No. 678 o Multi-link subnet, single subnet: Single subnet. 680 o Data rate: depends on 3GPP specification. 682 o Buffering requirements: High requirement. 684 o Security requirements: No, because data security is already 685 provided in LoRa specification. 687 o Mobility: Static. 689 o Time Synchronization: Highly required. 691 o Reliability and QoS: TBD. 693 o Traffic patterns: Random. 695 o Security Bootstrapping: required. 697 Example: Use of controlling car 699 Car sharing service becomes more popular. Customers wish to control 700 the car with smart phone application. For example, customers wish to 701 lock/unlock the car door with smart phone application, because 702 customers may not have a car key. Customers wish to blow with smart 703 phone application to locate the car easily. 705 Therefore, rental car should have a long range connectivity capable 706 modem such as LoRa end device and LTE UE. However, LoRa may not be 707 used because LoRa has low reliability and may not is supported in 708 indoor environment such as basement parking lot. And since the 709 message of controlling car is very small, it is sufficient to use LTE 710 MTC but above category 2. 712 Dominant parameters in controlling car scenarios with above example: 714 o Deployment/Bootstrapping: Pre-planned. 716 o Topology: Star topology. 718 o L2-mesh or L3-mesh: No. 720 o Multi-link subnet, single subnet: Single subnet. 722 o Data rate: depends on 3GPP specification. 724 o Buffering requirements: High requirement. 726 o Security requirements: High requirement. 728 o Mobility: Always dynamic . 730 o Time Synchronization: Highly required. 732 o Reliability and QoS: TBD. 734 o Traffic patterns: Random. 736 o Security Bootstrapping: required. 738 6. IANA Considerations 740 There are no IANA considerations related to this document. 742 7. Security Considerations 744 [TBD] 746 8. Acknowledgements 748 Carles Gomez has been funded in part by the Spanish Government 749 (Ministerio de Educacion, Cultura y Deporte) through the Jose 750 Castillejo grant CAS15/00336. His contribution to this work has been 751 carried out during his stay as a visiting scholar at the Computer 752 Laboratory of the University of Cambridge. 754 9. References 755 9.1. Normative References 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, 759 DOI 10.17487/RFC2119, March 1997, 760 . 762 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 763 over Low-Power Wireless Personal Area Networks (6LoWPANs): 764 Overview, Assumptions, Problem Statement, and Goals", 765 RFC 4919, DOI 10.17487/RFC4919, August 2007, 766 . 768 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 769 "Transmission of IPv6 Packets over IEEE 802.15.4 770 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 771 . 773 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 774 Routing Requirements in Low-Power and Lossy Networks", 775 RFC 5826, DOI 10.17487/RFC5826, April 2010, 776 . 778 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 779 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 780 DOI 10.17487/RFC6282, September 2011, 781 . 783 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 784 Application Spaces for IPv6 over Low-Power Wireless 785 Personal Area Networks (6LoWPANs)", RFC 6568, 786 DOI 10.17487/RFC6568, April 2012, 787 . 789 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 790 Bormann, "Neighbor Discovery Optimization for IPv6 over 791 Low-Power Wireless Personal Area Networks (6LoWPANs)", 792 RFC 6775, DOI 10.17487/RFC6775, November 2012, 793 . 795 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 796 Constrained-Node Networks", RFC 7228, 797 DOI 10.17487/RFC7228, May 2014, 798 . 800 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 801 over ITU-T G.9959 Networks", RFC 7428, 802 DOI 10.17487/RFC7428, February 2015, 803 . 805 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 806 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 807 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 808 . 810 9.2. Informative References 812 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 813 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 814 December 1998, . 816 [I-D.ietf-6lo-dect-ule] 817 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 818 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 819 Energy", draft-ietf-6lo-dect-ule-03 (work in progress), 820 September 2015. 822 [I-D.ietf-6lo-6lobac] 823 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 824 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 825 6lo-6lobac-02 (work in progress), July 2015. 827 [I-D.ietf-6lo-nfc] 828 Youn, J. and Y. Hong, "Transmission of IPv6 Packets over 829 Near Field Communication", draft-ietf-6lo-nfc-01 (work in 830 progress), July 2015. 832 [I-D.ietf-lwig-energy-efficient] 833 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 834 Efficient Features of Internet of Things Protocols", 835 draft-ietf-lwig-energy-efficient-04 (work in progress), 836 February 2016. 838 [I-D.ietf-roll-applicability-ami] 839 Popa, D., Gillmore, M., Toutain, L., Hui, J., Salazar, R., 840 Monden, K., and N. Cam-Winget, "Applicability Statement 841 for the Routing Protocol for Low Power and Lossy Networks 842 (RPL) in AMI Networks", draft-ietf-roll-applicability- 843 ami-11 (work in progress), August 2015. 845 [G.9959] "International Telecommunication Union, "Short range 846 narrow-band digital radiocommunication transceivers - PHY 847 and MAC layer specifications", ITU-T Recommendation", 848 January 2015. 850 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership 851 Project; Technical Specification Group Radio Access 852 Network; Evolved Universal Terrestrial Radio Access 853 (E-UTRA); User Equipment (UE) radio access capabilities 854 (Release 13)", December 2015. 856 Authors' Addresses 858 Yong-Geun Hong 859 ETRI 860 161 Gajeong-Dong Yuseung-Gu 861 Daejeon 305-700 862 Korea 864 Phone: +82 42 860 6557 865 Email: yghong@etri.re.kr 867 Carles Gomez 868 Universitat Politecnica de Catalunya/Fundacio i2cat 869 C/Esteve Terradas, 7 870 Castelldefels 08860 871 Spain 873 Email: carlesgo@entel.upc.edu 875 Younghwan Choi 876 ETRI 877 218 Gajeongno, Yuseong 878 Daejeon 305-700 879 Korea 881 Phone: +82 42 860 1429 882 Email: yhc@etri.re.kr 883 Deoknyong Ko 884 SKtelecom 885 9-1 Byundang-gu Sunae-dong, Seongnam-si 886 Gyeonggi-do 13595 887 Korea 889 Phone: +82 10 3356 8052 890 Email: engineer@sk.com