idnits 2.17.00 (12 Aug 2021) /tmp/idnits55686/draft-ietf-lpwan-overview-00.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 (December 5, 2016) is 1993 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-zuniga-lpwan-sigfox-system-description-01 == Outdated reference: A later version (-03) exists of draft-garcia-radext-radius-lorawan-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan S. Farrell, Ed. 3 Internet-Draft Trinity College Dublin 4 Intended status: Informational December 5, 2016 5 Expires: June 8, 2017 7 LPWAN Overview 8 draft-ietf-lpwan-overview-00 10 Abstract 12 Low Power Wide Area Networks (LPWAN) are wireless technologies with 13 characteristics such as large coverage areas, low bandwidth, possibly 14 very small packet and application layer data sizes and long battery 15 life operation. This memo is an informational overview of the set of 16 LPWAN technologies being considered in the IETF and of the gaps that 17 exist between the needs of those technologies and the goal of running 18 IP in LPWANs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 8, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.1. Provenance and Documents . . . . . . . . . . . . . . 4 58 2.1.2. Characteristics . . . . . . . . . . . . . . . . . . . 4 59 2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 10 60 2.2.1. Provenance and Documents . . . . . . . . . . . . . . 10 61 2.2.2. Characteristics . . . . . . . . . . . . . . . . . . . 11 62 2.3. SIGFOX . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 2.3.1. Provenance and Documents . . . . . . . . . . . . . . 15 64 2.3.2. Characteristics . . . . . . . . . . . . . . . . . . . 15 65 2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 19 66 2.4.1. Provenance and Documents . . . . . . . . . . . . . . 19 67 2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 20 68 3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 22 69 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 23 70 4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 23 71 4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 24 72 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 24 73 4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 25 74 4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 25 75 4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 25 76 4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 27 79 4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 28 82 4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 28 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 85 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 87 9. Informative References . . . . . . . . . . . . . . . . . . . 32 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 90 1. Introduction 92 [[Ed: Editor comments/queries are in double square brackets like 93 this. Note that the eventual fate of this draft is a topic for the 94 WG to consider - it might end up as a useful RFC, or it might be best 95 maintained as a draft only until its utility has dissapated. FWIW, 96 the editor doesn't mind what outcome the WG choose.]] 97 This document provides background material and an overview of the 98 technologies being considered in the IETF's Low Power Wide-Area 99 Networking (LPWAN) working group. We also provide a gap analysis 100 between the needs of these technologies and currently available IETF 101 specifications. 103 Most technologies in this space aim for similar goals of supporting 104 large numbers of low-cost, low-throughput devices at very low-cost 105 and with very-low power consumption, so that even battery-powered 106 devices can be deployed for years. And as the name implies, coverage 107 of large areas is also a common goal. So, by and large, the 108 different technologies aim for deployment in very similar 109 circumstances. 111 Existing pilot deployments have shown huge potential and created much 112 industrial interest in these technolgies. As of today, [[Ed: with 113 the possible exception of Wi-SUN devices?]] essentially no LPWAN 114 devices have IP capabilities. Connecting LPWANs to the Internet 115 would provide significant benefits to these networks in terms of 116 interoperability, application deployment, and management, among 117 others. The goal of the LPWAN WG is to adapt IETF defined protocols, 118 addressing schemes and naming to this particular constrained 119 environment. 121 This document is largely the work of the people listed in Section 7. 122 Discussion of this document should take place on the lp-wan@ietf.org 123 list. 125 2. LPWAN Technologies 127 This section provides an overview of the set of LPWAN technologies 128 that are being considered in the LPWAN working group. The text for 129 each was mainly contributed by proponents of each technology. 131 Note that this text is not intended to be normative in any sesne, but 132 simply to help the reader in finding the relevant layer 2 133 specifications and in understanding how those integrate with IETF- 134 defined technologies. Similarly, there is no attempt here to set out 135 the pros and cons of the relevant technologies. [[Ed: I assume 136 that's the right target here. Please comment if you disagree.]] 138 [[Ed: the goal here is 2-3 pages per technology. If there's much 139 more needed then we could add appendices I guess depending on what 140 text the WG find useful to include.]] 142 [[Ed: A lot of the radio frequency related details below could 143 disappear I think - for the purposes of this WG, I think a lot of 144 that is extraneous detail. Haven't yet done that though, in case I'm 145 missing something. It might also further imbalance the level of 146 description of the different technologies, to the extent that the WG 147 care explicitly about that.]] 149 2.1. LoRaWAN 151 [[Ed: Text here is from [I-D.farrell-lpwan-lora-overview]]] 153 2.1.1. Provenance and Documents 155 LoRaWAN is a wireless technology for long-range low-power low-data- 156 rate applications developed by the LoRa Alliance, a membership 157 consortium. This draft is based on 158 version 1.0.2 [LoRaSpec] of the LoRa specification. (Version 1.0.2 159 is expected to be published in a few weeks. We will when that has 160 happened. For now, version 1.0 is available at [LoRaSpec1.0]) 162 2.1.2. Characteristics 164 In LoRaWAN networks, end-device transmissions may be received at 165 multiple gateways, so during nominal operation a network server may 166 see multiple instances of the same uplink message from an end-device. 168 The LoRaWAN network infrastructure manages the data rate and RF 169 output power for each end-device individually by means of an adaptive 170 data rate (ADR) scheme. End-devices may transmit on any channel 171 allowed by local regulation at any time, using any of the currently 172 available data rates. 174 LoRaWAN networks are typically organized in a star-of-stars topology 175 in which gateways relay messages between end-devices and a central 176 "network server" in the backend. Gateways are connected to the 177 network server via IP links while end-devices use single-hop LoRaWAN 178 communication that can be received at one or more gateways. All 179 communication is generally bi-directional, although uplink 180 communication from end-devices to the network server are favoured in 181 terms of overall bandwidth availability. 183 Figure 1 shows the entities involved in a LoRaWAN network. 185 +----------+ 186 |End-device| * * * 187 +----------+ * +---------+ 188 * | Gateway +---+ 189 +----------+ * +---------+ | +---------+ 190 |End-device| * * * +---+ Network +--- Application 191 +----------+ * | | Server | 192 * +---------+ | +---------+ 193 +----------+ * | Gateway +---+ 194 |End-device| * * * * +---------+ 195 +----------+ 196 Key: * LoRaWAN Radio 197 +---+ IP connectivity 199 Figure 1: LoRaWAN architecture 201 o End-device: a LoRa client device, sometimes called a mote. 202 Communicates with gateways. 204 o Gateway: a radio on the infrastructure-side, sometimes called a 205 concentrator or base-station. Communicates with end-devices and, 206 via IP, with a network server. 208 o Network Server: The Network Server (NS) terminates the LoRaWAN MAC 209 layer for the end-devices connected to the network. It is the 210 center of the star topology. 212 o Uplink message: refers to communications from end-device to 213 network server or appliction via one or more gateways. 215 o Downlink message: refers to communications from network server or 216 application via one gateway to a single end-device or a group of 217 end-devices (considering multicasting). 219 o Application: refers to application layer code both on the end- 220 device and running "behind" the network server. For LoRaWAN, 221 there will generally only be one application running on most end- 222 devices. Interfaces between the network server and application 223 are not further described here. 225 LoRaWAN radios make use of ISM bands, for example, 433MHz and 868MHz 226 within the European Union and 915MHz in the Americas. 228 The end-device changes channel in a pseudo-random fashion for every 229 transmission to help make the system more robust to interference and/ 230 or to conform to local regulations. 232 Figure 2 below shows that after a transmission slot a Class A device 233 turns on its receiver for two short receive windows that are offset 234 from the end of the transmission window. End-devices can only 235 transmit a subsequent uplink frame after the end of the associated 236 receive windows. When a device joins a LoRaWAN network, there are 237 similar timeouts on parts of that process. 239 |----------------------------| |--------| |--------| 240 | Tx | | Rx | | Rx | 241 |----------------------------| |--------| |--------| 242 |---------| 243 Rx delay 1 244 |------------------------| 245 Rx delay 2 247 Figure 2: LoRaWAN Class A transmission and reception window 249 Given the different regional requirements the detailed specification 250 for the LoRaWAN physical layer (taking up more than 30 pages of the 251 specification) is not reproduced here. Instead and mainly to 252 illustrate the kinds of issue encountered, in Table 1 we present some 253 of the default settings for one ISM band (without fully explaining 254 those here) and in Table 2 we describe maxima and minima for some 255 parameters of interest to those defining ways to use IETF protocols 256 over the LoRaWAN MAC layer. 258 +------------------------+------------------------------------------+ 259 | Parameters | Default Value | 260 +------------------------+------------------------------------------+ 261 | Rx delay 1 | 1 s | 262 | | | 263 | Rx delay 2 | 2 s (must be RECEIVE_DELAY1 + 1s) | 264 | | | 265 | join delay 1 | 5 s | 266 | | | 267 | join delay 2 | 6 s | 268 | | | 269 | 868MHz Default | 3 (868.1,868.2,868.3), data rate: 0.3-5 | 270 | channels | kbps | 271 +------------------------+------------------------------------------+ 273 Table 1: Default settings for EU868MHz band 275 +-----------------------------------------------+--------+----------+ 276 | Parameter/Notes | Min | Max | 277 +-----------------------------------------------+--------+----------+ 278 | Duty Cycle: some but not all ISM bands impose | 1% | no-limit | 279 | a limit in terms of how often an end-device | | | 280 | can transmit. In some cases LoRaWAN is more | | | 281 | stringent in an attempt to avoid congestion. | | | 282 | | | | 283 | EU 868MHz band data rate/frame-size | 250 | 50000 | 284 | | bits/s | bits/s : | 285 | | : 59 | 250 | 286 | | octets | octets | 287 | | | | 288 | US 915MHz band data rate/frame-size | 980 | 21900 | 289 | | bits/s | bits/s : | 290 | | : 19 | 250 | 291 | | octets | octets | 292 +-----------------------------------------------+--------+----------+ 294 Table 2: Minima and Maxima for various LoRaWAN Parameters 296 Note that in the case of the smallest frame size (19 octets), 8 297 octets are required for LoRa MAC layer headers leaving only 11 octets 298 for payload (including MAC layer options). However, those settings 299 do not apply for the join procedure - end-devices are required to use 300 a channel that can send the 23 byte Join-request message for the join 301 procedure. 303 Uplink and downlink higher layer data is carried in a MACPayload. 304 There is a concept of "ports" (an optional 8 bit value) to handle 305 different applications on an end-device. Port zero is reserved for 306 LoRaWAN specific messaging, such as the join procedure. 308 In addition to carrying higher layer PDUs there are Join-Request and 309 Join-Response (aka Join-Accept) messages for handling network access. 310 And so-called "MAC commands" (see below) up to 15 bytes long can be 311 piggybacked in an options field ("FOpts"). 313 There are a number of MAC commands for: Link and device status 314 checking, ADR and duty-cycle negotiation, managing the RX windows and 315 radio channel settings. For example, the link check response message 316 allows the network server (in response to a request from an end- 317 device) to inform an end-device about the signal attenuation seen 318 most recently at a gateway, and to also tell the end-device how many 319 gateways received the corresponding link request MAC command. 321 Some MAC commands are initiated by the network server. For example, 322 one command allows the network server to ask an end-device to reduce 323 it's duty-cycle to only use a proportion of the maximum allowed in a 324 region. Another allows the network server to query the end-device's 325 power status with the response from the end-device specifying whether 326 it has an external power source or is battery powered (in which case 327 a relative battery level is also sent to the network server). 329 A LoRaWAN network has a short network identifier ("NwkID") which is a 330 seven bit value. A private network (common for LoRaWAN) can use the 331 value zero. If a network wishes to support "foreign" end-devices 332 then the NwkID needs to be registered with the LoRA Alliance, in 333 which case the NwkID is the seven least significant bits of a 334 registered 24-bit NetID. (Note however, that the methods for 335 "roaming" are currently being enhanced within the LoRA Alliance, so 336 the situation here is somewhat fluid.) 338 In order to operate nominally on a LoRaWAN network, a device needs a 339 32-bit device address, which is the catentation of the NwkID and a 340 25-bit device-specific network address that is assigned when the 341 device "joins" the network (see below for the join procedure) or that 342 is pre-provisioned into the device. 344 End-devices are assumed to work with one or a quite limited number of 345 applications, identified by a 64-bit AppEUI, which is assumed to be a 346 registered IEEE EUI64 value. In addition, a device needs to have two 347 symmetric session keys, one for protecting network artefacts 348 (port=0), the NwkSKey, and another for protecting appliction layer 349 traffic, the AppSKey. Both keys are used for 128 bit AES 350 cryptographic operations. So, one option is for an end-device to 351 have all of the above, plus channel information, somehow 352 (pre-)provisioned, in which case the end-device can simply start 353 transmitting. This is achievable in many cases via out-of-band means 354 given the nature of LoRaWAN networks. Table 3 summarises these 355 values. 357 +---------+---------------------------------------------------------+ 358 | Value | Description | 359 +---------+---------------------------------------------------------+ 360 | DevAddr | DevAddr (32-bits) = NwkId (7-bits) + device-specific | 361 | | network address (25 bits) | 362 | | | 363 | AppEUI | IEEE EUI64 naming the application | 364 | | | 365 | NwkSKey | 128 bit network session key for use with AES | 366 | | | 367 | AppSKey | 128 bit application session key for use with AES | 368 +---------+---------------------------------------------------------+ 370 Table 3: Values required for nominal operation 372 As an alternative, end-devices can use the LoRaWAN join procedure in 373 order to setup some of these values and dynamically gain access to 374 the network. To use the join procedure, an end-device must still 375 know the AppEUI, and in addition, a different (long-term) symmetric 376 key that is bound to the AppEUI - this is the application key 377 (AppKey), and is distinct from the application session key (AppSKey). 378 The AppKey is required to be specific to the device, that is, each 379 end-device should have a different AppKey value. And finally the 380 end-device also needs a long-term identifier for itself, 381 syntactically also an EUI-64, and known as the device EUI or DevEUI. 382 Table 4 summarises these values. 384 +---------+----------------------------------------------------+ 385 | Value | Description | 386 +---------+----------------------------------------------------+ 387 | DevEUI | IEEE EUI64 naming the device | 388 | | | 389 | AppEUI | IEEE EUI64 naming the application | 390 | | | 391 | AppKey | 128 bit long term application key for use with AES | 392 +---------+----------------------------------------------------+ 394 Table 4: Values required for join procedure 396 The join procedure involves a special exchange where the end-device 397 asserts the AppEUI and DevEUI (integrity protected with the long-term 398 AppKey, but not encrypted) in a Join-request uplink message. This is 399 then routed to the network server which interacts with an entity that 400 knows that AppKey to verify the Join-request. All going well, a 401 Join-accept downlink message is returned from the network server to 402 the end-device that specifies the 24-bit NetID, 32-bit DevAddr and 403 channel information and from which the AppSKey and NwkSKey can be 404 derived based on knowledge of the AppKey. This provides the end- 405 device with all the values listed in Table 3. 407 All payloads are encrypted and have data integrity. MAC commands, 408 when sent as a payload (port zero), are therefore protected. MAC 409 commands piggy-backed as frame options ("FOpts") are however sent in 410 clear. Any MAC commands sent as frame options and not only as 411 payload, are visible to a passive attacker but are not malleable for 412 an active attacker due to the use of the MIC. 414 For LoRaWAN version 1.0.x, the NWkSkey session key is used to provide 415 data integrity between the end-device and the network server. The 416 AppSKey is used to provide data confidentiality between the end- 417 device and network server, or to the application "behind" the network 418 server, depending on the implementation of the network. 420 All MAC layer messages have an outer 32-bit Message Integrity Code 421 (MIC) calculated using AES-CMAC calculated over the ciphertext 422 payload and other headers and using the NwkSkey. Payloads are 423 encrypted using AES-128, with a counter-mode derived from IEEE 424 802.15.4 using the AppSKey. Gateways are not expected to be provided 425 with the AppSKey or NwkSKey, all of the infrastructure-side 426 cryptography happens in (or "behind") the network server. When 427 session keys are derived from the AppKey as a result of the join 428 procedure the Join-accept message payload is specially handled. 430 The long-term AppKey is directly used to protect the Join-accept 431 message content, but the function used is not an aes-encrypt 432 operation, but rather an aes-decrypt operation. The justification is 433 that this means that the end-device only needs to implement the aes- 434 encrypt operation. (The counter mode variant used for payload 435 decryption means the end-device doesn't need an aes-decrypt 436 primitive.) 438 The Join-accept plaintext is always less than 16 bytes long, so 439 electronic code book (ECB) mode is used for protecting Join-accept 440 messages. The Join-accept contains an AppNonce (a 24 bit value) that 441 is recovered on the end-device along with the other Join-accept 442 content (e.g. DevAddr) using the aes-encrypt operation. Once the 443 Join-accept payload is available to the end-device the session keys 444 are derived from the AppKey, AppNonce and other values, again using 445 an ECB mode aes-encrypt operation, with the plaintext input being a 446 maximum of 16 octets. 448 2.2. Narrowband IoT (NB-IoT) 450 [[Ed: Text here is from [I-D.ratilainen-lpwan-nb-iot].]] 452 2.2.1. Provenance and Documents 454 Narrowband Internet of Things (NB-IoT) is developed and standardized 455 by 3GPP. The standardization of NB-IoT was finalized with 3GPP 456 Release-13 in June 2016, but further enhancements for NB-IoT are 457 worked on in the following releases, for example in the form of 458 multicast support. For more information of what has been specified 459 for NB-IoT, 3GPP specification 36.300 [TGPP36300] provides an 460 overview and overall description of the E-UTRAN radio interface 461 protocol architecture, while specifications 36.321 [TGPP36321], 462 36.322 [TGPP36322], 36.323 [TGPP36323] and 36.331 [TGPP36331] give 463 more detailed description of MAC, RLC, PDCP and RRC protocol layers 464 respectively. 466 2.2.2. Characteristics 468 [[Ed: Not clear what minimum/worst-case MTU might be. There are many 469 3GPP acronyms/terms to eliminate or explain.]] 471 Specific targets for NB-IoT include: Less than 5$ module cost, 472 extended coverage of 164 dB maximum coupling loss, battery life of 473 over 10 years, ~55000 devices per cell and uplink reporting latency 474 of less than 10 seconds. 476 NB-IoT supports Half Duplex FDD operation mode with 60 kbps peak rate 477 in uplink and 30 kbps peak rate in downlink, and a maximum size MTU 478 of 1600 bytes. As the name suggests, NB-IoT uses narrowbands with 479 the bandwidth of 180 kHz in both, downlink and uplink. The multiple 480 access scheme used in the downlink is OFDMA with 15 kHz sub-carrier 481 spacing. On uplink multi-tone SC-FDMA is used with 15 kHz tone 482 spacing or as a special case of SC-FDMA single tone with either 15kHz 483 or 3.75 kHz tone spacing may be used. 485 NB-IoT can be deployed in three ways. In-band deployment means that 486 the narrowband is multiplexed within normal LTE carrier. In Guard- 487 band deployment the narrowband uses the unused resource blocks 488 between two adjacent LTE carriers. Also standalone deployment is 489 supported, where the narrowband can be located alone in dedicated 490 spectrum, which makes it possible for example to refarm the GSM 491 carrier at 850/900 MHz for NB-IoT. All three deployment modes are 492 meant to be used in licensed bands. The maximum transmission power 493 is either 20 or 23 dBm for uplink transmissions, while for downlink 494 transmission the eNodeB may use higher transmission power, up to 46 495 dBm depending on the deployment. 497 For signaling optimization, two options are introduced in addition to 498 legacy RRC connection setup, mandatory Data-over-NAS (Control Plane 499 optimization, solution 2 in [TGPP23720]) and optional RRC Suspend/ 500 Resume (User Plane optimization, solution 18 in [TGPP23720]). In the 501 control plane optimization the data is sent over Non Access Stratum, 502 directly from Mobility Management Entity (MME) in core network to the 503 UE without interaction from base station. This means there are no 504 Access Stratum security or header compression, as the Access Stratum 505 is bypassed, and only limited RRC procedures. 507 The RRC Suspend/Resume procedures reduce the signaling overhead 508 required for UE state transition from Idle to Connected mode in order 509 to have a user plane transaction with the network and back to Idle 510 state by reducing the signaling messages required compared to legacy 511 operation 512 With extended DRX the RRC Connected mode DRX cycle is up to 10.24 513 seconds and in RRC Idle the DRX cycle can be up to 3 hours. 515 NB-IoT has no channel access restrictions allowing up to a 100% duty- 516 cycle. 518 3GPP access security is specified in [TGPP33203]. 520 +--+ 521 |UE| \ +------+ +------+ 522 +--+ \ | MME |------| HSS | 523 \ / +------+ +------+ 524 +--+ \+-----+ / | 525 |UE| ----| eNB |- | 526 +--+ /+-----+ \ | 527 / \ +--------+ 528 / \| | +------+ Service PDN 529 +--+ / | S-GW |----| P-GW |---- e.g. Internet 530 |UE| | | +------+ 531 +--+ +--------+ 533 Figure 3: 3GPP network architecture 535 Mobility Management Entity (MME) is responsible for handling the 536 mobility of the UE. MME tasks include tracking and paging UEs, 537 session management, choosing the Serving gateway for the UE during 538 initial attachment and authenticating the user. At MME, the Non 539 Access Stratum (NAS) signaling from the UE is terminated. 541 Serving Gateway (S-GW) routes and forwards the user data packets 542 through the access network and acts as a mobility anchor for UEs 543 during handover between base stations known as eNodeBs and also 544 during handovers between other 3GPP technologies. 546 Packet Data Node Gateway (P-GW) works as an interface between 3GPP 547 network and external networks. 549 Home Subscriber Server (HSS) contains user-related and subscription- 550 related information. It is a database, which performs mobility 551 management, session establishment support, user authentication and 552 access authorization. 554 E-UTRAN consists of components of a single type, eNodeB. eNodeB is a 555 base station, which controls the UEs in one or several cells. 557 The illustration of 3GPP radio protocol architecture can be seen from 558 Figure 4. 560 +---------+ +---------+ 561 | NAS |----|-----------------------------|----| NAS | 562 +---------+ | +---------+---------+ | +---------+ 563 | RRC |----|----| RRC | S1-AP |----|----| S1-AP | 564 +---------+ | +---------+---------+ | +---------+ 565 | PDCP |----|----| PDCP | SCTP |----|----| SCTP | 566 +---------+ | +---------+---------+ | +---------+ 567 | RLC |----|----| RLC | IP |----|----| IP | 568 +---------+ | +---------+---------+ | +---------+ 569 | MAC |----|----| MAC | L2 |----|----| L2 | 570 +---------+ | +---------+---------+ | +---------+ 571 | PHY |----|----| PHY | PHY |----|----| PHY | 572 +---------+ +---------+---------+ +---------+ 573 LTE-Uu S1-MME 574 UE eNodeB MME 576 Figure 4: 3GPP radio protocol architecture 578 The radio protocol architecture of NB-IoT (and LTE) is separated into 579 control plane and user plane. Control plane consists of protocols 580 which control the radio access bearers and the connection between the 581 UE and the network. The highest layer of control plane is called 582 Non-Access Stratum (NAS), which conveys the radio signaling between 583 the UE and the EPC, passing transparently through radio network. It 584 is responsible for authentication, security control, mobility 585 management and bearer management. 587 Access Stratum (AS) is the functional layer below NAS, and in control 588 plane it consists of Radio Resource Control protocol (RRC) 589 [TGPP36331], which handles connection establishment and release 590 functions, broadcast of system information, radio bearer 591 establishment, reconfiguration and release. RRC configures the user 592 and control planes according to the network status. There exists two 593 RRC states, RRC_Idle or RRC_Connected, and RRC entity controls the 594 switching between these states. In RRC_Idle, the network knows that 595 the UE is present in the network and the UE can be reached in case of 596 incoming call. In this state the UE monitors paging, performs cell 597 measurements and cell selection and acquires system information. 598 Also the UE can receive broadcast and multicast data, but it is not 599 expected to transmit or receive singlecast data. In RRC_Connected 600 the UE has a connection to the eNodeB, the network knows the UE 601 location on cell level and the UE may receive and transmit singlecast 602 data. RRC_Connected mode is established, when the UE is expected to 603 be active in the network, to transmit or receive data. Connection is 604 released, switching to RRC_Idle, when there is no traffic to save the 605 UE battery and radio resources. However, a new feature was 606 introduced for NB-IoT, as mentioned earlier, which allows data to be 607 transmitted from the MME directly to the UE, while the UE is in 608 RRC_Idle transparently to the eNodeB. 610 Packet Data Convergence Protocol's (PDCP) [TGPP36323] main services 611 in control plane are transfer of control plane data, ciphering and 612 integrity protection. 614 Radio Link Control protocol (RLC) [TGPP36322] performs transfer of 615 upper layer PDUs and optionally error correction with Automatic 616 Repeat reQuest (ARQ), concatenation, segmentation and reassembly of 617 RLC SDUs, in-sequence delivery of upper layer PDUs, duplicate 618 detection, RLC SDU discard, RLC-re-establishment and protocol error 619 detection and recovery. 621 Medium Access Control protocol (MAC) [TGPP36321] provides mapping 622 between logical channels and transport channels, multiplexing of MAC 623 SDUs, scheduling information reporting, error correction with HARQ, 624 priority handling and transport format selection. 626 Physical layer [TGPP36201] provides data transport services to higher 627 layers. These include error detection and indication to higher 628 layers, FEC encoding, HARQ soft-combining. Rate matching and mapping 629 of the transport channels onto physical channels, power weighting and 630 modulation of physical channels, frequency and time synchronization 631 and radio characteristics measurements. 633 User plane is responsible for transferring the user data through the 634 Access Stratum. It interfaces with IP and consists of PDCP, which in 635 user plane performs header compression using Robust Header 636 Compression (RoHC), transfer of user plane data between eNodeB and 637 UE, ciphering and integrity protection. Lower layers in user plane 638 are similarly RLC, MAC and physical layer performing tasks mentioned 639 above. 641 Under worst-case conditions, NB-IoT may achieve data rate of roughly 642 200 bps. For downlink with 164 dB coupling loss, NB-IoT may achieve 643 higher data rates, depending on the deployment mode. Stand-alone 644 operation may achieve the highest data rates, up to few kbps, while 645 in-band and guard-band operations may reach several hundreds of bps. 646 NB-IoT may even operate with higher maximum coupling loss than 170 dB 647 with very low bit rates. 649 2.3. SIGFOX 651 [[Ed: Text here is from 652 [I-D.zuniga-lpwan-sigfox-system-description].]] 654 2.3.1. Provenance and Documents 656 The SIGFOX LPWAN is in line with the terminology and specifications 657 being defined by the ETSI ERM TG28 Low Throughput Networks (LTN) 658 group [etsi_ltn]. As of today, SIGFOX's network has been fully 659 deployed in 6 countries, with ongoing deployments on 18 other 660 countries, in total a geography containing 397M people. 662 2.3.2. Characteristics 664 SIGFOX LPWAN autonomous battery-operated devices send only a few 665 bytes per day, week or month, in principle allowing them to remain on 666 a single battery for up to 10-15 years. The capacity of a SIGFOX 667 base station mainly depends on the number of messages generated by 668 the devices, and not on the number of devices. The battery life of 669 devices also depends on the number of messages generated by the 670 device, but it is important to keep in mind that these devices are 671 designed to last several years, some of them even buried underground. 672 The coverage of the cell also depends on the link budget and on the 673 type of deployment (urban, rural, etc.), which can vary from sending 674 less than one message per device per day to dozens of messages per 675 device per day. 677 The radio interface is compliant with the following regulations: 679 Spectrum allocation in the USA [fcc_ref] 681 Spectrum allocation in Europe [etsi_ref] 683 Spectrum allocation in Japan [arib_ref] 685 The SIGFOX LTN radio interface is also compliant with the local 686 regulations of the following countries: Australia, Brazil, Canada, 687 Kenya, Lebanon, Mauritius, Mexico, New Zealand, Oman, Peru, 688 Singapore, South Africa, South Korea, and Thailand. 690 The radio interface is based on Ultra Narrow Band (UNB) 691 communications, which allow an increased transmission range by 692 spending a limited amount of energy at the device. Moreover, UNB 693 allows a large number of devices to coexist in a given cell without 694 significantly increasing the spectrum interference. 696 Both uplink and downlink communications are possible with the UNB 697 solution. Due to spectrum optimizations, different uplink and 698 downlink frames and time synchronization methods are needed. 700 The main radio characteristics of the UNB uplink transmission are: 702 o Channelization mask: 100 Hz (600 Hz in the USA) 704 o Uplink baud rate: 100 baud (600 baud in the USA) 706 o Modulation scheme: DBPSK 708 o Uplink transmission power: compliant with local regulation 710 o Link budget: 155 dB (or better) 712 o Central frequency accuracy: not relevant, provided there is no 713 significant frequency drift within an uplink packet 715 In Europe, the UNB uplink frequency band is limited to 868,00 to 716 868,60 MHz, with a maximum output power of 25 mW and a maximum mean 717 transmission time of 1%. 719 The format of the uplink frame is the following: 721 +--------+--------+--------+------------------+-------------+-----+ 722 |Preamble| Frame | Dev ID | Payload |Msg Auth Code| FCS | 723 | | Sync | | | | | 724 +--------+--------+--------+------------------+-------------+-----+ 726 Figure 5: Uplink Frame Format 728 The uplink frame is composed of the following fields: 730 o Preamble: 19 bits 732 o Frame sync and header: 29 bits 734 o Device ID: 32 bits 736 o Payload: 0-96 bits 738 o Authentication: 16-40 bits 740 o Frame check sequence: 16 bits (CRC) 742 The main radio characteristics of the UNB downlink transmission are: 744 o Channelization mask: 1.5 kHz 746 o Downlink baud rate: 600 baud 748 o Modulation scheme: GFSK 749 o Downlink transmission power: 500 mW (4W in the USA) 751 o Link budget: 153 dB (or better) 753 o Central frequency accuracy: Centre frequency of downlink 754 transmission are set by the network according to the corresponding 755 uplink transmission. 757 In Europe, the UNB downlink frequency band is limited to 869,40 to 758 869,65 MHz, with a maximum output power of 500 mW with 10% duty 759 cycle. 761 The format of the downlink frame is the following: 763 +------------+-----+---------+------------------+-------------+-----+ 764 | Preamble |Frame| ECC | Payload |Msg Auth Code| FCS | 765 | |Sync | | | | | 766 +------------+-----+---------+------------------+-------------+-----+ 768 Figure 6: Downlink Frame Format 770 The downlink frame is composed of the following fields: 772 o Preamble: 91 bits 774 o Frame sync and header: 13 bits 776 o Error Correcting Code (ECC): 32 bits 778 o Payload: 0-64 bits 780 o Authentication: 16 bits 782 o Frame check sequence: 8 bits (CRC) 784 The radio interface is optimized for uplink transmissions, which are 785 asynchronous. Downlink communications are achieved by querying the 786 network for existing data from the device. 788 A device willing to receive downlink messages opens a fixed window 789 for reception after sending an uplink transmission. The delay and 790 duration of this window have fixed values. The LTN network transmits 791 the downlink message for a given device during the reception window. 792 The LTN network selects the BS for transmitting the corresponding 793 downlink message. 795 Uplink and downlink transmissions are unbalanced due to the 796 regulatory constraints on the ISM bands. Under the strictest 797 regulations, the system can allow a maximum of 140 uplink messages 798 and 4 downlink messages per device. These restrictions can be 799 slightly relaxed depending on system conditions and the specific 800 regulatory domain of operation. 802 +--+ 803 |EP| * +------+ 804 +--+ * | RA | 805 * +------+ 806 +--+ * | 807 |EP| * * * * | 808 +--+ * +----+ | 809 * | BS | \ +--------+ 810 +--+ * +----+ \ | | 811 DA -----|EP| * * * | SC |----- NA 812 +--+ * / | | 813 * +----+ / +--------+ 814 +--+ * | BS |/ 815 |EP| * * * * +----+ 816 +--+ * 817 * 818 +--+ * 819 |EP| * * 820 +--+ 822 Figure 7: ETSI LTN architecture 824 Figure 7 depicts the different elements of the SIGFOX architecture. 826 SIGFOX has a "one-contract one-network" model allowing devices to 827 connect in any country, without any notion of roaming. 829 The architecture consists of a single core network, which allows 830 global connectivity with minimal impact on the end device and radio 831 access network. The core network elements are the Service Center 832 (SC) and the Registration Authority (RA). The SC is in charge of the 833 data connectivity between the Base Station (BS) and the Internet, as 834 well as the control and management of the BSs and End Points. The RA 835 is in charge of the End Point network access authorization. 837 The radio access network is comprised of several BSs connected 838 directly to the SC. Each BS performs complex L1/L2 functions, 839 leaving some L2 and L3 functionalities to the SC. 841 The devices or End Points (EPs) are the objects that communicate 842 application data between local device applications (DAs) and network 843 applications (NAs). 845 EPs (or devices) can be static or nomadic, as they associate with the 846 SC and they do not attach to a specific BS. Hence, they can 847 communicate with the SC through one or many BSs. 849 Due to constraints in the complexity of the EP, it is assumed that 850 EPs host only one or very few device applications, which communicate 851 to one single network application at a time. 853 The radio protocol provides mechanisms to authenticate and ensure 854 integrity of the message. This is achieved by using a unique device 855 ID and a message authentication code, which allow ensuring that the 856 message has been generated and sent by the device with the ID claimed 857 in the message. 859 Security keys are independent for each device. These keys are 860 associated with the device ID and they are pre-provisioned. 861 Application data can be encrypted by the application provider. 863 2.4. Wi-SUN Alliance Field Area Network (FAN) 865 [[Ed: Text here is via personal communication from Bob Heile 866 (bheile@ieee.org) and was authored by Bob and Sum Chin Sean. Many 867 references to specifications are still needed here.]] 869 2.4.1. Provenance and Documents 871 The Wi-SUN Alliance is an industry alliance 872 for smart city, smart grid, smart utility, and a broad set of general 873 IoT applications. The Wi-SUN Alliance Field Area Network (FAN) 874 profile is open standards based (primarily on IETF and IEEE802 875 standards) and was developed to address applications like smart 876 municipality/city infrastructure monitoring and management, electric 877 vehicle (EV) infrastructure, advanced metering infrastructure (AMI), 878 distribution automation (DA), supervisory control and data 879 acquisition (SCADA) protection/management, distributed generation 880 monitoring and management, and many more IoT applications. 881 Additionally, the Alliance has created a certification program to 882 promote global multi-vendor interoperability. 884 The FAN profile [[Ed: reference needed!]] is an IPv6 frequency 885 hopping wireless mesh network with support for enterprise level 886 security. The frequency hopping wireless mesh topology aims to offer 887 superior network robustness, reliability due to high redundancy, good 888 scalability due to the flexible mesh configuration and good 889 resilience to interference. Very low power modes are in development 890 permitting long term battery operation of network nodes. [[Ed: 891 details welcome.]] 893 2.4.2. Characteristics 895 [[Ed: this really needs the references.]] The FAN profile is based on 896 various open standards in IETF, IEEE802 and ANSI/TIA for low power 897 and lossy networks. The FAN profile specification provides an 898 application-independent IPv6-based transport service for both 899 connectionless (i.e. UDP) and connection-oriented (i.e. TCP) 900 services. There are two possible methods for establishing the IPv6 901 packet routing: mandatory Routing Protocol for Low-Power and Lossy 902 Networks (RPL) at the Network layer or optional Multi-Hop Delivery 903 Service (MHDS) at the Data Link layer. Table 5 provides an overview 904 of the FAN network stack. 906 The Transport service is based on User Datagram Protocol (UDP) 907 defined in RFC768 or Transmission Control Protocol (TCP) defined in 908 RFC793. 910 The Network service is provided by IPv6 defined in RFC2460 with 911 6LoWPAN adaptation as defined in RC4944 and RFC6282. Additionally, 912 ICMPv6 as defined in RFC4443 is used for control plane in information 913 exchange. 915 The Data Link service provides both control/management of the 916 Physical layer and data transfer/management services to the Network 917 layer. These services are divided into Media Access Control (MAC) 918 and Logical Link Control (LLC) sub-layers. The LLC sub-layer 919 provides a protocol dispatch service which supports 6LoWPAN and an 920 optional MAC sub-layer mesh service. The MAC sub-layer is 921 constructed using data structures defined in IEEE802.15.4-2015. 922 Multiple modes of frequency hopping are defined. The entire MAC 923 payload is encapsulated in an IEEE802.15.9 Information Element to 924 enable LLC protocol dispatch between upper layer 6LoWPAN processing, 925 MAC sublayer mesh processing, etc. These areas will be expanded once 926 IEEE802.15.12 is completed 928 The PHY service is derived from a sub-set of the SUN FSK 929 specification in IEEE802.15.4-2015. The 2-FSK modulation schemes, 930 with channel spacing range from 200 to 600 kHz, are defined to 931 provide data rates from 50 to 300 kbps, with Forward Error Coding 932 (FEC) as an optional feature. Towards enabling ultra-low-power 933 applications, the PHY layer design is also extendable to low energy 934 and critical infrastructure monitoring networks, such as 935 IEEE802.15.4k. 937 +------------------------------+------------------------------------+ 938 | Layer | Description | 939 +------------------------------+------------------------------------+ 940 | IPv6 protocol suite | TCP/UDP | 941 | | | 942 | | 6LoWPAN Adaptation + Header | 943 | | Compression | 944 | | | 945 | | DHCPv6 for IP address management. | 946 | | | 947 | | Routing using RPL. | 948 | | | 949 | | ICMPv6. | 950 | | | 951 | | Unicast and Multicast forwarding. | 952 | | | 953 | MAC based on IEEE 802.15.4e | Frequency hopping | 954 | + IE extensions | | 955 | | | 956 | | Discovery and Join | 957 | | | 958 | | Protocol Dispatch (IEEE 802.15.9) | 959 | | | 960 | | Several Frame Exchange patterns | 961 | | | 962 | | Optional Mesh Under routing (ANSI | 963 | | 4957.210). | 964 | | | 965 | PHY based on 802.15.4g | Various data rates and regions | 966 | | | 967 | Security | 802.1X/EAP-TLS/PKI | 968 | | Authentication. | 969 | | | 970 | | 802.11i Group Key Management | 971 | | | 972 | | Optional ETSI-TS-102-887-2 Node 2 | 973 | | Node Key Management | 974 +------------------------------+------------------------------------+ 976 Table 5: Wi-SUN Stack Overivew 978 The FAN security supports Data Link layer network access control, 979 mutual authentication, and establishment of a secure pairwise link 980 between a FAN node and its Border Router, which is implemented with 981 an adaptation of IEEE802.1X and EAP-TLS as described in RFC5216 using 982 secure device identity as described in IEEE802.1AR. Certificate 983 formats are based upon RFC5280. A secure group link between a Border 984 Router and a set of FAN nodes is established using an adaptation of 985 the IEEE802.11 Four-Way Handshake. A set of 4 group keys are 986 maintained within the network, one of which is the current transmit 987 key. Secure node to node links are supported between one-hop FAN 988 neighbors using an adaptation of ETSI-TS-102-887-2. FAN nodes 989 implement Frame Security as specified in IEEE802.15.4-2015. 991 3. Generic Terminology 993 [[Ed: Text here is from [I-D.minaburo-lpwan-gap-analysis].]] 995 LPWAN technologies, such as those discussed above, have similar 996 architectures but different terminology. We can identify different 997 types of entities in a typical LPWAN network: 999 o The Host, which are the devices or the things (e.g. sensors, 1000 actuators, etc.), they are named differently in each technology 1001 (End Device, User Equipment or End Point). There can be a high 1002 density of hosts per radio gateway. 1004 o The Radio Gateway, which is the end point of the constrained link. 1005 It is known as: Gateway, Evolved Node B or Base station. 1007 o The Network Gateway or Router is the interconnection node between 1008 the Radio Gateway and the Internet. It is known as: Network 1009 Server, Serving GW or Service Center. 1011 o AAA Server, which controls the user authentication, the 1012 applications. It is known as: Join-Server, Home Subscriber Server 1013 or Registration Authority. [[Ed: I'm not clear that AAA server is 1014 the right generic term here.]] 1016 o At last we have the Application Server, known also as Packet Data 1017 Node Gateway or Network Application. 1019 +---------------------------------------------------------------------+ 1020 | Function/ | | | | | 1021 | Technology | LORAWAN | NB-IOT | SIGFOX | IETF | 1022 +--------------+-----------+------------+-------------+---------------+ 1023 | Sensor, | | | | | 1024 | Actuator, | End | User | End | Thing | 1025 |device, object| Device | Equipment | Point | (HOST) | 1026 +--------------+-----------+------------+-------------+---------------+ 1027 | Transceiver | | Evolved | Base | RADIO | 1028 | Antenna | Gateway | Node B | Station | GATEWAY | 1029 +--------------+-----------+------------+-------------+---------------+ 1030 | Server | Network | Serving- | Service |Network Gateway| 1031 | | Server | Gateway | Center | (ROUTER) | 1032 +--------------+-----------+------------+-------------+---------------+ 1033 | Security | Join | Home |Registration | | 1034 | Server | Server | Subscriber | Authority | AAA | 1035 | | | Server | | SERVER | 1036 +--------------+-----------+------------+-------------+---------------+ 1037 | Application |Application| Packet Data| Network | APPLICATION | 1038 | | Server |Node Gateway| Application | SERVER | 1039 +---------------------------------------------------------------------+ 1041 Figure 8: LPWAN Architecture Terminology 1043 () () () | +------+ 1044 () () () () / \ +---------+ | AAA | 1045 () () () () () () / \========| /\ |====|Server| +-----------+ 1046 () () () | | <--|--> | +------+ |Application| 1047 () () () () / \============| v |==============| Server | 1048 () () () / \ +---------+ +-----------+ 1049 HOSTS Radio Gateways Network Gateway 1051 Figure 9: LPWAN Architecture 1053 4. Gap Analysis 1055 [[Ed: Text here is from [I-D.minaburo-lpwan-gap-analysis].]] 1057 4.1. Naive application of IPv6 1059 IPv6 [RFC2460] has been designed to allocate addresses to all the 1060 nodes connected to the Internet. Nevertheless, the header overhead 1061 of at least 40 bytes introduced by the protocol is incompatible with 1062 LPWAN constraints. If IPv6 with no further optimization were used, 1063 several LPWAN frames would be needed just to carry the IP header. 1064 Another problem arises from IPv6 MTU requirements, which require the 1065 layer below to support at least 1280 byte packets [RFC2460]. 1067 IPv6 needs a configuration protocol (neighbor discovery protocol, NDP 1068 [RFC4861]) for a node to learn network parameters NDP generates 1069 regular traffic with a relatively large message size that does not 1070 fit LPWAN constraints. 1072 In some LPWAN technologies, layer two multicast is not supported. In 1073 that case, if the network topology is a star, the solution and 1074 considerations of section 3.2.5 of [RFC7668] may be applied. 1076 [[Ed: other things to maybe mention: IPsec, DHCPv6, anything with 1077 even 1 regular RTT needed, e.g. DNS.]] 1079 4.2. 6LoWPAN 1081 Several technologies that exhibit significant constraints in various 1082 dimensions have exploited the 6LoWPAN suite of specifications 1083 [RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use- 1084 cases]. However, the constraints of LPWANs, often more extreme than 1085 those typical of technologies that have (re)used 6LoWPAN, constitute 1086 a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. 1087 LPWANs are characterised by device constraints (in terms of 1088 processing capacity, memory, and energy availability), and specially, 1089 link constraints, such as: 1091 o very low layer two payload size (from ~10 to ~100 bytes), 1093 o very low bit rate (from ~10 bit/s to ~100 kbit/s), and 1095 o in some specific technologies, further message rate constraints 1096 (e.g. between ~0.1 message/minute and ~1 message/minute) due to 1097 regional regulations that limit the duty cycle. 1099 4.2.1. Header Compression 1101 6LoWPAN header compression reduces IPv6 (and UDP) header overhead by 1102 eliding header fields when they can be derived from the link layer, 1103 and by assuming that some of the header fields will frequently carry 1104 expected values. 6LoWPAN provides both stateless and stateful header 1105 compression. In the latter, all nodes of a 6LoWPAN are assumed to 1106 share compression context. In the best case, the IPv6 header for 1107 link-local communication can be reduced to only 2 bytes. For global 1108 communication, the IPv6 header may be compressed down to 3 bytes in 1109 the most extreme case. However, in more practical situations, the 1110 smallest IPv6 header size may be 11 bytes (one address prefix 1111 compressed) or 19 bytes (both source and destination prefixes 1112 compressed). These headers are large considering the link layer 1113 payload size of LPWAN technologies, and in some cases are even bigger 1114 than the LPWAN PDUs. 6LoWPAN has been initially designed for IEEE 1115 802.15.4 networks with a frame size up to 127 bytes and a throughput 1116 of up to 250 kb/s, which may or may not be duty-cycled. 1118 4.2.2. Address Autoconfiguration 1120 Traditionally, Interface Identifiers (IIDs) have been derived from 1121 link layer identifiers [RFC4944] . This allows optimisations such as 1122 header compression. Nevertheless, recent guidance has given advice 1123 on the fact that, due to privacy concerns, 6LoWPAN devices should not 1124 be configured to embed their link layer addresses in the IID by 1125 default. 1127 4.2.3. Fragmentation 1129 As stated above, IPv6 requires the layer below to support an MTU of 1130 1280 bytes [RFC2460]. Therefore, given the low maximum payload size 1131 of LPWAN technologies, fragmentation is needed. 1133 If a layer of an LPWAN technology supports fragmentation, proper 1134 analysis has to be carried out to decide whether the fragmentation 1135 functionality provided by the lower layer or fragmentation at the 1136 adaptation layer should be used. Otherwise, fragmentation 1137 functionality shall be used at the adaptation layer. 1139 6LoWPAN defined a fragmentation mechanism and a fragmentation header 1140 to support the transmission of IPv6 packets over IEEE 802.15.4 1141 networks [RFC4944]. While the 6LoWPAN fragmentation header is 1142 appropriate for IEEE 802.15.4-2003 (which has a frame payload size of 1143 81-102 bytes), it is not suitable for several LPWAN technologies, 1144 many of which have a maximum payload size that is one order of 1145 magnitude below that of IEEE 802.15.4-2003. The overhead of the 1146 6LoWPAN fragmentation header is high, considering the reduced payload 1147 size of LPWAN technologies and the limited energy availability of the 1148 devices using such technologies. Furthermore, its datagram offset 1149 field is expressed in increments of eight octets. In some LPWAN 1150 technologies, the 6LoWPAN fragmentation header plus eight octets from 1151 the original datagram exceeds the available space in the layer two 1152 payload. In addition, the MTU in the LPWAN networks could be 1153 variable which implies a variable fragmentation solution. 1155 4.2.4. Neighbor Discovery 1157 6LoWPAN Neighbor Discovery [RFC6775] defined optimizations to IPv6 1158 Neighbor Discovery [RFC4861], in order to adapt functionality of the 1159 latter for networks of devices using IEEE 802.15.4 or similar 1160 technologies. The optimizations comprise host-initiated interactions 1161 to allow for sleeping hosts, replacement of multicast-based address 1162 resolution for hosts by an address registration mechanism, multihop 1163 extensions for prefix distribution and duplicate address detection 1164 (note that these are not needed in a star topology network), and 1165 support for 6LoWPAN header compression. 1167 6LoWPAN Neighbor Discovery may be used in not so severely constrained 1168 LPWAN networks. The relative overhead incurred will depend on the 1169 LPWAN technology used (and on its configuration, if appropriate). In 1170 certain LPWAN setups (with a maximum payload size above ~60 bytes, 1171 and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange 1172 may be completed in a few seconds, without incurring packet 1173 fragmentation. 1175 In other LPWANs (with a maximum payload size of ~10 bytes, and a 1176 message rate of ~0.1 message/minute), the same exchange may take 1177 hours or even days, leading to severe fragmentation and consuming a 1178 significant amount of the available network resources. 6LoWPAN 1179 Neighbor Discovery behavior may be tuned through the use of 1180 appropriate values for the default Router Lifetime, the Valid 1181 Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as 1182 the address Registration Lifetime. However, for the latter LPWANs 1183 mentioned above, 6LoWPAN Neighbor Discovery is not suitable. 1185 4.3. 6lo 1187 The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6 1188 support over link layer technologies such as Bluetooth Low Energy 1189 (BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC or IEEE 802.11ah. 1190 These technologies are similar in several aspects to IEEE 802.15.4, 1191 which was the original 6LoWPAN target technology. [[Ed: refs?]] 1193 6lo has mostly used the subset of 6LoWPAN techniques best suited for 1194 each lower layer technology, and has provided additional 1195 optimizations for technologies where the star topology is used, such 1196 as BTLE or DECT-ULE. 1198 The main constraint in these networks comes from the nature of the 1199 devices (constrained devices), whereas in LPWANs it is the network 1200 itself that imposes the most stringent constraints. [[Ed: I'm not 1201 sure that conclusion follows from the information provided in this 1202 section - is more needed?.]] 1204 4.4. 6tisch 1206 The 6tisch solution is dedicated to mesh networks that operate using 1207 802.15.4e MAC with a deterministic slotted channel. The TSCH [[Ed: 1208 expand on 1st use]] can help to reduce collisions and to enable a 1209 better balance over the channels. It improves the battery life by 1210 avoiding the idle listening time for the return channel. 1212 A key element of 6tisch is the use of synchronization to enable 1213 determinism. TSCH and 6TiSCH may provide a standard scheduling 1214 function. The LPWAN networks probably will not support 1215 synchronization like the one used in 6tisch. 1217 4.5. RoHC 1219 RoHC [[Ed: expand on 1st use]] header compression mechanisms were 1220 defined for point to point multimedia channels, to reduce the header 1221 overhead of RTP flows. RoHC can also reduce the overhead of IPv4 or 1222 IPv6 or UDP headers. It is based on shared context which does not 1223 require any state but compressed packets are not routable. The 1224 context is initialised at the beginning of the communication or when 1225 it [[Ed: which "it"?]] is lost. The compression is managed using a 1226 sequence number (SN) which is encoded using a windowing algorithm 1227 allowing for reduction of the SN to 4 bits instead of 2 bytes. [[Ed: 1228 is that the 2 bytes as per 6lowPAN?]] But this window needs to be 1229 updated each 15 packets which implies larger headers. When RoHC is 1230 used we talk about an average header compression size to give the 1231 performance of compression. For example, RoHC starts sending bigger 1232 packets than the original (52 bytes) to reduce the header up to 4 1233 bytes (it stays here only for 15 packets, which correspond to the 1234 window size). Each time the context is lost or needs to be 1235 synchronised, packets of about 15 to 43 bytes are sent. [[Ed: the 1236 above isn't that cleaar to me.]] 1238 RoHC is not adapted to the constrained nodes of the LPWAN networks: 1239 it does not take into account the energy limitations and the 1240 transmission rate, and context is synchronised during the 1241 transmission, which does not allow a better compression. [[Ed: this 1242 seems to conflict a bit with what was said about 6tisch which puzzled 1243 me.]] 1245 4.6. ROLL 1247 Most technologies considered by the lpwan WG are based on a star 1248 topology, which eliminates the need for routing at that layer. 1249 Future work may address additional use-cases that may require 1250 adaptation of existing routing protocols or the definition of new 1251 ones. As of the time of writing, work similar to that done in the 1252 ROLL WG and other routing protocols are out of scope of the LPWAN WG. 1254 4.7. CoAP 1256 CoAP [RFC7252] provides a RESTful framework for applications intended 1257 to run on constrained IP networks. It may be necessary to adapt CoAP 1258 or related protocols to take into account for the extreme duty cycles 1259 and the potentially extremely limited throughput of LPWANs. 1261 For example, some of the timers in CoAP may need to be redefined. 1262 Taking into account CoAP acknowledgements may allow the reduction of 1263 L2 acknowledgements. On the other hand, the current work in progress 1264 in the CoRE WG where the COMI/CoOL network management interface 1265 which, uses Structured Identifiers (SID) to reduce payload size over 1266 CoAP proves to be a good solution for the LPWAN technologies. The 1267 overhead is reduced by adding a dictionary which matches a URI to a 1268 small identifier and a compact mapping of the YANG model into the 1269 CBOR binary representation. 1271 4.8. Mobility 1273 LPWANs nodes can be mobile. However, LPWAN mobility is different 1274 from the one specified for Mobile IP. LPWAN implies sporadic traffic 1275 and will rarely be used for high-frequency, real-time communications. 1276 The applications do not generate a flow, they need to save energy and 1277 most of the time the node will be down. The mobility will imply most 1278 of the time a group of devices, which represent a network itself. 1279 The mobility concerns more the gateway than the devices. 1281 NEMO [[Ed: refs?]] Mobility solutions may be used in the case where 1282 some hosts belonging to the same Network gateway will move from one 1283 point to another and that they are not aware of this mobility. 1285 4.9. DNS and LPWAN 1287 The purpose of the DNS is to enable applications to name things that 1288 have a global unique name. Lots of protocols are using DNS to 1289 identify the objects, especially REST and applications using CoAP. 1290 Therefore, hosts (things), or the named services they use, should be 1291 registered in DNS. DNS is probably a good topic of research for 1292 LPWAN technologies, while the matching of the name and the IP 1293 information can be used to configure the LPWAN devices. [[Ed: I'm 1294 not sure what that last bit means.]] 1296 5. Security Considerations 1298 [[Ed: be good to add stuff here about a) privacy and b) difficulties 1299 with getting current security protocols to work in this context. For 1300 a) maybe try find nice illustrations, e.g. extremecom instrumeted- 1301 igloo traces (temperature change allowing one to infer when someone 1302 took a pee:-). For b) things like IPsec/(D)TLS/OCSP and NTP to work 1303 in these environments. Not sure how much of that is known or useful 1304 for the WG. Probably worth noting the IAB statement on 1305 confidentiality and to ponder the impact of more than one layer of 1306 encryption in this context. Text below is basically from the "gaps" 1307 draft.]] 1308 Most LPWAN technologies integrate some authentication or encryption 1309 mechanisms that were defined outside the IETF. The working group may 1310 need to do work to integrate these mechanisms to unify management. A 1311 standardized Authentication, Accounting and Authorization (AAA) 1312 infrastructure [RFC2904] may offer a scalable solution for some of 1313 the security and management issues for LPWANs. AAA offers 1314 centralized management that may be of use in LPWANs, for example 1315 [I-D.garcia-dime-diameter-lorawan] and 1316 [I-D.garcia-radext-radius-lorawan] suggest possible security 1317 processes for a LoRaWAN network. Similar mechanisms may be useful to 1318 explore for other LPWAN technologies. 1320 6. IANA Considerations 1322 There are no IANA considerations related to this memo. 1324 7. Contributors 1326 As stated above this document is mainly a collection of content 1327 developed by the full set of contributors listed below. The main 1328 input documents and their authors were: 1330 o Text for Section 2.1 was provieded by Alper Yegin and Stephen 1331 Farrell in [I-D.farrell-lpwan-lora-overview]. 1333 o Text for Section 2.2 was provided by Antti Ratilainen in 1334 [I-D.ratilainen-lpwan-nb-iot]. 1336 o Text for Section 2.3 was provided by Juan Carlos Zuniga and Benoit 1337 Ponsard in [I-D.zuniga-lpwan-sigfox-system-description]. 1339 o Text for Section 2.4 was provided via personal communication from 1340 Bob Heile (bheile@ieee.org) and was authored by Bob and Sum Chin 1341 Sean. There is no Internet draft for that at present. 1343 o Text for Section 4 was provided by Ana Minabiru, Carles Gomez, 1344 Laurent Toutain, Josep Paradells and Jon Crowcroft in 1345 [I-D.minaburo-lpwan-gap-analysis]. Additional text from that 1346 draft is also used elsewhere above. 1348 The full list of contributors are: 1350 Jon Crowcroft 1351 University of Cambridge 1352 JJ Thomson Avenue 1353 Cambridge, CB3 0FD 1354 United Kingdom 1355 Email: jon.crowcroft@cl.cam.ac.uk 1357 Carles Gomez 1358 UPC/i2CAT 1359 C/Esteve Terradas, 7 1360 Castelldefels 08860 1361 Spain 1363 Email: carlesgo@entel.upc.edu 1365 Bob Heile 1366 Wi-Sun Alliance 1367 11 Robert Toner Blvd, Suite 5-301 1368 North Attleboro, MA 02763 1369 USA 1371 Phone: +1-781-929-4832 1372 Email: bheile@ieee.org 1374 Ana Minaburo 1375 Acklio 1376 2bis rue de la Chataigneraie 1377 35510 Cesson-Sevigne Cedex 1378 France 1380 Email: ana@ackl.io 1382 Josep PAradells 1383 UPC/i2CAT 1384 C/Jordi Girona, 1-3 1385 Barcelona 08034 1386 Spain 1388 Email: josep.paradells@entel.upc.edu 1390 Benoit Ponsard 1391 SIGFOX 1392 425 rue Jean Rostand 1393 Labege 31670 1394 France 1396 Email: Benoit.Ponsard@sigfox.com 1397 URI: http://www.sigfox.com/ 1398 Antti Ratilainen 1399 Ericsson 1400 Hirsalantie 11 1401 Jorvas 02420 1402 Finland 1404 Email: antti.ratilainen@ericsson.com 1406 Chin-Sean SUM 1407 Wi-Sun Alliance 1408 20, Science Park Rd 1409 Singapore 117674 1411 Phone: +65 6771 1011 1412 Email: sum@wi-sun.org 1414 Laurent Toutain 1415 Institut MINES TELECOM ; TELECOM Bretagne 1416 2 rue de la Chataigneraie 1417 CS 17607 1418 35576 Cesson-Sevigne Cedex 1419 France 1421 Email: Laurent.Toutain@telecom-bretagne.eu 1423 Alper Yegin 1424 Actility 1425 Paris, Paris 1426 FR 1428 Email: alper.yegin@actility.com 1430 Juan Carlos Zuniga 1431 SIGFOX 1432 425 rue Jean Rostand 1433 Labege 31670 1434 France 1436 Email: JuanCarlos.Zuniga@sigfox.com 1437 URI: http://www.sigfox.com/ 1439 8. Acknowledgements 1441 Thanks to all those listed in Section 7 for the excellent text. 1442 Errors in the handling of that are solely the editor's fault. 1444 In addition to the contributors above, thanks are due to Jiazi Yi, 1445 [your name here] for comments. 1447 Stephen Farrell's work on this memo was supported by the Science 1448 Foundation Ireland funded CONNECT centre . 1450 9. Informative References 1452 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1453 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1454 December 1998, . 1456 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1457 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1458 D. Spence, "AAA Authorization Framework", RFC 2904, 1459 DOI 10.17487/RFC2904, August 2000, 1460 . 1462 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1463 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1464 DOI 10.17487/RFC4861, September 2007, 1465 . 1467 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1468 "Transmission of IPv6 Packets over IEEE 802.15.4 1469 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1470 . 1472 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1473 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1474 DOI 10.17487/RFC6282, September 2011, 1475 . 1477 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1478 Bormann, "Neighbor Discovery Optimization for IPv6 over 1479 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1480 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1481 . 1483 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1484 Application Protocol (CoAP)", RFC 7252, 1485 DOI 10.17487/RFC7252, June 2014, 1486 . 1488 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1489 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1490 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1491 . 1493 [I-D.farrell-lpwan-lora-overview] 1494 Farrell, S. and A. Yegin, "LoRaWAN Overview", draft- 1495 farrell-lpwan-lora-overview-01 (work in progress), October 1496 2016. 1498 [I-D.minaburo-lpwan-gap-analysis] 1499 Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and 1500 J. Crowcroft, "LPWAN Survey and GAP Analysis", draft- 1501 minaburo-lpwan-gap-analysis-02 (work in progress), October 1502 2016. 1504 [I-D.zuniga-lpwan-sigfox-system-description] 1505 Zuniga, J. and B. PONSARD, "SIGFOX System Description", 1506 draft-zuniga-lpwan-sigfox-system-description-01 (work in 1507 progress), October 2016. 1509 [I-D.ratilainen-lpwan-nb-iot] 1510 Ratilainen, A., "NB-IoT characteristics", draft- 1511 ratilainen-lpwan-nb-iot-00 (work in progress), July 2016. 1513 [I-D.garcia-dime-diameter-lorawan] 1514 Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, 1515 "LoRaWAN Authentication in Diameter", draft-garcia-dime- 1516 diameter-lorawan-00 (work in progress), May 2016. 1518 [I-D.garcia-radext-radius-lorawan] 1519 Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, 1520 "LoRaWAN Authentication in RADIUS", draft-garcia-radext- 1521 radius-lorawan-02 (work in progress), October 2016. 1523 [TGPP36300] 1524 3GPP, "TS 36.300 v13.4.0 Evolved Universal Terrestrial 1525 Radio Access (E-UTRA) and Evolved Universal Terrestrial 1526 Radio Access Network (E-UTRAN); Overall description; Stage 1527 2", 2016, 1528 . 1530 [TGPP36321] 1531 3GPP, "TS 36.321 v13.2.0 Evolved Universal Terrestrial 1532 Radio Access (E-UTRA); Medium Access Control (MAC) 1533 protocol specification", 2016. 1535 [TGPP36322] 1536 3GPP, "TS 36.322 v13.2.0 Evolved Universal Terrestrial 1537 Radio Access (E-UTRA); Radio Link Control (RLC) protocol 1538 specification", 2016. 1540 [TGPP36323] 1541 3GPP, "TS 36.323 v13.2.0 Evolved Universal Terrestrial 1542 Radio Access (E-UTRA); Packet Data Convergence Protocol 1543 (PDCP) specification (Not yet available)", 2016. 1545 [TGPP36331] 1546 3GPP, "TS 36.331 v13.2.0 Evolved Universal Terrestrial 1547 Radio Access (E-UTRA); Radio Resource Control (RRC); 1548 Protocol specification", 2016. 1550 [TGPP36201] 1551 3GPP, "TS 36.201 v13.2.0 - Evolved Universal Terrestrial 1552 Radio Access (E-UTRA); LTE physical layer; General 1553 description", 2016. 1555 [TGPP23720] 1556 3GPP, "TR 23.720 v13.0.0 - Study on architecture 1557 enhancements for Cellular Internet of Things", 2016. 1559 [TGPP33203] 1560 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security 1561 for IP-based services", 2016. 1563 [etsi_ltn] 1564 "ETSI Technical Committee on EMC and Radio Spectrum 1565 Matters (ERM) TG28 Low Throughput Networks (LTN)", 1566 February 2015. 1568 [fcc_ref] "FCC CFR 47 Part 15.247 Telecommunication Radio Frequency 1569 Devices - Operation within the bands 902-928 MHz, 1570 2400-2483.5 MHz, and 5725-5850 MHz.", June 2016. 1572 [etsi_ref] 1573 "ETSI EN 300-220 (Parts 1 and 2): Electromagnetic 1574 compatibility and Radio spectrum Matters (ERM); Short 1575 Range Devices (SRD); Radio equipment to be used in the 25 1576 MHz to 1 000 MHz frequency range with power levels ranging 1577 up to 500 mW", May 2016. 1579 [arib_ref] 1580 "ARIB STD-T108 (Version 1.0): 920MHz-Band Telemeter, 1581 Telecontrol and data transmission radio equipment.", 1582 February 2012. 1584 [LoRaSpec] 1585 LoRa Alliance, "LoRaWAN Specification Version V1.0.2", Nov 1586 2016, . 1588 [LoRaSpec1.0] 1589 LoRa Alliance, "LoRaWAN Specification Version V1.0", Jan 1590 2015, . 1593 Author's Address 1595 Stephen Farrell (editor) 1596 Trinity College Dublin 1597 Dublin 2 1598 Ireland 1600 Phone: +353-1-896-2354 1601 Email: stephen.farrell@cs.tcd.ie