| 6lpwa | X. Vilajosana, Ed. |
| Internet-Draft | Worldsensing |
| Intended status: Standards Track | M. Dohler |
| Expires: January 9, 2017 | King's College London |
| A. Yegin | |
| Actility | |
| July 8, 2016 |
Transmission of IPv6 Packets over LoRaWAN
draft-vilajosana-lpwan-lora-hc-00
This document describes how IPv6 is transmitted over LoRaWAN using 6LowPAN techniques. LoRaWAN is a wireless communication system for long-range low-power low-data-rate applications. LoRaWAN networks typically are laid out in a star topology in the field with gateways relaying messages between end-devices and a central network server in the backend, the complete system referred to as star of stars network.
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 January 9, 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.
LoRa is a wireless technology for long-range low-power low-data-rate applications developed by Semtech, which is used in LoRaWAN networks. LoRaWAN networks typically are organized in a star-of-stars topology in which gateways relay messages between end-devices and a central network server in the backend. Gateways are connected to the network server via IP links while end-devices use single-hop LoRaWAN communication to one or many gateways. All communication is generally bi-directional, although uplink communication from end-devices to the network server are strongly favoured.
Communication between end-devices and gateways is spread out among different frequency channels and so-called spreading factors. Selecting a spreading factor is a trade-off between required link budget and data rate. Spreading factors create virtual and orthogonal non-interfering communication channels that enable simultaneous transmissions. Depending on the used spreading factor, LoRaWAN data rates range from 0.3 kbps to 50 kbps. To maximize both battery life of end-devices and overall network capacity, the LoRaWAN network infrastructure manages the data rate and RF output for each end-device individually by means of an adaptive data rate (ADR) scheme. End-devices may transmit on any channel available at any time, using any available data rate.
The consolidation of that technology and its important impact in the M2M market, is triggering the need for end to end IP connectivity from end devices to the backend server without the need of proxying roles taken at Gateways. Due to the constrained nature of LoRaWAN devices, the compression techniques developed by 6LowPAN become mandatory. The present document specifies how IPv6 and the 6LowPAN architecture run on top of the LoRaWAN MAC layer.
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 RFC 2119 [RFC2119].
TODO briefly describe the technology. Phy layer and modulation. MAC operation and frame formats.
Figure 1: LoRaWAN Class A transmission and reception window.
|----------------------------| |--------| |--------|
| Tx | | Rx | | Rx |
|----------------------------| |--------| |--------|
|---------|
Rx delay 1
|------------------------|
Rx delay 2
The LoRaWAN technology enables low power wide area network coverage at the cost of reduced data rate and to obey to strict spectrum occupancy regulations. This imposes strict communication limitations that make applications using LoRaWAN to contain the amount of data that is transmitted. 6LoWPAN standards RFC4944, RFC6775, and RFC6282 enable IP connectivity while leverage the overhead of fully IPv6 headers. They also provides standard Internet connectivity by enabling IPv6 addressing and stateless IPv6 address auto-configuration, Neighbour Discovery and most importantly Header Compression. The main difference between IEEE 802.15.4 and LoRaWAN is that LoRaWAN builds stars and star of stars networks not requiring a routing protocol nor multi-hop operation. At the same time LoRaWAN is subject to bandwidth, data rate, radio duty-cycle regulations and frame size constraints that impose strict limitation in the protocol overhead that is supported when compared to IEEE 802.15.4.
Figure 2: Protocol Stack for IPv6 over LoRaWAN
+----------------------------------------+ ------------------
| | Transport and
| Upper Layer Protocols | Application Layer
+----------------------------------------+ ------------------
| | |
| IPv6 | |
| | Network
+----------------------------------------+ Layer
|Adaptation Layer for IPv6 over LoRaWAN | |
+----------------------------------------+ ------------------
| |
| IPv6-LOR Addressing Binding | LoRaWAN Link Layer
| | |
+----------------------------------------+ ------------------
| | |
| Activities | LoRaWAN
| Digital Protocol | Physical Layer
| RF Analog | |
| | |
+----------------------------------------+ ------------------
Adaptation layer for IPv6 over LoRaWAN SHALL support neighbour discovery,
address auto-configuration, header compression, and fragmentation and
reassembly.
According to RFC 4861 [RFC4861] a link is "a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6."
In LoRaWAN the IPv6 layer is designed to enable transmission of IPv6 packets over LoRaWAN links. The LoRaWAN protocol is in charge of establishing the pairwise communication between the LoRaWAN gateway and the LoRaWAN device. The IPv6 adaptation layer however is in charge of managing header compression and packet fragmentation in order to deal with different spreading factors and allowed packet payload at the underlying MAC layer.
Per this specification, the IPv6 header compression format specified in RFC 6282 MUST be used [RFC6282] but more drastic compression based on provisioning an extended context in the Neighbor Solicitation (NS) is expected in the upcoming revision. The IPv6 payload length can be derived from the LoRaWAN MAC header length and the possibly elided IPv6 address can be reconstructed from the link-layer address, used at the time of LoRaWAN connection establishment. As described in Section 4.5 context information or more aggressive compression formats such as RoHC [RFC3095] SHOULD be used at the 6LBR in order to compress well-known network prefixes and indicated at the specific field of the IPHC header. This compression will be defined in the upcomming revisions.
LoRaWAN networks form star topologies or star of stars, having a point-to-point nature. Address assignment is managed by the 6LBR that ensures that collisions do not occur. Broadcast features are used mainly by the 6LBR. 6LN to 6LN communications are always carried out through the 6LBR and hence it is in charge of relaying link local packets.
After the LoRaWAN node and the LoRaWAN gateway have established the LoRaWAN connection, the link is enabled and IPv6 address configuration and subsequent transmission are able to start.
Nodes (both hosts and routers) in a LoRaWAN network MAY use the address auto-configuration process. This process relies in the ability for a node to generate a link-local address for the communication interface. A link-local address is formed by appending an identifier of the interface to the well-known link-local prefix [RFC4291]. Before the link-local address can be assigned to an interface and used, a node must attempt to verify that this "tentative" address is not already in use by another node on the link. This section describes how LoRaWAN nodes determine the address to be used and how this address is bound to the 6LBR node (or Gateway).
The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device. The DevEUI is preconfigured at each node.
A LoRaWAN device addressing can be conducted in two ways. Over the air activation (OTAA) and Activation by personalization (ABP). The former requires 2 MAC layer messages to establish the network address and security keys (join-request and join-response). The latter assumes that device address and security keys are pre-programmed at the nodes and the DevEUI is not mandatory. Lately, the LoRa Alliance is considering to mandate DevEUI in ABP mode.
Figure 3: DevEUI
+------------+----------------+ | Bit# | [63..0] | +------------+----------------+ | DevEUI | DevEUI | +------------+----------------+
A LoRaWAN end device performs stateless address auto-configuration as per [RFC4862]. A 64-bit Interface identifier (IID) for a LoRaWAN interface MAY be formed by utilizing the 64-bit LoRaWAN DevEUI. That IID MAY guarantee a stable IPv6 address and MUST be used along the lifetime of the network.
According to [RFC7136], interface IIDs of all unicast addresses for LoRaWAN-enabled devices MUST be formed on the basis of 64 bits long and constructed using the EUI-64 format. LoRaWAN End Device Addresses MUST follow a stateless address auto-configuration with the 64 bit DevEUI.
[RFC4291] indicates the use of a "Universal/Local" scope bit that identifies the network device to be locally accessible or globally accessible. The former SHOULD be followed and LoRaWAN end-devices SHOULD set to 0 the "Universal/Local" bit. In the case that a Universally accessible IPv6 address needs to be used a Neighbor Discovery mechanism and a network commissioning procedure is required. This procedure is described in Section 4.4.
LoRaWAN IPv6 Network Prefix is build using the link-local prefix FE80::/64. The IPv6 link-local address for a LoRaWAN-enabled device is formed by appending the IID, to the prefix, as depicted in Figure 4.
Duplicate address detection for link-local addresses is performed by the 6LBR.
Once a 6LN has established its own link-local address, it starts sending Router Solicitation messages as described in [RFC4861] Section 6.3.7.
For non-link-local addresses a 64-bit IID MAY be formed by utilizing the 64-bit LoRaWAN DevEUI as described in this section. A 6LN can also use a the EUI-64 generated IID from the MAC Layer. The non-link-local addresses generated by the 6LN MUST be registered with the 6LBR.
The mechanism by which the 6LBR obtains an IPv6 prefix is out of scope of this document but can for example be accomplished by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. As 6LNs MUST always communicate to the 6LBR, the "on-link" flag (L) MUST be set to zero in the Prefix Information Option [RFC4861]. This will always happen even when the destination is another 6LN using the same prefix.
Figure 4: IPv6 link-local address in LoRaWAN
0 0 0 0 1 0 1 6 9 2 0 0 4 6 7 +----------+-----------------+---------------+----------------+ |1111111010| zeros | DevEUI | +----------+-----------------+---------------+----------------+ | | | /-------------------------- 128 bits ----------------------/| | |
Neighbour Discovery is addressed following the classical ND approach as defined by [RFC4861] , [RFC4862] and [RFC6775]. As LoRaWAN networks can be organized in star topologies or star of stars topologies the LoRaWAN manager can take two differentiated roles. For single star topologies the LoRaWAN manager will act as a 6LBR and MUST keep track of the nodes addresses within the link, otherwise it acts as 6LR and forwards Node Solicitation and ARO requests to the 6LBR in the network.
Figure 5: ND Procedure for a single star topology
LoRaWAN node LoRaWAN 6LR/6LBR
| Router Solicitation (RS) |
|-------------------------------->|
| |
| Router Advertisement (RA) |
|<--------------------------------|
| |
| Neighbour Solicitation (NS) |
|-------------------------------->|
| |
| Neighbour Advertisement (NA) |
|<--------------------------------|
| |
When a LoRaWAN node joins a network, it sends an RS to the 6LR containing its IID as described in Section 4.3.2. The 6LBR router answers with a RA containing its IIDs and prefixes. Hosts receive Router Advertisement messages containing the Authoritative Border Router Option (ABRO), the IIDs of the 6LR or 6LBR and MAY optionally contain one or more 6LoWPAN Context Options (6COs). They also contain the existing Prefix Information Options (PIOs) as described in [RFC4861].
When a host has configured a non-link-local IPv6 address, it registers that address with one or more of its default routers using the Address Registration Option (ARO) in an NS message. The host chooses a lifetime of the registration and repeats the ARO periodically (before the lifetime runs out) to maintain the registration. The host needs to refresh its prefix and context information by sending a new unicast NS. As LoRaWAN might use very low data rates it is recommended to use large Lifetime configurations assuming that LoRaWAN devices are not mobile. According to [RFC6775] the maximum Router Lifetime is about 18 hours, whereas the maximum Registration Lifetime is about 45.5 days.
Future versions of this document should consider the ND approach described in [efficient-nd]
The ND Procedure for star of stars follows the multi-hop ND approach described by [RFC6775]. The multihop distribution relies on RS messages and RA messages sent between routers, and using the ABRO version number to control the propagation of the information (prefixes and context information) that is being sent in the RAs.
Figure 6: ND Procedure for star of stars in LoRaWAN.
LoRaWAN node LoRaWAN 6LR LoRaWAN 6LBR
| Router Solicitation (RS) | |
|------------------------------->| |
| | |
| Router Advertisement (RA) | |
|<-------------------------------| |
| | |
| Node Registration (NR) | |
|------------------------------->| |
| | Neighbour Solicitation (NS) |
| |--------------------------------->|
| | |
| | Neighbour Advertisement (NA) |
| |<---------------------------------|
| Node Confirmation (NC) | |
|<-------------------------------| |
| | |
TODO.
TODO.
TODO.
The transmission of IPv6 over LoRaWAN links has similar requirements and concerns for security as for IEEE 802.15.4. LoRaWAN Link Layer security considerations are covered by the LoRaWAN Specification [LoRaSpec].
There are no IANA considerations related to this document.
The authors would like to acknowledge the guidance and input provided by Pascal Thubert.
| [LoRaSpec] | LoRa Alliance, "LoRaWAN Specification Rev.3", April 2014. |
| [efficient-nd] | Thubert, P., Nordmark, E. and S. Chakrabarti, "An Update to 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-00 , May 2016. |