| Network Working Group | A. Minaburo, Ed. |
| Internet-Draft | Acklio |
| Intended status: Informational | C. Gomez, Ed. |
| Expires: April 22, 2017 | UPC/i2CAT |
| L. Toutain | |
| Institut MINES TELECOM ; TELECOM Bretagne | |
| J. Paradells | |
| UPC/i2CAT | |
| J. Crowcroft | |
| University of Cambridge | |
| October 19, 2016 |
LPWAN Survey and GAP Analysis
draft-minaburo-lpwan-gap-analysis-02
Low Power Wide Area Networks (LPWAN) are technologies covering different applications based on long range, low bandwidth and low power operation. The use of IETF protocols in the LPWAN technologies should contribute to the deployment of a wide number of applications in an open and standard environment where actual devices using LPWAN technologies will be able to communicate. This document makes a survey of the principal characteristics of these technologies and provides the gaps for the integration on the IETF protocol stack.
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 April 22, 2017.
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.
LPWAN (Low-Power Wide Area Network) technologies define long range, low bit rate and low power wireless interfaces that are a kind of constrained and challenged networks [RFC7228]. They can operate in license or license-exempt bands to provide connectivity to a vast number of battery-powered devices requiring limited communications.
If the existing pilot deployments have shown the huge potential and the industrial interest in their capabilities, the loose coupling with the Internet makes the device management and network operation complex. More importantly, LPWAN devices are, as of today, with no IP capabilities.
Connecting LPWANs to the Internet would provide significant benefits to these networks in terms of interoperability, application deployment, and management, among others. The goal is to adapt IETF defined protocols, addressing schemes and naming spaces to this constrained environment. This document surveys the main characteristics of LPWAN technologies, and analyzes the gaps for the integration of the IETF protocol stack in the LPWAN technologies.
The LPWANs are large-scale constrained networks in the sense of [RFC7228] with the following characteristics:
In the terminology of [RFC7228], these characteristics put LP-WANs into the “challenged network” category where the IP connectivity has to be redefined or modified. Therefore, LPWANs need to be considered as a separate class of networks with the following desired properties:
The data transmission rate (DTR) is the amount of digital data that is moved from one device to another in a given time. In a network, the DTR can be viewed as the speed of travel of a given amount of data. The greater the bandwidth of a path the higher the DTR (usually measured in bit per second, bit/s). For example, a low-speed connection to the Internet may have a DTR of 33.6 kilobit/s.
LPWAN DTR is lower than 1 byte/s in the most constrained links. So standard marks need to be adjusted, like for instance, instead of sending data per second we are sending the data per day. Which implies that many of the actual protocols need to be adapted to this new scale.
Timers, delays, RTTs, buffers, etc. will need to make a time shift in order to correctly perform over an LPWAN link. A concrete example could be the CoAP timers that need to be tuned properly.
LPWAN technologies, such as LoRaWAN, NB-IOT and SIGFOX, have similar architectures but different terminology. We can identify different types of entities in a typical LPWAN network:
+---------------------------------------------------------------------+
| Function/ | | | | |
| Technology | LORAWAN | NB-IOT | SIGFOX | IETF |
+--------------+-----------+------------+-------------+---------------+
| Sensor, | | | | |
| Actuator, | End | User | End | Thing |
|device, object| Device | Equipment | Point | (HOST) |
+--------------+-----------+------------+-------------+---------------+
| Transceiver | | Evolved | Base | RADIO |
| Antenna | Gateway | Node B | Station | GATEWAY |
+--------------+-----------+------------+-------------+---------------+
| Server | Network | Serving- | Service |Network Gateway|
| | Server | Gateway | Center | (ROUTER) |
+--------------+-----------+------------+-------------+---------------+
| Security | Join | Home |Registration | |
| Server | Server | Subscriber | Authority | AAA |
| | | Server | | SERVER |
+--------------+-----------+------------+-------------+---------------+
| Application |Application| Packet Data| Network | APPLICATION |
| | Server |Node Gateway| Application | SERVER |
+---------------------------------------------------------------------+
LPWAN Architecture Terminology
Figure 1
() () () | +------+
() () () () / \ +---------+ | AAA |
() () () () () () / \========| /\ |====|Server| +-----------+
() () () | | <--|--> | +------+ |Application|
() () () () / \============| v |==============| Server |
() () () / \ +---------+ +-----------+
HOSTS Radio Gateways Network Gateway
LPWAN Architecture
Figure 2
IPv6 [RFC2460] has been designed to allocate addresses to all the nodes connected to the Internet. Nevertheless, the header overhead of, at least, 40 bytes introduced by the protocol is incompatible with the LPWAN constraints. If IPv6 (with no further optimization) were used, several LPWAN frames would be needed just to carry the header, discussion on this point is developed in the 6LoWPAN section below. Another limitation comes from the IPv6 MTU requirement, by which the layer below IP has to support packets of at least 1280 bytes [RFC2460].
IPv6 needs a configuration protocol (neighbor discovery protocol, NDP [RFC4861]) for a node to learn network parameters, and the node relation with its neighbours. This protocol generates a regular traffic with a large message size that does not fit LPWAN constraints.
In some LPWAN technologies, layer two multicast is not supported. In that case, if the network topology is a star, the solution and considerations of section 3.2.5 of [RFC7668] may be applied.
Several technologies that exhibit significant constraints in various dimensions have exploited the 6LoWPAN suite of specifications [RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use-cases]. However, the constraints of LPWANs, often more extreme than those typical of technologies that have (re)used 6LoWPAN, constitute a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. LPWANs are characterised by device constraints (in terms of processing capacity, memory, and energy availability), and specially, link constraints, such as:
6LoWPAN header compression reduces IPv6 (and UDP) header overhead by eliding header fields when they can be derived from the link layer, and by assuming that some of the header fields will frequently carry expected values. 6LoWPAN provides both stateless and stateful header compression. In the latter, all nodes of a 6LoWPAN are assumed to share compression context. In the best case, the IPv6 header for link-local communication can be reduced to only 2 bytes. For global communication, the IPv6 header may be compressed down to 3 bytes in the most extreme case. However, in more practical situations, the lowest IPv6 header size may be 11 bytes (one address prefix compressed) or 19 bytes (both source and destination prefixes compressed). These headers are large considering the link layer payload size of LPWAN technologies, and in some cases are even bigger than the LPWAN PDUs. 6LoWPAN has been initially designed for IEEE 802.15.4 networks with a frame size up to 127 bytes and a throughput of up to 250 kb/s, which may or may not be duty-cycled.
In the ambit of 6LoWPAN, traditionally, Interface Identifiers (IIDs) have been derived from link layer identifiers [RFC4944] . This allows optimisations such as header compression. Nevertheless, recent guidance has given advice on the fact that, due to privacy concerns, 6LoWPAN devices should not be configured to embed their link layer addresses in the IID by default.
As stated above, IPv6 requires the layer below to support an MTU of 1280 bytes [RFC2460]. Therefore, given the low maximum payload size of LPWAN technologies, fragmentation is needed.
If a layer of an LPWAN technology supports fragmentation, proper analysis has to be carried out to decide whether the fragmentation functionality provided by the lower layer or fragmentation at the adaptation layer should be used. Otherwise, fragmentation functionality shall be used at the adaptation layer.
6LoWPAN defined a fragmentation mechanism and a fragmentation header to support the transmission of IPv6 packets over IEEE 802.15.4 networks [RFC4944]. While the 6LoWPAN fragmentation header is appropriate for IEEE 802.15.4-2003 (which has a frame payload size of 81-102 bytes), it is not suitable for several LPWAN technologies, many of which have a maximum payload size that is one order of magnitude below that of IEEE 802.15.4-2003. The overhead of the 6LoWPAN fragmentation header is high, considering the reduced payload size of LPWAN technologies and the limited energy availability of the devices using such technologies. Furthermore, its datagram offset field is expressed in increments of eight octets. In some LPWAN technologies, the 6LoWPAN fragmentation header plus eight octets from the original datagram exceeds the available space in the layer two payload. In addition, the MTU in the LPWAN networks could be variable which implies a variable fragmentation solution.
6LoWPAN Neighbor Discovery [RFC6775] defined optimizations to IPv6 Neighbor Discovery [RFC4861], in order to adapt functionality of the latter for networks of devices using IEEE 802.15.4 or similar technologies. The optimizations comprise host-initiated interactions to allow for sleeping hosts, replacement of multicast-based address resolution for hosts by an address registration mechanism, multihop extensions for prefix distribution and duplicate address detection (note that these are not needed in a star topology network), and support for 6LoWPAN header compression.
6LoWPAN Neighbor Discovery may be used in not so severely constrained LPWAN networks. The relative overhead incurred will depend on the LPWAN technology used (and on its configuration, if appropriate). In certain LPWAN setups (with a maximum payload size above ~60 bytes, and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange may be completed in a few seconds, without incurring packet fragmentation. In other LPWANs (with a maximum payload size of ~10 bytes, and a message rate of ~0.1 message/minute), the same exchange may take hours or even days, leading to severe fragmentation and consuming a significant amount of the available network resources. 6LoWPAN Neighbor Discovery behavior may be tuned through the use of appropriate values for the default Router Lifetime, the Valid Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as the address Registration Lifetime. However, for the latter LPWANs mentioned above, 6LoWPAN Neighbor Discovery is not suitable.
The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6 support over a variety of constrained node link layer technologies such as Bluetooth Low Energy (BLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC or IEEE 802.11ah.
These technologies are relatively similar in several aspects to IEEE 802.15.4, which was the original 6LoWPAN target technology. 6LoWPAN has been the basis for the functionality defined by 6Lo, which has mostly used the subset of 6LoWPAN techniques most suitable for each lower layer technology, and has provided additional optimizations for technologies where the star topology is used, such as BLE or DECT-ULE.
The main constraint in these networks comes from the nature of the devices (constrained devices), whereas in LPWANs it is the network itself that imposes the most stringent constraints.
The 6tisch solution is dedicated to mesh networks that operate using 802.15.4e MAC with a deterministic slotted channel. The TSCH can help to reduce collisions and to enable a better balance over the channels. It improves the battery life by avoiding the idle listening time for the return channel.
A key element of 6tisch is the use of synchronization to enable determinism. TSCH and 6TiSCH may provide a standard scheduling function. The LPWAN networks probably will not support synchronization like the one used in 6tisch.
RoHC header compression mechanisms were defined for point to point multimedia channels, to reduce the header overhead of the RTP flows, it can also reduce the overhead of IPv4 or IPv6 or IPv4/v6/UDP headers. It is based on a shared context which does not require any state but packets are not routable. The context is initialised at the beginning of the communication or when it is lost. The compression is managed using a sequence number (SN) which is encoded using a window algorithm letting the reduction of the SN to 4 bits instead of 2 bytes. But this window needs to be updated each 15 packets which implies larger headers. When RoHC compression is used we talk about an average header compression size to give the performance of compression. For example, the compression start sending bigger packets than the original (52 bytes) to reduce the header up to 4 bytes (it stays here only for 15 packets, which correspond to the window size). Each time the context is lost or needs to be synchronised, packets of about 15 to 43 bytes are sent.
The RoHC header compression is not adapted to the constrained nodes of the LPWAN networks: it does not take into account the energy limitations and the transmission rate, and context is synchronised during the transmission, which does not allow a better compression.
The LPWAN technologies considered by the lpwan WG are based on a star topology, which eliminates the need for routing. Future works may address additional use-cases which may require the adaptation of existing routing protocols or the definition of new ones. As of the writing, the work done at the ROLL WG and other routing protocols are out of scope of the LPWAN WG.
CoRE provides a resource-oriented framework for applications intended to run on constrained IP networks. It may be necessary to adapt the protocols to take into account the duty cycling and the potentially extremely limited throughput of LPWANs.
For example, some of the timers in CoAP may need to be redefined. Taking into account CoAP acknowledgements may allow the reduction of L2 acknowledgements. On the other hand, the current work in progress in the CoRE WG where the COMI/CoOL network management interface which, uses Structured Identifiers (SID) to reduce payload size over CoAP proves to be a good solution for the LPWAN technologies. The overhead is reduced by adding a dictionary which matches a URI to a small identifier and a compact mapping of the YANG model into the CBOR binary representation.
Most of the LPWAN technologies integrate some authentication or encryption mechanisms (see Section 5) that may not have been defined by the IETF. The working group will work to integrate these mechanisms to unify management. For the technologies which are not integrating natively security protocols, it is necessary to adapt existing mechanisms to the LPWAN constraints. The AAA infrastructure brings a scalable solution. It offers a central management for the security processes, draft-garcia- dime-diameter-lorawan-00 and draft-garcia-radext-radius-lorawan-00 explain the possible security process for a LoRaWAN network. The mechanisms basically are divided in: key management protocols, encryption and integrity algorithms used. Most of the solutions do not present a key management procedure to derive specific keys for securing network and or data information. In most cases, a pre-shared key between the smart object and the communication endpoint is assumed.
LPWANs nodes can be mobile. However, LPWAN mobility is different from the one specified for Mobile IP. LPWAN implies sporadic traffic and will rarely be used for high-frequency, real-time communications. The applications do not generate a flow, they need to save energy and most of the time the node will be down. The mobility will imply most of the time a group of devices, which represent a network itself. The mobility concerns more the gateway than the devices.
NEMO Mobility solutions may be used in the case where some hosts belonging to the same Network gateway will move from one point to another and that they are not aware of this mobility.
The purpose of the DNS is to enable applications to name things that have a global unique name. Lots of protocols are using DNS to identify the objects, especially REST and applications using CoAP. Therefore, things should be registered in DNS. DNS is probably a good topic of research for LPWAN technologies, while the matching of the name and the IP information can be used to configure the LPWAN devices.
+-------------+---------------+--------------+--------+ |Technology |range | Throughput |MAC MTU | +-------------+---------------+--------------+--------+ |LoRa |2-5 km urban |0.3 to 50 kbps|256 B | | |<15 km suburban| | | +-------------+---------------+--------------+--------+ |SIGFOX |10 km urban |up:100/600 bps| 12/ | | |50 km rural |down: 600 bps | 8 B | +-------------+---------------+--------------+--------+ |IEEE802.15.4k| < 20 km LoS |1.5 bps to |16/24/ | |LECIM | < 5 km NoLoS | 128 kbps | 32 B | +-------------+---------------+--------------+--------+ |IEEE802.15.4g| 2-3 km LoS | 4.8 kbps to |2047 B | |SUN | |800 kbps | | +-------------+---------------+--------------+--------+ |RPMA | 65 km LoS | up: 624kbps |64 B | | | 20 km NoLoS |down: 156kbps | | | | | mob: 2kbps | | +-------------+---------------+--------------+--------+ |DASH-7 | 2 km | 9 kbps |256 B | | | | 55.55 kbps | | | | | 166.66 kbps | | +-------------+---------------+--------------+--------+ |Weightless-w | 5 km urban | 1 kbps to |min 10 B| | | | 10 Mbps | | +-------------+---------------+--------------+--------+ |Weightless-n |<5 km urban | 30 kbps to |max 20 B| | |<30 km suburban| 100kbps | | +-------------+---------------+--------------+--------+ |Weightless-p |> 2 km urban | up to 100kbps| | +-------------+---------------+--------------+--------+ | NB-IoT * | <15 km | ~ 200kbps | >1000B | +-------------+---------------+--------------+--------+ * supports segmentation
Figure 3: Survey of LPWAN technologies
Different technologies can be included under the LPWAN acronym. The following list is the result of a survey among the first participant to the mailing-list. It cannot be exhaustive but is representative of the current trends.
The table Figure 3 gives some key performance parameters for some candidate technologies. The maximum MTU size must be taken carefully, for instance in LoRa, it take up to 2 sec to send a 50 Byte frame using the most robust modulation. In that case the theoretical limit of 256 B will be impossible to reach.
Most of the technologies listed in the Annex A work in the ISM band and may be used for private a public networks. Weightless-W uses white spaces in the TV spectrum and NB-LTE will use licensed channels. Some technologies include encryption at layer 2.
LORAWAN
LoRaWAN provides a joining procedure called “Over the Air Activation” that enables a smart object to securely join the network, deriving the necessary keys to perform the communications securely. The messages are integrity protected and the application information is ciphered with the derived keys from the joining procedure.
The joining procedure consists of one exchange, that entails a join-request message and a join-accept message. Upon successful authentication, the smart- object and the network-server are able to derive two keys to secure the communications (AppSKey and NwkSKey)
SIGFOX
The SIGFOX radio protocol provides mechanisms to authenticate and ensure integrity of the message. This is achieved by using a unique device ID and a message authentication code, which allow ensuring that the message has been generated and sent by the device with the ID claimed in the message.
Security keys are independent for each device. These keys are associated with the device ID and they are pre-provisioned. Application data can be encrypted by the application provider.
IEEE802.15.4k and IEEE802.15.4g
There is no mention of acquiring key material to secure the communications.
DASH-7
DASH-7 defines 2 keys for specific users (root, user) and a network key. Provides network security, integrity and encryption. The process of how these keys are distributed is not explained.
RPMA
They use security algorithms and provides for mutual device authentication, message authentication and message confidentiality. No mention of how the key material is distributed.
Weightless
They offer a joining procedure to network by authenticating the smart object. Integrity of the messages, encryption and key distribution
NB-IoT
ToDo. Not Access to the specification.
Thanks you very much for the discussion and feedback on the LPWAN mailing list, namely, Alexander Pelov, Pascal Thubert, Samita Chakrabarti, Xavier Vilajosana, Misha Dohler, Florian Meier, Timothy J. Salo, Michael Richardson, Robert Cragie, Paul Duffy, Pat Kinney, Joaquin Cabezas and Bill Gage.
We would like also to thank Dan Garcia Carrillo and Rafael Marin Lopez for the input made for the security part.
Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336. Part of 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.