Internet DRAFT - draft-vilajosana-6lpwa-lora-hc
draft-vilajosana-6lpwa-lora-hc
6lpwa X. Vilajosana, Ed.
Internet-Draft Worldsensing
Intended status: Standards Track M. Dohler
Expires: December 5, 2016 King's College London
June 3, 2016
Transmission of IPv6 Packets over LoRa
draft-vilajosana-6lpwa-lora-hc-00
Abstract
This document describes how IPv6 is transmitted over LoRa using
6LowPAN techniques. LoRa is a wireless communication system for
long-range low-power low-data-rate applications. LoRa 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.
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 December 5, 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
Vilajosana & Dohler Expires December 5, 2016 [Page 1]
Internet-Draft 6lpwa-lora June 2016
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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Overview of LoRa Technology . . . . . . . . . . . . . . . . . 3
4. Specification of IPv6 over LoRa . . . . . . . . . . . . . . . 3
4.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4
4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Stateless Address Auto-configuration . . . . . . . . . . 5
4.3.1. LoRa Addressing . . . . . . . . . . . . . . . . . . . 5
4.3.2. Address Auto-Configuration . . . . . . . . . . . . . 6
4.4. Neighbour Discovery . . . . . . . . . . . . . . . . . . . 7
4.5. Header Compression in LoRa . . . . . . . . . . . . . . . 9
4.6. Fragmentation in LoRa . . . . . . . . . . . . . . . . . . 9
5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. External Informative References . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
LoRa is a wireless modulation for long-range low-power low-data-rate
applications developed by Semtech. LoRa 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 LoRa 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 communication
range and data rate. Spreading factors create virtual and orthogonal
non-interfering communication channels that enable simultaneous
transmissions. Depending on the used spreading factor, LoRa data
rates range from 0.3 kbps to 50 kbps. To maximize both battery life
of end-devices and overall network capacity, the LoRa network
infrastructure manages the data rate and RF output for each end-
Vilajosana & Dohler Expires December 5, 2016 [Page 2]
Internet-Draft 6lpwa-lora June 2016
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 LoRa Managers or Gateways. Due to the constrained
nature of LoRa devices, the compression techniques developed by
6LowPAN become mandatory. The present document specifies how IPv6
and the 6LowPAN architecture run on top of the LoRa MAC layer.
2. Requirements Language
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].
3. Overview of LoRa Technology
TODO briefly describe the technology. Phy layer and modulation. MAC
operation and frame formats.
Figure 1: LoRa Class A transmission and reception window.
|----------------------------| |--------| |--------|
| Tx | | Rx | | Rx |
|----------------------------| |--------| |--------|
|---------|
Rx delay 1
|------------------------|
Rx delay 2
4. Specification of IPv6 over LoRa
The LoRa 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 LoRa 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 adressing and stateless IPv6 address auto-
configuration, Neighbour Discovery and most importantly Header
Compression. The main difference between IEEE 802.15.4 and LoRa is
that LoRa builds stars and star of stars networks not requiring a
routing protocol nor multi-hop operation. At the same time LoRa is
subject to bandwidth, data rate, radio duty-cycle regulations and
Vilajosana & Dohler Expires December 5, 2016 [Page 3]
Internet-Draft 6lpwa-lora June 2016
frame size constraints that impose strict limitation in the protocol
overhead that is supported when compared to IEEE 802.15.4.
4.1. Protocol stack
Figure 2: Protocol Stack for IPv6 over LoRa
+----------------------------------------+ ------------------
| | Transport and
| Upper Layer Protocols | Application Layer
+----------------------------------------+ ------------------
| | |
| IPv6 | |
| | Network
+----------------------------------------+ Layer
| Adaptation Layer for IPv6 over LoRa | |
+----------------------------------------+ ------------------
| |
| IPv6-LOR Addressing Binding | LoRa Link Layer
| | |
+----------------------------------------+ ------------------
| | |
| Activities | LoRa
| Digital Protocol | Physical Layer
| RF Analog | |
| | |
+----------------------------------------+ ------------------
Adaptation layer for IPv6 over LoRa SHALL support neighbour discovery,
address auto-configuration, header compression, and fragmentation and
reassembly.
4.2. Link Model
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 LoRa the IPv6 layer is designed to enable transmission of IPv6
packets over LoRa links. The LoRa protocol is in charge of
establishing the pairwise communication between the LoRa gateway and
the LoRa 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.
Vilajosana & Dohler Expires December 5, 2016 [Page 4]
Internet-Draft 6lpwa-lora June 2016
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 NS is expected in the
upcoming revision. The IPv6 payload length can be derived from the
LoRa MAC header length and the possibly elided IPv6 address can be
reconstructed from the link-layer address, used at the time of LoRa
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.
LoRa 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 LoRa node and the LoRa gateway have established the LoRa
connection, the link is enabled and IPv6 address configuration and
subsequent transmission are able to start.
4.3. Stateless Address Auto-configuration
Nodes (both hosts and routers) in a LoRa 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 LoRa nodes determine the address to be used and how
this address is bound to the 6LBR node (or LoRa Manager or Gateway).
4.3.1. LoRa Addressing
LoRa 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. The latter assumes that device address and
security keys are pre-programmed at the nodes. In the case of OTAA
the joining negotiation establishes a unique 4 Bytes DevAddr. When
ABP is used the DevAddr is pre-configured at the node.
The LoRa device address uses 32 bits and identifies the end-device
within the current network. The most significant 7 bits are used as
Vilajosana & Dohler Expires December 5, 2016 [Page 5]
Internet-Draft 6lpwa-lora June 2016
network identifier (NetworkID) to separate addresses of territorially
overlapping networks or networks managed by different network
operators. The least significant 25 bits are referred to as the
network address (NetworkAddress) of the end-device and can be
arbitrarily assigned by the network manager.
Figure 3: End Device Address
+------------+----------------+----------------+
| Bit# | [31..25] | [24..0] |
+------------+----------------+----------------+
| DevAddr | NetworkID | End Device |
| | | NetworkAddress |
+------------+----------------+----------------+
4.3.2. Address Auto-Configuration
A LoRa end device performs stateless address auto-configuration as
per [RFC4862]. A 64-bit Interface identifier (IID) for a LoRa
interface MAY be formed by utilizing the 32-bit LoRa DevAddr. 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
LoRa-enabled devices MUST be formed on the basis of 64 bits long and
constructed using the EUI-64 format. LoRa End Device Addresses MUST
follow a stateless address auto-configuration that requires 32 zeros
and 32 bit DevAddr.
[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 LoRa 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.
LoRa IPv6 Network Prefix is build using the link-local prefix
FE80::/64. The IPv6 link-local address for a LoRa-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.
Vilajosana & Dohler Expires December 5, 2016 [Page 6]
Internet-Draft 6lpwa-lora June 2016
For non-link-local addresses a 64-bit IID MAY be formed by utilizing
the 32-bit LoRa DevAddr as described in Section TODO. 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 LoRa
0 0 0 0 1
0 1 6 9 2
0 0 4 6 7
+----------+-----------------+---------------+----------------+
|1111111010| zeros | zeros | DevAddr |
+----------+-----------------+---------------+----------------+
| |
| /-------------------------- 128 bits ----------------------/|
| |
4.4. Neighbour Discovery
Neighbour Discovery is addressed following the classical ND approach
as defined by [RFC4861] , [RFC4862] and [RFC6775]. As LoRa networks
can be organized in star topologies or star of stars topologies the
LoRa manager can take two differentiated roles. For single star
topologies the LoRa 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.
Vilajosana & Dohler Expires December 5, 2016 [Page 7]
Internet-Draft 6lpwa-lora June 2016
Figure 5: ND Procedure for a single star topology
LoRa node LoRa 6LR/6LBR
| Router Solicitation (RS) |
|-------------------------------->|
| |
| Router Advertisement (RA) |
|<--------------------------------|
| |
| Neighbour Solicitation (NS) |
|-------------------------------->|
| |
| Neighbour Advertisement (NA) |
|<--------------------------------|
| |
When a LoRa 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 RS 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 RS. As LoRa might use very low
data rates it is recommended to use large Lifetime configurations
assuming that LoRa 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.
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.
Vilajosana & Dohler Expires December 5, 2016 [Page 8]
Internet-Draft 6lpwa-lora June 2016
Figure 6: ND Procedure for star of stars in LoRa.
LoRa node LoRa 6LR LoRa 6LBR
| Router Solicitation (RS) | |
|------------------------------->| |
| | |
| Router Advertisement (RA) | |
|<-------------------------------| |
| | |
| Node Registration (NR) | |
|------------------------------->| |
| | Neighbour Solicitation (NS) |
| |-------------------------------->|
| | |
| | Neighbour Advertisement (NA) |
| |<--------------------------------|
| Node Confirmation (NC) | |
|<------------------------------| |
| | |
4.5. Header Compression in LoRa
TODO.
4.6. Fragmentation in LoRa
TODO.
5. Internet Connectivity Scenarios
TODO.
6. Security Considerations
The transmission of IPv6 over LoRa links has similar requirements and
concerns for security as for IEEE 802.15.4. LoRa Link Layer security
considerations are covered by the LoRa Specification [LoRaSpec].
7. IANA Considerations
There are no IANA considerations related to this document.
Vilajosana & Dohler Expires December 5, 2016 [Page 9]
Internet-Draft 6lpwa-lora June 2016
8. Acknowledgements
The authors would like to acknowledge the guidance and input provided
by Pascal Thubert.
9. References
9.1. Normative References
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[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>.
[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>.
[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>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
Vilajosana & Dohler Expires December 5, 2016 [Page 10]
Internet-Draft 6lpwa-lora June 2016
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
July 2001, <http://www.rfc-editor.org/info/rfc3095>.
[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>.
[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>.
9.2. External Informative References
[LoRaSpec]
LoRa Alliance, "LoRa Specification Rev.3", April 2014.
Authors' Addresses
Xavier Vilajosana (editor)
Worldsensing
483 Arago 4th floor
Barcelona, Catalonia 08013
Spain
Email: xvilajosana@worldsensing.com
Mischa Dohler
King's College London
London, London
UK
Email: mischa.dohler@kcl.ac.uk
Vilajosana & Dohler Expires December 5, 2016 [Page 11]
