Use cases for IPv6 over Networks of Resource-constrained Nodes
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Authors||Yong-Geun Hong , Carles Gomez|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
6Lo Working Group Y-G. Hong Internet-Draft ETRI Intended status: Standards Track C. Gomez Expires: September 22, 2016 UPC/i2cat Y-H. Choi ETRI D-Y. Ko SKtelecom March 21, 2016 Use cases for IPv6 over Networks of Resource-constrained Nodes draft-hong-6lo-use-cases-01 Abstract This document describes the characteristics of link layer technologies that are used at constrained node networks and typical use cases of IPv6 over networks of resource-constrained nodes. In addition to IEEE 802.15.4, various link layer technologies such as BLE, ITU-T G.9959 (Z-Wave), DECT-ULE, MS/TP, NFC, and LTE MTC are widely used at constrained node networks for typical services. Based on these link layer technologies, IPv6 over networks of resource- constrained nodes has various and practical use cases. To efficiently implement typical services, the applicability and consideration of several design spaces are described. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 22, 2016. Hong, et al. Expires September 22, 2016 [Page 1] Internet-Draft 6lo use cases March 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 4 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Master-Slave/Token-Passing . . . . . . . . . . . . . . . 5 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 7 5. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Use case of NFC: Alternative Secure Transfer . . . . . . 8 5.2. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 10 5.3. Use case of Bluetooth Low Energy: Smartphone-Based Interaction with Constrained Devices . . . . . . . . . . 12 5.4. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 13 5.5. Use case of LTE MTC . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Running IPv6 on constrained node networks has different features due to the characteristics of constrained node networks such as small packet size, short link-layer address, low bandwidth, network topology, low power, low cost, and large number of devices [RFC4919]. Hong, et al. Expires September 22, 2016 [Page 2] Internet-Draft 6lo use cases March 2016 For example, because some IEEE 802.15.4 link layers have a frame size of 127 octets and IPv6 requires an MTU of 1280 bytes, an appropriate fragmentation and reassembly adaptation layer must be provided at the layer of below IPv6. Also, the limited size of IEEE 802.15.4 frame, the length shortage of data delivery, and low energy consumption requirements make the need for header compression. IETF 6lowpan (IPv6 over Low powerWPAN) working group published [RFC4944], an adaptation layer for sending IPv6 packets over IEEE 802.15.4, [RFC6282], compression format for IPv6 datagrams over IEEE 802.15.4-based networks, and [RFC6775], Neighbor Discovery Optimization for 6lowpan. As IoT (Internet of Things) services become more popular, various link layer technologies such as Bluetooth Low Energy (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), and Near Field Communication (NFC) are actively used. And the need of transmission of IPv6 packets over these link layer technologies is required. A number of IPv6-over-foo documents have been developed in the IETF 6lo (IPv6 over Networks of Resource-constrained Nodes) and 6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e) working group. In the 6lowpan working group, the [RFC6568], "Design and Application Spaces for 6LoWPANs" was published and it describes potential application scenarios and use cases for low-power wireless personal area networks. In this document, various design space dimension such as deployment, network size, power source, connectivity, multi-hop communication, traffic pattern, security level, mobility, and QoS were analyzed. And it described a fundamental set of 6lowpan application scenarios and use cases: Industrial monitoring-Hospital storage rooms, Structural monitoring-Bridge safety monitoring, Connected home-Home Automation, Healthcare-Healthcare at home by tele-assistance, Vehicle telematics-telematics, and Agricultural monitoring-Automated vineyard. Even though the [RFC6568] describes some potential application scenarios and use cases and it lists the design space in the context of 6lowpan, it does not cover the different use cases and design space in the context of the 6lo working group. This document provides the use cases of 6lo, considering the following: o 6lo use cases MAY be uniquely different to the 6lowpan use cases. o 6lo use cases SHOULD cover various IoT related wire/wireless link layer technologies providing practical information of such technologies. Hong, et al. Expires September 22, 2016 [Page 3] Internet-Draft 6lo use cases March 2016 o 6lo use cases MAY describe characteristics and typical use cases of each link layer technology, and then 6lo use cases's applicability. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. 6lo Link layer technologies 3.1. ITU-T G.9959 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID network identifier is assigned by a network controller and how an 8-bit NodeID host identifier is allocated to each node. NodeIDs are unique within the network identified by the HomeID. The G.9959 HomeID represents an IPv6 subnet that is identified by one or more IPv6 prefixes [RFC7428]. 3.2. Bluetooth Low Energy Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 4.1, and developed even further in successive versions. Bluetooth SIG has also published Internet Protocol Support Profile (IPSP), which includes Internet Protocol Support Service (IPSS). The IPSP enables discovery of IP-enabled devices and establishment of link- layer connection for transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or newer. Devices such as mobile phones, notebooks, tablets and other handheld computing devices which will include Bluetooth 4.1 chipsets will also have the low-energy variant of Bluetooth. Bluetooth LE will also be included in many different types of accessories that collaborate with mobile devices such as phones, tablets and notebook computers. An example of a use case for a Bluetooth LE accessory is a heart rate monitor that sends data via the mobile phone to a server on the Internet [RFC7668]. 3.3. DECT-ULE DECT ULE is a low power air interface technology that is designed to support both circuit switched services, such as voice communication, and packet mode data services at modest data rate. Hong, et al. Expires September 22, 2016 [Page 4] Internet-Draft 6lo use cases March 2016 The DECT ULE protocol stack consists of the PHY layer operating at frequencies in the 1880 - 1920 MHz frequency band depending on the region and uses a symbol rate of 1.152 Mbps. Radio bearers are allocated by use of FDMA/TDMA/TDD technics. In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single Fixed Parts (FP) defining the network with a number of PP attached. The MAC layer supports traditional DECT as this is used for services like discovery, pairing, security features etc. All these features have been reused from DECT. The DECT ULE device can switch to the ULE mode of operation, utilizing the new ULE MAC layer features. The DECT ULE Data Link Control (DLC) provides multiplexing as well as segmentation and re- assembly for larger packets from layers above. The DECT ULE layer also implements per-message authentication and encryption. The DLC layer ensures packet integrity and preserves packet order, but delivery is based on best effort. The current DECT ULE MAC layer standard supports low bandwidth data broadcast. However the usage of this broadcast service has not yet been standardized for higher layers [I-D.ietf-6lo-dect-ule]. 3.4. Master-Slave/Token-Passing MS/TP is a contention-free access method for the RS-485 physical layer, which is used extensively in building automation networks. This specification defines the frame format for transmission of IPv6 [RFC2460] packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The general approach is to adapt elements of the 6LoWPAN [RFC4944] specification to constrained wired networks. An MS/TP device is typically based on a low-cost microcontroller with limited processing power and memory. Together with low data rates and a small address space, these constraints are similar to those faced in 6LoWPAN networks and suggest some elements of that solution might be leveraged. MS/TP differs significantly from 6LoWPAN in at least three respects: a) MS/TP devices typically have a continuous source of power, b) all MS/TP devices on a segment can communicate directly so there are no hidden node or mesh routing issues, and c) recent changes to MS/TP provide support for large payloads, eliminating the need for link-layer fragmentation and reassembly. MS/TP is designed to enable multidrop networks over shielded twisted pair wiring. It can support a data rate of 115,200 baud on segments up to 1000 meters in length, or segments up to 1200 meters in length Hong, et al. Expires September 22, 2016 [Page 5] Internet-Draft 6lo use cases March 2016 at lower baud rates. An MS/TP link requires only a UART, an RS-485 transceiver with a driver that can be disabled, and a 5ms resolution timer. These features make MS/TP a cost-effective field bus for the most numerous and least expensive devices in a building automation network [I-D.ietf-6lo-6lobac]. 3.5. NFC NFC technology enables simple and safe two-way interactions between electronic devices, allowing consumers to perform contactless transactions, access digital content, and connect electronic devices with a single touch. NFC complements many popular consumer level wireless technologies, by utilizing the key elements in existing standards for contactless card technology (ISO/IEC 14443 A&B and JIS-X 6319-4). NFC can be compatible with existing contactless card infrastructure and it enables a consumer to utilize one device across different systems. Extending the capability of contactless card technology, NFC also enables devices to share information at a distance that is less than 10 cm with a maximum communication speed of 424 kbps. Users can share business cards, make transactions, access information from a smart poster or provide credentials for access control systems with a simple touch. NFC's bidirectional communication ability is ideal for establishing connections with other technologies by the simplicity of touch. In addition to the easy connection and quick transactions, simple data sharing is also available [I-D.ietf-6lo-nfc]. 3.6. LTE MTC LTE category defines the overall performance and capabilities of the UE(User Equipment). For example, the maximum down rate of category 1 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. There are many categories in LTE standard. 3GPP standards defined the category 0 to be used for low rate IoT service in release 12. Since category 1 and category 0 could be used for low rate IoT service, we call LTE MTC[LTE_MTC]. LTE MTC have the advantages compared to above category 2 to be used for low rate IoT service such as low power and low cost. The below figure shows the primary characteristics of LTE MTC. Hong, et al. Expires September 22, 2016 [Page 6] Internet-Draft 6lo use cases March 2016 +------------+---------------------+-------------------+ | Category | Max. Date Rate Down | Max. Date Rate Up | +------------+---------------------+-------------------+ | Category 0 | 1.0 Mbit/s | 1.0 Mbit/s | | | | | | Category 1 | 10.3 Mbit/s | 5.2 Mbit/s | +------------+---------------------+-------------------+ Table 1: Primary characteristics of LTE MTC 4. Design Space The [RFC6568] lists the dimensions used to describe the design space of wireless sensor networks in the context of the 6LoWPAN working group. The design space is already limited by the unique characteristics of a LoWPAN (e.g., low power, short range, low bit rate). In the RFC 6558, the following design space dimensions are described; Deployment, Network size, Power source, Connectivity, Multi-hop communication, Traffic pattern, Mobility, Quality of Service (QoS). The design space dimensions of 6lo are a little different to those of the RFC 6558 due to the different characteristics of 6lo link layer technologies. The following design space dimensions can be considered. o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or in an organized manner. The bootstrapping has different characteristics of each link layer technologies. o Topology: Topology of 6lo networks may inherently follow the characteristics of each link layer technology. Point-to-point, star, tree or mesh topologies can be configured. o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the characteristics of each link layer technologies. Some link layer technologies may support L2-mesh and some may not support. o Multi-link subnet, single subnet: The selection of multi-link subnet and single subnet depends on connectivity and the number of 6lo nodes. o Data rate: Originally, the link layer technologies of 6lo have low rate of data transmission. But, by adjusting the MTU, it can deliver higher data rate. Hong, et al. Expires September 22, 2016 [Page 7] Internet-Draft 6lo use cases March 2016 o Buffering requirements: Some 6lo use case may require more data rate than the link layer technology support. In this case, a buffering mechanism to manage the date is required. o Security Requirements: Some 6lo use case can transfer some important and personal data between 6lo nodes. In this case, high-level security support is required. o Mobility across 6lo networks and subnets: The movement of 6lo nodes is dependent on the 6lo use case. If the 6lo nodes can move or moved around, it requires the mobility management mechanism. o Time synchronization requirements: The requirement of time synchronization of the upper layer service is dependent on the 6lo use case. For some 6lo use case related to health service, the measured data must be recorded with exact time and must be transferred with time synchronization. o Reliability and QoS: Some 6lo use case requires high reliability, for example real-time service or health-related services. o Traffic patterns: 6lo use case may various traffic patterns. Some 6lo use case may require short data length and randomly. Some 6lo use case may require continuous data and periodic data transmission. o Security Bootstrapping: Without the external operations, 6lo nodes must have the security bootstrapping mechanism. o Power use strategy: to enable certain use cases, there may be requirements on the class of energy availability and the strategy followed for using power for communication [RFC7228]. Each link layer technology defines a particular power use strategy which may be tuned [I-D.ietf-lwig-energy-efficient]. o Energy limitation: The energy limitation class [RFC7228] is specific to each use case, and may or may not be related to the power use strategy. 5. 6lo Use Cases 5.1. Use case of NFC: Alternative Secure Transfer According to applications, various secured data can be handled and transferred. Depending on security level of the data, methods for transfer can be alternatively selected. The personal data having serious issues should be transferred securely, but data transfer by using Wi-Fi and Bluetooth connections cannot always be secure because Hong, et al. Expires September 22, 2016 [Page 8] Internet-Draft 6lo use cases March 2016 of their a little long radio frequency range. Hackers can overhear the personal data transfer behind hidden areas. Therefore, methods need to be alternatively selected to transfer secured data. Voice and video data, which are not respectively secure and requires long transmission range, can be transferred by 3G/4G technologies, such as WCDMA, GSM, and LTE. Big size data, which are not secure and requires high speed and broad bandwidth, can be transferred by Wi-Fi and wired network technologies. However, the person data, which are serious issues so requires secure transfer in wireless area, can be securely transferred by NFC technology. It has very short frequency range ? nearly single touch communication. Example: Secure Transfer by Using NFC in Healthcare Services with Tele-Assistance A senior citizen who lives alone wears one to several wearable 6lo devices to measure heartbeat, pulse rate, etc. The 6lo devices are densely installed at home for movement detection. An LoWPAN Border Router (LBR) at home will send the sensed information to a connected healthcare center. Portable base stations with LCDs may be used to check the data at home, as well. Data is gathered in both periodic and event-driven fashion. In this application, event-driven data can be very time-critical. In addition, privacy also becomes a serious issue in this case, as the sensed data is very personal. While the senior citizen is provided audio and video healthcare services by a tele-assistance based on LTE connections, the senior citizen can alternatively use NFC connections to transfer the personal sensed data to the tele-assistance. At this moment, hidden hackers can overhear the data based on the LTE connection, but they cannot gather the personal data over the NFC connection. +-------------+ +-------------+ |voice & video|....... LTE connection ......>|voice & video| | data |<...... LTE connection .......| data | +-------------+ +-------------+ | sensed data |....... NFC connection ......>| | | |<...... NFC connection .......| personal | | | | result data | +-------------+ +-------------+ (patient) (tele-assistance) Figure 1: Alternative Secure Transfer in Healthcare Services Dominant parameters in secure transfer by using NFC in healthcare services: Hong, et al. Expires September 22, 2016 [Page 9] Internet-Draft 6lo use cases March 2016 o Deployment/Bootstrapping: Pre-planned. MP2P/P2MP (data collection), P2P (local diagnostic). o Topology: Small, NFC-enabled device connected to the Internet. o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be configured. o Multi-link subnet, single subnet: a Single-hop for gateway; patient's body network is mesh topology. o Data rate: Small data rate. o Buffering requirements: Low requirement. o Security requirements: Data privacy and security must be provided. Encryption is required. o Mobility: Moderate (patient's mobility). o Time Synchronization: Highly required. o Reliability and QoS: High level of reliability support (life-or- death implication), role-based. o Traffic patterns: Short data length and periodic (randomly). o Security Bootstrapping: Highly required. o Other Issues: Plug-and-play configuration is required for mainly non-technical end-users. Real-time data acquisition and analysis are important. Efficient data management is needed for various devices that have different duty cycles, and for role-based data control. Reliability and robustness of the network are also essential. 5.2. Use case of ITU-T G.9959: Smart Home Z-Wave is one of the main technologies that may be used to enable smart home applications. Born as a proprietary technology, Z-Wave was specifically designed for this use case. Recently, the Z-Wave radio interface (physical and MAC layers) has been standardized as the ITU-T G.9959 specification. Example: Use of ITU-T G.9959 for Home Automation Variety of home devices (e.g. light dimmers/switches, plugs, thermostats,blinds/curtains and remote controls) are augmented with Hong, et al. Expires September 22, 2016 [Page 10] Internet-Draft 6lo use cases March 2016 ITU-T G.9959 interfaces. A user may turn on/off or may control home appliances by pressing a wall switch or by pressing a button in a remote control. Scenes may be programmed, so that after a given event, the home devices adopt a specific configuration. Sensors may also periodically send measurements of several parameters (e.g. gas presence, light, temperature, humidity, etc.) which are collected at a sink device, or may generate commands for actuators (e.g. a smoke sensor may send an alarm message to a safety system). The devices involved in the described scenario are nodes of a network that follows the mesh topology, which is suitable for path diversity to face indoor multipath propagation issues. The multihop paradigm allows end-to-end connectivity when direct range communication is not possible. Security support is required, specially for safety-related communication. When a user interaction (e.g. a button press) triggers a message that encapsulates a command, if the message is lost, the user may have to perform further interactions to achieve the desired effect (e.g. a light is turned off). A reaction to a user interaction will be perceived by the user as immediate as long as the reaction takes place after less than 0.5 seconds [RFC5826]. Dominant parameters in home automation scenarios with ITU-T G.9959: o Deployment/Bootstrapping: Pre-planned. o Topology: Mesh topology. o L2-mesh or L3-mesh: ITU-T G.9959 provides support for L2-mesh, and L3-mesh can also be used (the latter requires an IP-based routing protocol). o Multi-link subnet, single subnet: Multi-link subnet. o Data rate: Small data rate, infrequent transmissions. o Buffering requirements: Low requirement. o Security requirements: Data privacy and security must be provided. Encryption is required. o Mobility: Most devices are static. A few devices (e.g. remote control) are portable. o Time Synchronization: TBD. o Reliability and QoS: Moderate to high level of reliability support. Actions as a result of human-generated traffic should occur after less than 0.5 seconds. Hong, et al. Expires September 22, 2016 [Page 11] Internet-Draft 6lo use cases March 2016 o Traffic patterns: Periodic (sensor readings) and aperiodic (user- triggered interaction). o Security Bootstrapping: Required. 5.3. Use case of Bluetooth Low Energy: Smartphone-Based Interaction with Constrained Devices The key feature behind the current high Bluetooth LE momentum is its support in a large majority of smartphones in the market. Bluetooth LE can be used to allow the interaction between the smartphone and surrounding sensors or actuators. Furthermore, Bluetooth LE is also the main radio interface currently available in wearables. Since a smartphone typically has several radio interfaces that provide Internet access, such as Wi-Fi or 4G, the smartphone can act as a gateway for nearby devices such as sensors, actuators or wearables. Bluetooth LE may be used in several domains, including healthcare, sports/wellness and home automation. Example: Bluetooth LE-based Body Area Network for fitness A person wears a smartwatch for fitness purposes. The smartwatch has several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, temperature, etc.), a display, and a Bluetooth LE radio interface. The smartwatch can show fitness-related statistics on its display. However, when a paired smartphone is in the range of the smartwatch, the latter can report almost real-time measurements of its sensors to the smartphone, which can forward the data to a cloud service on the Internet. In addition, the smartwatch can receive notifications (e.g. alarm signals) from the cloud service via the smartphone. On the other hand, the smartphone may locally generate messages for the smartwatch, such as e-mail reception or calendar notifications. The functionality supported by the smartwatch may be complemented by other devices such as other on-body sensors, wireless headsets or head-mounted displays. All such devices may connect to the smartphone creating a star topology network whereby the smartphone is the central component. Dominant parameters in home automation scenarios with Bluetooth LE: o Deployment/Bootstrapping: Pre-planned. o Topology: Star topology. o L2-mesh or L3-mesh: No. o Multi-link subnet, single subnet: Multi-link subnet. Hong, et al. Expires September 22, 2016 [Page 12] Internet-Draft 6lo use cases March 2016 o Data rate: TBD. o Buffering requirements: Low requirement. o Security requirements: For health-critical information, data privacy and security must be provided. Encryption is required. Some types of notifications sent by the smartphone may not need. o Mobility: Low. o Time Synchronization: the link layer, which is based on TDMA, provides a basis for time synchronization. o Reliability and QoS: a relatively low ratio of message losses is acceptable for periodic sensor readings. End-to-end latency of sensor readings is not subject to stringent requirements. The latency of should be low for critical notifications or alarms, generated by either the smartphone or an Internet cloud service. o Traffic patterns: periodic (sensor readings) and aperiodic (smartphone-generated notifications). o Security Bootstrapping: Required. 5.4. Use case of DECT-ULE: Smart Home DECT is a technology widely used for wireless telephone communicatio s in residential scenarios. Since DECT-ULE is a low-power variant of DECT, DECT-ULE can be used to connect constrained devices such as sensors and actuators to a Fixed Part, a device that typically acts as a base station for wireless telephones. Therefore, DECT-ULE is specially suitable for the connected home space in application areas such as home automation, smart metering, safety, healthcare, etc. Example: use of DECT-ULE for Smart Metering The smart electricity meter of a home is equipped with a DECT-ULE transceiver. This device is in the coverage range of the Fixed Part of the home. The Fixed Part can act as a router connected to the Internet. This way, the smart meter can transmit electricity consumption readings through the DECT-ULE link with the Fixed Part, and the latter can forward such readings to the utility company using Wide Area Network (WAN) links. The meter can also receive queries from the utility company or from an advanced energy control system controlled by the user, which may also be connected to the Fixed Part via DECT-ULE. Dominant parameters in smart metering scenarios with DECT-ULE: Hong, et al. Expires September 22, 2016 [Page 13] Internet-Draft 6lo use cases March 2016 o Deployment/Bootstrapping: Pre-planned. o Topology: Star topology. o L2-mesh or L3-mesh: No. o Multi-link subnet, single subnet: Multi-link subnet. o Data rate: Small data rate, infrequent transmissions. o Buffering requirements: Low requirement. o Security requirements: Data privacy and security must be provided. Encryption is required. o Mobility: No. o Time Synchronization: TBD. o Reliability and QoS: bounded latency, stringent reliability service agreements [I-D.ietf-roll-applicability-ami]. o Traffic patterns: Periodic (meter reading notifications sent by the meter) and aperiodic (user- or company-triggered queries to the meter, and messages triggered by local events such as power outage or leak detection [I-D.ietf-roll-applicability-ami]). o Security Bootstrapping: required. 5.5. Use case of LTE MTC Wireless link layer technologies can be divided short range connectivity and long range connectivity. BLE, ITU-T G.9959 (Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity. LTE MTC is used for long range connectivity. And there is another long range connectivity technology. It is LPWAN(Low Power Wide Area Network) technology such as LoRa, Sigfox and etc. Therefore, the use case of LTE MTC should be compared to LPWAN. Example: Use of wireless backhaul for LoRa gateway LoRa is the most promising technology of LPWAN. LoRa network architecture has a star of stat topology. LoRa gateway relay the messages from LoRa end device to application server and vice versa. LoRa gateway can has two types of backhaul, wired and wireless backhaul. Hong, et al. Expires September 22, 2016 [Page 14] Internet-Draft 6lo use cases March 2016 If LoRa gateway has wireless backhaul, it should have LTE modem. Since the modem cost of LTE MTC is cheaper than the modem cost of above LTE category 2, it is helpful to design to use LTE MTC. Since the maximum date rate of LoRa end device is 50kbps, it is sufficient to use LTE MTC without using category 2. Dominant parameters in LoRa gateway scenarios with above example: o Deployment/Bootstrapping: Pre-planned. o Topology: Star topology. o L2-mesh or L3-mesh: No. o Multi-link subnet, single subnet: Single subnet. o Data rate: depends on 3GPP specification. o Buffering requirements: High requirement. o Security requirements: No, because data security is already provided in LoRa specification. o Mobility: Static. o Time Synchronization: Highly required. o Reliability and QoS: TBD. o Traffic patterns: Random. o Security Bootstrapping: required. Example: Use of controlling car Car sharing service becomes more popular. Customers wish to control the car with smart phone application. For example, customers wish to lock/unlock the car door with smart phone application, because customers may not have a car key. Customers wish to blow with smart phone application to locate the car easily. Therefore, rental car should have a long range connectivity capable modem such as LoRa end device and LTE UE. However, LoRa may not be used because LoRa has low reliability and may not is supported in indoor environment such as basement parking lot. And since the message of controlling car is very small, it is sufficient to use LTE MTC but above category 2. Hong, et al. Expires September 22, 2016 [Page 15] Internet-Draft 6lo use cases March 2016 Dominant parameters in controlling car scenarios with above example: o Deployment/Bootstrapping: Pre-planned. o Topology: Star topology. o L2-mesh or L3-mesh: No. o Multi-link subnet, single subnet: Single subnet. o Data rate: depends on 3GPP specification. o Buffering requirements: High requirement. o Security requirements: High requirement. o Mobility: Always dynamic . o Time Synchronization: Highly required. o Reliability and QoS: TBD. o Traffic patterns: Random. o Security Bootstrapping: required. 6. IANA Considerations There are no IANA considerations related to this document. 7. Security Considerations [TBD] 8. Acknowledgements Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336. His contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge. 9. References Hong, et al. Expires September 22, 2016 [Page 16] Internet-Draft 6lo use cases March 2016 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, <http://www.rfc-editor.org/info/rfc5826>. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>. [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, DOI 10.17487/RFC6568, April 2012, <http://www.rfc-editor.org/info/rfc6568>. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. Hong, et al. Expires September 22, 2016 [Page 17] Internet-Draft 6lo use cases March 2016 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <http://www.rfc-editor.org/info/rfc7428>. [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <http://www.rfc-editor.org/info/rfc7668>. 9.2. Informative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [I-D.ietf-6lo-dect-ule] Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Energy", draft-ietf-6lo-dect-ule-03 (work in progress), September 2015. [I-D.ietf-6lo-6lobac] Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", draft-ietf- 6lo-6lobac-02 (work in progress), July 2015. [I-D.ietf-6lo-nfc] Youn, J. and Y. Hong, "Transmission of IPv6 Packets over Near Field Communication", draft-ietf-6lo-nfc-01 (work in progress), July 2015. [I-D.ietf-lwig-energy-efficient] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- Efficient Features of Internet of Things Protocols", draft-ietf-lwig-energy-efficient-04 (work in progress), February 2016. [I-D.ietf-roll-applicability-ami] Popa, D., Gillmore, M., Toutain, L., Hui, J., Salazar, R., Monden, K., and N. Cam-Winget, "Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks", draft-ietf-roll-applicability- ami-11 (work in progress), August 2015. Hong, et al. Expires September 22, 2016 [Page 18] Internet-Draft 6lo use cases March 2016 [G.9959] "International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications", ITU-T Recommendation", January 2015. [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities (Release 13)", December 2015. Authors' Addresses Yong-Geun Hong ETRI 161 Gajeong-Dong Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 6557 Email: email@example.com Carles Gomez Universitat Politecnica de Catalunya/Fundacio i2cat C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: firstname.lastname@example.org Younghwan Choi ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea Phone: +82 42 860 1429 Email: email@example.com Hong, et al. Expires September 22, 2016 [Page 19] Internet-Draft 6lo use cases March 2016 Deoknyong Ko SKtelecom 9-1 Byundang-gu Sunae-dong, Seongnam-si Gyeonggi-do 13595 Korea Phone: +82 10 3356 8052 Email: firstname.lastname@example.org Hong, et al. Expires September 22, 2016 [Page 20]