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