idnits 2.17.1
draft-farrell-lpwan-lora-overview-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 28, 2016) is 2699 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 lpwan S. Farrell
3 Internet-Draft Trinity College Dublin
4 Intended status: Informational A. Yegin
5 Expires: May 1, 2017 Actility
6 October 28, 2016
8 LoRaWAN Overview
9 draft-farrell-lpwan-lora-overview-01
11 Abstract
13 Low Power Wide Area Networks (LPWAN) are wireless technologies
14 covering different Internet of Things (IoT) applications. The common
15 characteristics for LPWANs are large coverage, low bandwidth, small
16 packet and application layer data sizes and long battery life
17 operation. One of these technologies is LoRaWAN developed by the
18 LoRa Alliance. LoRaWAN targets key requirements of the Internet of
19 things such as secure bi-directional communication, mobility and
20 localization services. This memo is an informational overview of
21 LoRaWAN and gives the principal characteristics of this technology in
22 order to help with the IETF work for providing IPv6 connectivity over
23 LoRaWAN along with other LPWANs.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on May 1, 2017.
42 Copyright Notice
44 Copyright (c) 2016 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. Radio Spectrum . . . . . . . . . . . . . . . . . . . . . . . 4
62 4. MAC Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 5. Names and Addressing . . . . . . . . . . . . . . . . . . . . 8
64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
65 6.1. Payload Encryption and Data Integrity . . . . . . . . . . 10
66 6.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . 10
67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
70 10. Informative References . . . . . . . . . . . . . . . . . . . 12
71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
73 1. Introduction
75 LoRaWAN is a wireless technology for long-range low-power low-data-
76 rate applications developed by the LoRa Alliance, a membership
77 consortium. LoRaWAN networks are
78 typically organized in a star-of-stars topology in which gateways
79 relay messages between end-devices and a central "network server" in
80 the backend. Gateways are connected to the network server via IP
81 links while end-devices use single-hop LoRaWAN communication that can
82 be received at one or more gateways. All communication is generally
83 bi-directional, although uplink communication from end-devices to the
84 network server are favoured in terms of overall bandwidth
85 availability.
87 In LoRaWAN networks, end-device transmissions may be received at
88 multiple gateways, so during nominal operation a network server may
89 see multiple instances of the same uplink message from an end-device.
91 To maximize both battery life of end-devices and overall network
92 capacity, the LoRaWAN network infrastructure manages the data rate
93 and RF output power for each end-device individually by means of an
94 adaptive data rate (ADR) scheme. End-devices may transmit on any
95 channel allowed by local regulation at any time, using any of the
96 currently available data rates.
98 This memo provides an overview of the LoRaWAN technology for the
99 Internet community, but the definitive specification [LoRaSpec] is
100 that produced by the LoRa Alliance. This draft is based on version
101 1.0.2 of the LoRa specification. (Note that version 1.0.2 is
102 expected to be published in a few weeks. We will update this draft
103 when that has happened. For now, version 1.0 is available at
104 [LoRaSpec1.0])
106 2. Terminology
108 This section introduces some LoRaWAN terms. Figure 1 shows the
109 entities involved in a LoRaWAN network.
111 +----------+
112 |End-device| * * *
113 +----------+ * +---------+
114 * | Gateway +---+
115 +----------+ * +---------+ | +---------+
116 |End-device| * * * +---+ Network +--- Application
117 +----------+ * | | Server |
118 * +---------+ | +---------+
119 +----------+ * | Gateway +---+
120 |End-device| * * * * +---------+
121 +----------+
122 Key: * LoRaWAN radio
123 +---+ IP connectivity
125 Figure 1: LoRaWAN architecture
127 o End-device: a LoRa client device, sometimes called a mote.
128 Communicates with gateways.
130 o Gateway: a radio on the infrastructure-side, sometimes called a
131 concentrator or base-station. Communicates with end-devices and,
132 via IP, with a network server.
134 o Network Server: The Network Server (NS) terminates the LoRaWAN MAC
135 layer for the end-devices connected to the network. It is the
136 center of the star topology.
138 o Uplink message: refers to communications from end-device to
139 network server or appliction via one or more gateways.
141 o Downlink message: refers to communications from network server or
142 application via one gateway to a single end-device or a group of
143 end-devices (considering multicasting).
145 o Application: refers to application layer code both on the end-
146 device and running "behind" the network server. For LoRaWAN,
147 there will generally only be one application running on most end-
148 devices. Interfaces between the network server and application
149 are not further described here.
151 o Classes A, B and C define different device capabilities and modes
152 of operation for end-devices. End-devices can transmit uplink
153 messages at any time in any mode of operation (so long as e.g.,
154 ISM band restrictions are honoured). An end-device in Class A can
155 only receive downlink messages at predetermined timeslots after
156 each uplink message transmission. Class B allows the end-device
157 to receive downlink messages at periodically scheduled timeslots.
158 Class C allows receipt of downlink messages at anytime. Class
159 selection is based on the end-devices' application use case and
160 its power supply. (While Classes B and C are not further
161 described here, readers may have seen those terms elsewhere so we
162 include them for clarity.)
164 3. Radio Spectrum
166 LoRaWAN radios make use of ISM bands, for example, 433MHz and 868MHz
167 within the European Union and 915MHz in the Americas.
169 The end-device changes channel in a pseudo-random fashion for every
170 transmission to help make the system more robust to interference and/
171 or to conform to local regulations.
173 As with other LPWAN radio technologies, LoRaWAN end-devices respect
174 the frequency, power and maximum transmit duty cycle requirements for
175 the sub-band imposed by local regulators. In most cases, this means
176 an end-device is only transmitting for 1% of the time, as specified
177 by ISM band regulations. And in some cases the LoRaWAN specification
178 calls for end-devices to transmit less often than is called for by
179 the ISM band regulations in order to avoid congestion.
181 Figure 2 below shows that after a transmission slot a Class A device
182 turns on its receiver for two short receive windows that are offset
183 from the end of the transmission window. The frequencies and data
184 rate chosen for the first of these receive windows match those used
185 for the transmit window. The frequency and data-rate for the second
186 receive window are configurable. If a downlink message preamble is
187 detected during a receive window, then the end-device keeps the radio
188 on in order to receive the frame.
190 End-devices can only transmit a subsequent uplink frame after the end
191 of the associated receive windows. When a device joins a LoRaWAN
192 network (see Section 4 for details), there are similar timeouts on
193 parts of that process.
195 |----------------------------| |--------| |--------|
196 | Tx | | Rx | | Rx |
197 |----------------------------| |--------| |--------|
198 |---------|
199 Rx delay 1
200 |------------------------|
201 Rx delay 2
203 Figure 2: LoRaWAN Class A transmission and reception window
205 Given the different regional requirements the detailed specification
206 for the LoRaWAN physical layer (taking up more than 30 pages of the
207 specification) is not reproduced here. Instead and mainly to
208 illustrate the kinds of issue encountered, in Table 1 we present some
209 of the default settings for one ISM band (without fully explaining
210 those here) and in Table 2 we describe maxima and minima for some
211 parameters of interest to those defining ways to use IETF protocols
212 over the LoRaWAN MAC layer.
214 +------------------------+------------------------------------------+
215 | Parameters | Default Value |
216 +------------------------+------------------------------------------+
217 | Rx delay 1 | 1 s |
218 | | |
219 | Rx delay 2 | 2 s (must be RECEIVE_DELAY1 + 1s) |
220 | | |
221 | join delay 1 | 5 s |
222 | | |
223 | join delay 2 | 6 s |
224 | | |
225 | 868MHz Default | 3 (868.1,868.2,868.3), date rate: 0.3-5 |
226 | channels | kbps |
227 +------------------------+------------------------------------------+
229 Table 1: Default settings for EU868MHz band
231 +-----------------------------------------------+--------+----------+
232 | Parameter/Notes | Min | Max |
233 +-----------------------------------------------+--------+----------+
234 | Duty Cycle: some but not all ISM bands impose | 1% | no-limit |
235 | a limit in terms of how often an end-device | | |
236 | can transmit. In some cases LoRaWAN is more | | |
237 | stringent in an attempt to avoid congestion. | | |
238 | | | |
239 | EU 868MHz band data rate/frame-size | 250 | 50000 |
240 | | bits/s | bits/s : |
241 | | : 59 | 250 |
242 | | octets | octets |
243 | | | |
244 | US 915MHz band data rate/frame-size | 980 | 21900 |
245 | | bits/s | bits/s : |
246 | | : 19 | 250 |
247 | | octets | octets |
248 +-----------------------------------------------+--------+----------+
250 Table 2: Minima and Maxima for various LoRaWAN Parameters
252 Note that in the case of the smallest frame size (19 octets), 8
253 octets are required for LoRa MAC layer headers leaving only 11 octets
254 for payload (including MAC layer options). However, those settings
255 do not apply for the join procedure - end-devices are required to use
256 a channel that can send the 23 byte Join-request message for the join
257 procedure.
259 4. MAC Layer
261 Uplink and downlink higher layer data is carried in a MACPayload.
262 There is a concept of "ports" (an optional 8 bit value) to handle
263 different applications on an end-device. Port zero is reserved for
264 LoRaWAN specific messaging, such as the join procedure.
266 The header also distinguishes the uplink/downlink directions and
267 whether or not an acknowledgement ("confirmation") is required from
268 the peer.
270 All payloads are encrypted and ciphertexts are protected with a
271 cryptographic Message Integrity Check (MIC) - see Section 6 for
272 details.
274 In addition to carrying higher layer PDUs there are Join-Request and
275 Join-Response (aka Join-Accept) messages for handling network access.
276 And so-called "MAC commands" (see below) up to 15 bytes long can be
277 piggybacked in an options field ("FOpts").
279 LoRaWAN end-devices can choose various different data rates from a
280 menu of available rates (dependent on the frequencies in use). It is
281 however, recommended that end-devices set the Adaptive Data Rate
282 ("ADR") bit in the MAC layer which is a signal that the network
283 should control the data rate (via MAC commands to the end-device).
284 The network can also assert the ADR bit and control data rates at
285 it's discretion. The goal is to ensure minimal on-time for radios
286 whilst increasing throughput and reliability when possible. Other
287 things being equal, the effect should be that end-devices closer to a
288 gateway can successfully use higher data rates, whereas end-devices
289 further from all gateways still receive connectivity though at a
290 lower data rate.
292 Data rate changes can be validated via a scheme of acks from the
293 network with a fall-back to lower rates in the event that downlink
294 acks go missing.
296 There are 16 (or 32) bit frame counters maintained in each direction
297 that are incremented on each transmission (but not re-transmissions)
298 that are not re-used for a given key. When the device supports a 32
299 bit counter, then only the least significant 16 bits are sent in the
300 MAC header, but all 32 bits are used in cryptographic operations.
301 (If an end-device only supports a 16 bit counter internally, then the
302 topmost 16 bits are set to zero.)
304 There are a number of MAC commands for: Link and device status
305 checking, ADR and duty-cycle negotiation, managing the RX windows and
306 radio channel settings. For example, the link check response message
307 allows the network server (in response to a request from an end-
308 device) to inform an end-device about the signal attenuation seen
309 most recently at a gateway, and to also tell the end-device how many
310 gateways received the corresponding link request MAC command.
312 Some MAC commands are initiated by the network server. For example,
313 one command allows the network server to ask an end-device to reduce
314 it's duty-cycle to only use a proportion of the maximum allowed in a
315 region. Another allows the network server to query the end-device's
316 power status with the response from the end-device specifying whether
317 it has an external power source or is battery powered (in which case
318 a relative battery level is also sent to the network server).
320 The network server can also inform an end-device about channel
321 assignments (mid-point frequencies and data rates). Of course, these
322 must also remain within the bands assigned by local regulation.
324 5. Names and Addressing
326 A LoRaWAN network has a short network identifier ("NwkID") which is a
327 seven bit value. A private network (common for LoRaWAN) can use the
328 value zero. If a network wishes to support "foreign" end-devices
329 then the NwkID needs to be registered with the LoRA Alliance, in
330 which case the NwkID is the seven least significant bits of a
331 registered 24-bit NetID. (Note however, that the methods for
332 "roaming" are currently being enhanced within the LoRA Alliance, so
333 the situation here is somewhat fluid.)
335 In order to operate nominally on a LoRaWAN network, a device needs a
336 32-bit device address, which is the catentation of the NwkID and a
337 25-bit device-specific network address that is assigned when the
338 device "joins" the network (see below for the join procedure) or that
339 is pre-provisioned into the device.
341 End-devices are assumed to work with one or a quite limited number of
342 applications, which matches most LoRaWAN use-cases. The applications
343 are identified by a 64-bit AppEUI, which is assumed to be a
344 registered IEEE EUI64 value.
346 In addition, a device needs to have two symmetric session keys, one
347 for protecting network artefacts (port=0), the NwkSKey, and another
348 for protecting appliction layer traffic, the AppSKey. Both keys are
349 used for 128 bit AES cryptpgraphic operations. (See Section 6 for
350 details.)
352 So, one option is for an end-device to have all of the above, plus
353 channel information, somehow (pre-)provisioned, in which case the
354 end-device can simply start transmitting. This is achievable in many
355 cases via out-of-band means given the nature of LoRaWAN networks.
356 Table 3 summarises these values.
358 +---------+---------------------------------------------------------+
359 | Value | Description |
360 +---------+---------------------------------------------------------+
361 | DevAddr | DevAddr (32-bits) = NwkId (7-bits) + device-specific |
362 | | network address (25 bits) |
363 | | |
364 | AppEUI | IEEE EUI64 naming the application |
365 | | |
366 | NwkSKey | 128 bit network session key for use with AES |
367 | | |
368 | AppSKey | 128 bit application session key for use with AES |
369 +---------+---------------------------------------------------------+
371 Table 3: Values required for nominal operation
373 As an alternative, end-devices can use the LoRaWAN join procedure in
374 order to setup some of these values and dynamically gain access to
375 the network.
377 To use the join procedure, an end-device must still know the AppEUI.
378 In addition to the AppEUI, end-devices using the join procedure need
379 to also know a different (long-term) symmetric key that is bound to
380 the AppEUI - this is the application key (AppKey), and is distinct
381 from the application session key (AppSKey). The AppKey is required
382 to be specific to the device, that is, each end-device should have a
383 different AppKey value. And finally the end-device also needs a
384 long-term identifier for itself, syntactically also an EUI-64, and
385 known as the device EUI or DevEUI. Table 4 summarises these values.
387 +---------+----------------------------------------------------+
388 | Value | Description |
389 +---------+----------------------------------------------------+
390 | DevEUI | IEEE EUI64 naming the device |
391 | | |
392 | AppEUI | IEEE EUI64 naming the application |
393 | | |
394 | AppKey | 128 bit long term application key for use with AES |
395 +---------+----------------------------------------------------+
397 Table 4: Values required for join procedure
399 The join procedure involves a special exchange where the end-device
400 asserts the AppEUI and DevEUI (integrity protected with the long-term
401 AppKey, but not encrypted) in a Join-request uplink message. This is
402 then routed to the network server which interacts with an entity that
403 knows that AppKey to verify the Join-request. All going well, a
404 Join-accept downlink message is returned from the network server to
405 the end-device that specifies the 24-bit NetID, 32-bit DevAddr and
406 channel information and from which the AppSKey and NwkSKey can be
407 derived based on knowledge of the AppKey. This provides the end-
408 device with all the values listed in Table 3.
410 There is some special handling related to which channels to use and
411 for multiple transmissions for the join-request which is intended to
412 ensure a successful join in as many cases as possible. Join-request
413 and Join-accept messages also include some random values (nonces) to
414 both provide some replay protection and to help ensure the session
415 keys are unique per run of the join procedure. If a Join-request
416 fails validation, then no Join-accept message (indeed no message at
417 all) is returned to the end-device. For example, if an end-device is
418 factory-reset then it should end up in a state in which it can re-do
419 the join procedure.
421 6. Security Considerations
423 In this section we describe the use of cryptography in LoRaWAN. This
424 section is not intended as a full specification but to be sufficient
425 so that future IETF specifications can encompass the required
426 security considerations. The emphasis is on describing the
427 externally visible characteristics of LoRaWAN.
429 6.1. Payload Encryption and Data Integrity
431 All payloads are encrypted and have data integrity. Frame options
432 (used for MAC commands) when sent as a payload (port zero) are
433 therefore protected. MAC commands piggy-backed as frame options
434 ("FOpts") are however sent in clear. Since MAC commands may be sent
435 as options and not only as payload, any values sent in that manner
436 are visible to a passive attacker but are not malleable for an active
437 attacker due to the use of the MIC.
439 For LoRaWAN version 1.0.x, the NWkSkey session key is used to provide
440 data integrity between the end-device and the network server. The
441 AppSKey is used to provide data confidentiality between the end-
442 device and network server, or to the application "behind" the network
443 server, depending on the implementation of the network.
445 All MAC layer messages have an outer 32-bit Message Integrity Code
446 (MIC) calculated using AES-CMAC calculated over the ciphertext
447 payload and other headers and using the NwkSkey.
449 Payloads are encrypted using AES-128, with a counter-mode derived
450 from IEEE 802.15.4 using the AppSKey.
452 Gateways are not expected to be provided with the AppSKey or NwkSKey,
453 all of the infrastructure-side cryptography happens in (or "behind")
454 the network server.
456 6.2. Key Derivation
458 When session keys are derived from the AppKey as a result of the join
459 procedure the Join-accept message payload is specially handled.
461 The long-term AppKey is directly used to protect the Join-accept
462 message content, but the function used is not an aes-encrypt
463 operation, but rather an aes-decrypt operation. The justification is
464 that this means that the end-device only needs to implement the aes-
465 encrypt operation. (The counter mode variant used for payload
466 decryption means the end-device doesn't need an aes-decrypt
467 primitive.)
468 The Join-accept plaintext is always less than 16 bytes long, so
469 electronic code book (ECB) mode is used for protecting Join-accept
470 messages.
472 The Join-accept contains an AppNonce (a 24 bit value) that is
473 recovered on the end-device along with the other Join-accept content
474 (e.g. DevAddr) using the aes-encrypt operation.
476 Once the Join-accept payload is available to the end-device the
477 session keys are derived from the AppKey, AppNonce and other values,
478 again using an ECB mode aes-encrypt operation, with the plaintext
479 input being a maximum of 16 octets.
481 7. IANA Considerations
483 There are no IANA considerations related to this memo.
485 8. Acknowledgements
487 The authors re-used some text from [I-D.vilajosana-lpwan-lora-hc]
489 Stephen Farrell's work on this memo was supported by the Science
490 Foundation Ireleand funded CONNECT centre
491 .
493 9. Contributors
495 The following members of the LoRa Alliance reviewed this draft and
496 contributed (much more than SF) to the definition of LoRaWAN.
498 Name, Affiliation, email (optional)
500 Chun-Yeow Yeoh, VADS LYFE SDN BHD, yeow@tmrnd.com.my
502 Olivier Hersent, Actility, olivier.hersent@actility.com
504 Dave Kjendal, Senet Inc, dkjendal@senetco.com
506 Paul Duffy, Cisco, paduffy@cisco.com
508 Joachim Ernst, Swisscom Broadcast Ltd, joachim.ernst@swisscom.com
510 Nicolas Sornin, Semtech, nsornin@semtech.com
512 Phillippe Christin, Orange, philippe.christin@orange.com
514 10. Informative References
516 [I-D.vilajosana-lpwan-lora-hc]
517 Vilajosana, X., Dohler, M., and A. Yegin, "Transmission of
518 IPv6 Packets over LoRaWAN", draft-vilajosana-lpwan-lora-
519 hc-00 (work in progress), July 2016.
521 [LoRaSpec]
522 LoRa Alliance, "LoRaWAN Specification Version V1.0.2", Nov
523 2016, .
525 [LoRaSpec1.0]
526 LoRa Alliance, "LoRaWAN Specification Version V1.0", Jan
527 2015, .
530 Authors' Addresses
532 Stephen Farrell
533 Trinity College Dublin
534 Dublin 2
535 Ireland
537 Phone: +353-1-896-2354
538 Email: stephen.farrell@cs.tcd.ie
540 Alper Yegin
541 Actility
542 Paris, Paris
543 FR
545 Email: alper.yegin@actility.com