idnits 2.17.1 draft-minaburo-6lpwa-cosol-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 (June 8, 2016) is 2872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'No-Responce' is mentioned on line 602, but not defined == Outdated reference: A later version (-07) exists of draft-marin-ace-wg-coap-eap-01 == Outdated reference: A later version (-02) exists of draft-veillette-core-cool-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Minaburo, Ed. 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain, Ed. 5 Expires: December 10, 2016 Institut MINES-TELECOM ; TELECOM Bretagne 6 Y. Delibie, Ed. 7 Kerlink 8 June 8, 2016 10 Constrained Signaling Over LPWA 11 draft-minaburo-6lpwa-cosol-00 13 Abstract 15 This document presents a new type of long-range, low-rate radio 16 technologies and an extensible mechanism to operate these networks 17 based on CoAP. The emerging Low-Power Wide-Area Networks (LPWA) 18 present a particular set of constraints, which places them at the 19 intersection of infrastructure networks, ultra-dense networks, delay- 20 tolerant networks and low-power and lossy networks. The main 21 objectives of LPWA signaling is to minimize the number of exchanged 22 messages, minimize the size of each message in a secure and 23 extensible manner, all with keeping the fundamental principle of 24 technology-independence (L2-independence). This document describes 25 the use of the Constrained Application Protocol (CoAP) as the main 26 signaling protocol for LPWA, over which minimal messages are 27 exchanged allowing the full operation of the network, such as 28 authentication, authorization, and management. The use of CoAP 29 signaling provides a generic mechanism that can be applied to 30 different LPWA technologies. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 10, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 2. LPWA Technologies . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Radio technologies . . . . . . . . . . . . . . . . . . . 5 70 2.2. Physical Layer Characteristics . . . . . . . . . . . . . 5 71 2.2.1. Ultra Narrowband LPWA radios . . . . . . . . . . . . 6 72 2.2.2. Spread-spectrum LPWA radios . . . . . . . . . . . . . 6 73 2.3. MAC Layer Characteristics . . . . . . . . . . . . . . . . 7 74 3. CoSOL Architecture . . . . . . . . . . . . . . . . . . . . . 7 75 3.1. General LPWA architecture . . . . . . . . . . . . . . . . 7 76 3.2. Node-F lifecycle . . . . . . . . . . . . . . . . . . . . 8 77 3.3. CoAP as Signaling Protocol for LPWAs . . . . . . . . . . 10 78 3.3.1. Semi-Association . . . . . . . . . . . . . . . . . . 10 79 3.3.2. Network Discovery . . . . . . . . . . . . . . . . . . 11 80 3.3.3. Association . . . . . . . . . . . . . . . . . . . . . 13 81 3.3.4. Authentication . . . . . . . . . . . . . . . . . . . 13 82 3.3.5. Operation . . . . . . . . . . . . . . . . . . . . . . 14 83 3.3.6. Dissociation . . . . . . . . . . . . . . . . . . . . 15 84 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 8.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 The goal of this document is to provide the necessary mechanisms to 96 operate a Low-Power Wide-Area Network (LPWA) by using IETF CoAP 97 [RFC7252] as a core signaling protocol. 99 Long-range, low-rate radio technologies have emerged in the past 100 several years, and are the base for building LPWAs. LPWAs generally 101 have the following characteristics: 103 o Work in narrow, license-free (ISM) bands with good propagation 104 properties (< 1GHz) 106 o Low- to very-low throughput (1-200 kbps) 108 o Low-power operation (25 mW in Europe) 110 o Long-range communication capabilities (up to 30 km with line-of- 111 sight, several km in urban environment) 113 o Strong channel access restrictions (1% to 10% duty cycling) 115 o Infrastructure-based 117 o Star topology 119 LPWAs are built on radio communication technologies, which use 120 advanced signal processing techniques and combination of appropriate 121 modulation and coding approaches to provide the aforementioned radio 122 characteristics. 124 The absence of license fees and the far-reaching connectivity allow 125 for an extremely competitive pricing of LPWAs compared to other 126 networking technologies, e.g. cellular or mesh. LPWAs are sometimes 127 referred to as LP-WAN or LR-WAN (Low-Rate WAN). Even though LPWAs 128 are extremely limited in terms of network performance, they are 129 enough for a wide class of applications, among which [LTN001]: 131 o Metering (water, gas, electricity) 133 o Infrastructure networks (water, gas, electricity, roads, 134 pipelines, drains) 136 o Environment/Smart City (waste management, air pollution monitoring 137 and alerting, acoustic noise monitoring, public lighting 138 management, parking management, self service bike rental, digital 139 board monitoring, water pipe leakage monitoring) 141 o Environment/Country side (soil quality, livestock surveillance, 142 cattle and pet monitoring, climate, irrigation) 144 o Remote monitoring (house, building) 146 o Industrial (water tank, asset tracking) 148 o Automotive (vehicle tracking, impact detection, pay as you drive, 149 assistance request, ...) 151 o Logistics (goods tracking, conservation monitoring) 153 o Healthcare (patient monitoring, home medical equipment usage) 155 o House appliances (pet tracking, white goods, personal asset) 157 o Truck (tyre monitoring) 159 o Identification (authentication) 161 The IEEE is studying LPWAs, but limited to the case of low-energy 162 critical infrastructure monitoring (LECIM), under the group IEEE 163 802.15.4k [IEEE.802-15.4k]. 165 The combination of the above characteristics and the envisioned 166 applications define a new class of networks with the following unique 167 constraints: 169 o Potentially extremely high density (expected of up to 10k-100k+ 170 end-devices managed by a single radio antena) 172 o Coexistence of delay-tolerant and critical applications (metering 173 and alarms) 175 o Low-power, low-throughput, lossy connectivity (use of ISM bands) 177 o Limited payload (100 bytes max, typically less than 50 bytes, 12 178 bytes for UNB) 180 CoAP is a client-server protocol specialized for constrained networks 181 and devices. CoAP is highly optimized, extensible, standard 182 protocol, which in conjunction with the Concise Binary Object 183 Representation (CBOR) is the ideal candidate for the signaling 184 protocol of the control plane of an LPWA. 186 It can be used during all stages of the lifecycle of the network, 187 e.g. discovery, authentication, operation. Furthermore, this can be 188 achieved by following RESTful management paradigm, by using a 189 particular resource tree definition or adopting COOL 190 [I-D.veillette-core-cool]. 192 1.1. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC 2119 [RFC2119]. 198 2. LPWA Technologies 200 2.1. Radio technologies 202 There are two classes of LPWA radio technologies, using different 203 radio modulation approaches: 205 o Ultra Narrow Band (UNB) 207 o Spread-spectrum (SS) 209 An example of UNB is the technology developed and promoted by SigFox 210 [SigFox]. Semtech LoRa [LoRa] uses a direct-sequence spread-spectrum 211 with orthogonal codes (OSSS). 213 Both approaches have their advantages and will coexist in the future, 214 as there are currently several operators, which deploy the two types 215 in the same areas. 217 2.2. Physical Layer Characteristics 219 At the physical layer, the important part is the possibility to 220 reconstruct the signal at long distances. The used ISM bands are 221 defined around the world (e.g. 868 MHz in Europe and 900 MHz in USA) 222 and require a 1% (or 10%) duty cycling, or alternatively - advanced 223 detection and channel reallocation techniques. In reality, all 224 deployed networks use the duty cycling limitation, with the following 225 distinction. There is one 100kHz band in which 10% duty cycling is 226 allowed, with a slightly more emission power. The rest of the bands 227 are limited at 1% duty cycling and very restricted power of emission 228 (e.g. 25 mW in Europe). 230 UNB LPWAs make the distinction between Uplink and Downlink, first 231 depending on the modulation, and second with the 10% duty-cycling 232 channel been used for the Downlink. OSSS LPWAs make no such 233 distinction, although for the operation of a network, an operator can 234 chose to use the same Uplink/Downlink channel separation. 236 Note that the 1% or 10% duty-cycle limitation counts for all trafic 237 originating from an electronic equipment, e.g. an antena managing 238 100k objects must obey the same limitation as an end-device, with all 239 frames emitted from the antena (data, acknowledgements) counting 240 towards its quota. 242 2.2.1. Ultra Narrowband LPWA radios 244 Ultra Narrowband (UNB) technologies generally possess the following 245 physical layer characteristics [LTN003]: 247 o Uplink: 249 * channelization mask 100kHz (600 kHz USA) 251 * baud rate 100 bauds (600 bauds USA) 253 * modulation BPSK 255 o Downlink: 257 * channelization mask: dynamic selection 259 * down link baud rate: 600 baud 261 * modulation scheme: GFSK 263 * downlink transmission power: 500 mW, 10% duty cycle 265 2.2.2. Spread-spectrum LPWA radios 267 OSSS technologies possess the following physical layer 268 characteristics [LTN003]: 270 o channelization mask: from 8 kHz to 500 kHz (depending on spreading 271 factor) 273 o chip rate: 8 kcps up to 500 kcps 275 o data rate: 30-50 000 bps 277 o modulation scheme: equivalent to DSSS with orthogonal signaling 279 No particular distinction is made between the Uplink and the 280 Downlink. 282 2.3. MAC Layer Characteristics 284 Several proprietary MAC frame formats exist for UNB and OSSS. 285 However, they are designed to operate the network in a centralized, 286 highly-vertically-integrated fashion. The only standard MAC frame 287 format is the IEEE 802.15.4k, which is based on the well-known IEEE 288 802.15.4 with the addition of a fragmentation sub-layer. 290 The channel access method is based on ALOHA, although it is up to the 291 network operator to chose if an appropriate end-node polling should 292 be implemented. 294 3. CoSOL Architecture 296 3.1. General LPWA architecture 298 We can identify three types of entities in a typical LPWA. These 299 are: 301 o Node-F: far-reachable node, e.g. the end-point, object, device. 303 o Node-R: radio relay, bridging the LPWA radio technology to a 304 different medium (often a LAN or cellular WAN). 306 o Node-G: gateway node, interconnection between the radio-relay node 307 and the Internet. 309 +--------+ +--------+ +--------+ 310 | Node-F | <-- LPWA radio --> | Node-R | <-- IP --> | Node-G | 311 +--------+ +--------+ +--------+ 313 General architecture of an LPWA. LPWA radio technology is used only 314 between the Node-F and the Node-R. 316 Figure 1 318 Of these, only Node-F and Node-R communicate through an LPWA radio 319 technology. However, due to the extreme constraints of these 320 technologies, they are always behind a gateway (Node-G). Note, that 321 the Node-R and Node-G can be collocated, e.g. on a single hardware 322 equipment. 324 The Node-G is connected to the Internet and is assumed to have 325 sufficient computational resources to store a context for each of the 326 Node-Fs. The strong limitation here is the radio link. 328 In an actual deployment, a (limited) set of Node-Rs cover a large 329 area with a potentially very-high number of Node-Fs. A single Node-G 330 is capable of controlling all Node-Rs. 332 o 333 o o 334 o (((*)))-------\ 335 o o | 336 o o | 337 o (((*)))---------------+------Node-G 338 o o | 339 o o | 340 o (((*)))-------------------+ 341 o | 342 o o o o | 343 o (((*)))-----------/ 344 o o 345 o o 347 o = Node-F 348 (((*))) = Node-R 350 An example coverage of an area with several Node-Rs. Note that a 351 single Node-F may be covered by several Node-Rs. 353 Figure 2 355 3.2. Node-F lifecycle 357 Similar to other wireless infrastructure-based technologies, a Node-F 358 can go through several stages: 360 o Semi-Association 362 o Network Discovery 364 o Association 366 o Authentication 368 o Dissociation 370 The Node-F state machine is then the following: 372 +------------------------------------------------------+ 373 | | 374 V | 375 Semi-associated | 376 | | 377 V | 378 Disconnected <-> Network discovery -> Associated -> Authenticated 379 ^ | | 380 | | | 381 +------------------------------------------------------+ 383 Node-F connectivity state machine. 385 Figure 3 387 The Node-F can be in Semi-Associated mode. Upon start, and depending 388 on the application, a Node-F can use a state of uni-directional 389 communication, where it is considered semi-associated to the network. 390 In that state, the Node-F broadcasts frames, handled by the Node-G, 391 but the network cannot join the Node-F on a regular basis. This is a 392 degraded LPWA operating mode and if caution is not used, can lead to 393 significant scalability and evolvability issues. 395 The Network Discovery can be reactive or proactive. The former is 396 based on detecting beacon frames sent periodically by the network 397 (e.g. Node-G). The latter is implemented by the Node-F broadcasting 398 probe request frames, to which all appropriate Node-Gs must respond. 400 Once a network has been discovered, the Node-F can associate to the 401 network. The association creates the necessary (minimal) context on 402 the Node-G, which initiates the authentication of the Node-F 404 The authentication is initiated by the Node-G, which should allow for 405 the necessary AAA exchanges to take place. If the authentication is 406 successful, the Node-F enters the Authenticated state. In this stage 407 there is bi-directional communication between the Node-F and the 408 Node-G. If the authentication is not successful, the Node-F enters 409 Disconnected state. Once in Authenticated state, the Node-F can 410 downgrade its connectivity to Semi-Associated mode. 412 The management of the node in Authenticated state is performed with 413 COOL [I-D.veillette-core-cool]. As an example, managing the 414 parameters of a Semtech LoRa device can be achieved through the use 415 of the YANG module defined in 417 Finally, the Node-F may decide to dissociate from the network by 418 sending an explicit request. Upon dissociation the Node-G may 419 release all contexts related to the Node-F and re-association 420 requires going through the authentication stage again. Node mobility 421 is achieved by explicitly dissociating from the old Node-G and then 422 authenticating to the new Node-G. Implicit dissociation is also 423 possible upon the expiration of predefined timers, or in case of 424 mobility optimization. 426 3.3. CoAP as Signaling Protocol for LPWAs 428 Use as CoAP for signaling is implemented as follows. The MAC, 429 network and/or transport layers MUST provide a mechanism to 430 differentiate user data from signaling data frames (e.g. by using 431 separate MAC addresses, IP addresses and/or UDP-ports). Both the 432 Node-G and the Node-F are running CoAP servers for implementing the 433 control plane. Frames exchanged over the LPWA radio interface and 434 marked as "signaling data" are handled by the corresponding control 435 plane CoAP servers. 437 The Node-G runs a (virtual) CoAP server for each Node-F. This server 438 is identified with a DNS name, e.g. "node123.home.node- 439 g.example.com", which can be used explicitly in the CoAP messages via 440 the Proxy-Uri option if needed. 442 Note, that the Node-R acts only as a transceiver and as such is 443 transparent from protocol point of view. As such, the following 444 management scheme applies: 446 +--------+ +--------+ 447 | Node-F | <-- LPWA constraints --> | Node-G | 448 +--------+ +--------+ 450 Node-F connectivity from protocol point of view. 452 Figure 4 454 3.3.1. Semi-Association 456 When in a semi-associated state, a Node-F broadcasts its messages 457 without performing network discovery, or association. If the Node-F 458 is under the coverage of a Node-G, the Node-G will receive the 459 broadcast, and forward the user data. The frames SHOULD be signed, 460 so that they could be authenticated by the network. Layer 2 461 acknowledgements MUST be used, and in some cases piggybacking on them 462 can provoke the Node-F to associate to the network. 464 The broadcast messages MUST include the necessary information to join 465 the user data destination, and enough information for the Node-G to 466 authenticate the message sender. This can be achieved through a 467 Confirmable CoAP message, where the user data are POSTed to a well- 468 known resource defined on the Node-G. DTLS with integrity check can 469 be used, with long-lived keys negotiated by the Node-F and the 470 network. Alternatively, COSE objects may provide the necessary 471 mechanisms. 473 Even though an application can be implemented by using only simplex 474 association capabilities, there are non-negligible negative 475 consequences related to scalability and evolvability in this case. 476 For example, a Node-F which periodically broadcasts information will 477 occupy the spectrum, even if there is no operator willing to accept 478 its trafic. In addition, no channel access management can be 479 applied. 481 Node-F Node-G 482 | | 483 | | 484 +--------->| Header: POST 485 | POST | Uri-Host: "destination.example.com" 486 | | Uri-Path: "temp" 487 | | 488 | | 489 |<---------+ Header: 2.01 Created 490 | 2.01 | 491 | | 492 | | 494 Sending a message in a semi-associated state. 496 Figure 5 498 3.3.2. Network Discovery 500 A network can be discovered by a Node-F reactively or proactively. 502 Reactive network discovery is based on the detection of periodic 503 beacons emitted by the Node-G. The beacons are implemented with CoAP 504 messages with the No-Response option 505 [I-D.tcs-coap-no-response-option]. The Node-G POSTs its information 506 to a well-known resource, e.g. "/network/node-G/" or a resource alias 507 "/g". Alternatively, this could be achieved by POST-ting to a COOL 508 container (e.g. POST /cool with data node ID = 1 for example). 510 Node-F Node-G 511 | | 512 | | 513 |<---------+ Header: POST 514 | POST /g | Uri-Path: "g" 515 | | [No-Responce] 516 | | 517 | | 519 Reactive network discovery. The Node-G sends periodically beacon 520 messages, containing information pertinent to this network. 522 Figure 6 524 The CoAP POST request is processed at the Node-F. A resource is 525 created locally, with the representation, which provides the 526 appropriate network parameters, e.g. network ID, Node-G ID, and other 527 radio-related parameters, such as channel, beacon frequency and so 528 forth. This information allows the Node-F to begin the 529 authentication phase. 531 A Node-F may chose to proactively probe for the existence of network 532 coverage. In that case, it sends a Confirmable CoAP GET request to 533 obtain the information from a well-known resource, normally published 534 by the beacon messages, e.g. "/network/node-G/" or a resource alias 535 "/g" or COOL data node ID ("/cool" data node ID = 2 for example). 537 Node-F Node-G 538 | | 539 | | 540 +--------->| Header: GET 541 | GET /g | Uri-Path: "g" 542 | | Accept: application/cbor 543 | | 544 | | 545 |<---------+ Header: 2.05 Content 546 | 2.05 | Payload: ... 547 | | 549 Proactive network discovery. The Node-F request the information of 550 all surrounding Node-Gs. 552 Figure 7 554 Once the network is discovered, the Node-F has all necessary 555 information to start the authentication phase. 557 3.3.3. Association 559 Before being able to communicate, the Node-F must associate to the 560 network, and then eventually authenticate. The association phase 561 signals to the Node-G that there is a new device willing to 562 communicate with the network. This association SHOULD provide enough 563 information to allow the Node-G to start the authentication process. 564 For example, it may provide the AAA server, which could authenticate 565 the Node-F, or its EAP-Identity. Note, that the Node-F may elect to 566 mark the association message with the No-response option 567 [I-D.tcs-coap-no-response-option], waiting for the subsequent 568 authentication request from the Node-G. 570 Node-F Node-G 571 | | 572 | | 573 +--------->| Header: POST 574 | POST /n | Uri-Path: "n" 575 | | Payload: ... 576 | | 577 |<---------+ Header: 2.01 Created 578 | 2.01 | Location-Path: "/n/n705" 579 | | 581 Node-F associates to a network, by creating a corresponding resource 582 element on the Node-G. 584 Figure 8 586 3.3.4. Authentication 588 The EAP-over-CoAP [I-D.marin-ace-wg-coap-eap] specifies an approach 589 to encapsulating EAP messages over CoAP. This allows to authenticate 590 a Node-F, which wishes to join an LPWA, and negotiate the L2 591 encryption keys, and DTLS keying material. 593 As the Node-F has already associated to the Node-G, it is the Node-G 594 that initiates the authentification request, by going directly to 595 Step 1) of the EAP-over-CoAP specification. 597 Node-F Node-G 598 | | 599 | | 600 1) |<-----------+ Header: POST 601 | POST /auth | Uri-Path: "auth" 602 | | [No-Responce] 603 | | 604 | | 605 2) +----------->| Header: 2.01 Created 606 | ACK /auth | Location-Path: "/auth/5" 607 | | 608 | | 609 | | 610 3) |<-----------+ Header: PUT 611 | PUT /auth/5| Uri-Path: "auth/5" 612 | | Payload: EAP-PSK MSG 1 613 | | 614 | | 615 4) +----------->| Header: 2.04 Changed 616 | ACK /auth/5| Payload: EAP-PSK MSG 2 617 | | 618 ...... 620 Node-F and Node-G perform mutual authentication following EAP-over- 621 CoAP. 623 Figure 9 625 Upon the end of the authentication phase, a Master Shared Key (MSK) 626 is known by the Node-F and the Node-G, and is used to generate DTLS 627 encryption or integrity keys. Further communications should be 628 encrypted/signed with the freshly derived keys. 630 3.3.5. Operation 632 Once the Node-F is authenticated to the network, it can send user 633 data via the Node-G to any other end-point on the Internet. 635 During the operation of the Node-F, the network may need to change 636 one or more parameters concerning the LPWA radio parameters of the 637 Node-F. These changes may even concern parameters related to the 638 Node-F itself (such as sleep cycles), its network parameters (e.g. 639 IP addresses), and so forth. This is achieved through the use of 640 COOL [I-D.veillette-core-cool]. The appropriate YANG modules must be 641 present on the Node-F (e.g. a Semtech LoRa Node-F should implement 642 the . 644 Node-F Node-G 645 | | 646 | | 647 |<-----------+ Header: PUT 648 | PUT /cool | Uri-Path: "cool" 649 | | Payload: {5:10,6:2} 650 | | 651 | | 652 +----------->| Header: 2.04 Changed 653 | 2.04 | 654 | | 656 Example, in which the Node-G changes the Spreading Factor (e.g. COOL 657 data node ID = 5) to 10, and the Channel (e.g. COOL data node ID = 658 6) to 2. Note, that the payload is encoded in CBOR. 660 Figure 10 662 3.3.6. Dissociation 664 If the Node-F wishes to deregister from the network, it could do so 665 by deleting the context created upon association: 667 Node-F Node-G 668 | | 669 | | 670 +--------------->| Header: POST 671 | DELETE /n/n705 | Uri-Path: "n/n705" 672 | | 673 | | 674 |<---------------+ Header: 2.02 Deleted 675 | 2.02 | 676 | | 678 Node-F dissociates from the network by deleting its associated 679 resources. 681 Figure 11 683 4. Acknowledgements 685 5. IANA Considerations 687 This memo includes no request to IANA. 689 6. Security Considerations 691 All drafts are required to have a security considerations section. 692 See RFC 3552 [RFC3552] for a guide. 694 7. Acknowledgements 696 We want to thanks Alexander Pelov for all his inputs and corrections 697 he has done to this work. 699 8. References 701 8.1. Normative References 703 [I-D.marin-ace-wg-coap-eap] 704 Garcia, D., "EAP-based Authentication Service for CoAP", 705 draft-marin-ace-wg-coap-eap-01 (work in progress), October 706 2014. 708 [I-D.tcs-coap-no-response-option] 709 Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 710 Bose, "CoAP option for no server-response", draft-tcs- 711 coap-no-response-option-17 (work in progress), May 2016. 713 [I-D.veillette-core-cool] 714 Veillette, M. and A. Pelov, "Constrained Objects 715 Language", draft-veillette-core-cool-00 (work in 716 progress), November 2015. 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, 720 DOI 10.17487/RFC2119, March 1997, 721 . 723 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 724 Application Protocol (CoAP)", RFC 7252, 725 DOI 10.17487/RFC7252, June 2014, 726 . 728 8.2. Informative References 730 [IEEE.802-15.4k] 731 Institute of Electrical and Electronics Engineers, "Low- 732 Rate Wireless Personal Area Networks (LR-WPANs) - 733 Amendment 5: Physical Layer Specifications for Low Energy, 734 Critical Infrastructure Monitoring Networks., IEEE 735 802.15.4k", IEEE Standard 802.15.4, 2013. 737 [LoRa] Semtech, "https://web.archive.org/web/20150510011904/ 738 https://www.semtech.com/wireless-rf/lora.html", May 2015. 740 [LTN001] European Telecommunications Standards Institute, "Low 741 Throughput Networks (LTN); Use Cases for Low Throughput 742 Networks, ETSI GS LTN 001", IEEE ETSI GS LTN 001, 2014. 744 [LTN003] European Telecommunications Standards Institute, "Low 745 Throughput Networks (LTN); Protocols and Interfaces, ETSI 746 GS LTN 003", IEEE ETSI GS LTN 003, 2014. 748 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 749 Text on Security Considerations", BCP 72, RFC 3552, 750 DOI 10.17487/RFC3552, July 2003, 751 . 753 [SigFox] SigFox, "https://web.archive.org/web/20150628225901/ 754 http://www.sigfox.com/en/#!/technology", June 2015. 756 Authors' Addresses 758 Ana Minaburo (editor) 759 Acklio 760 2bis rue de la Chataigneraie 761 Cesson-Sevigne, Bretagne 35510 762 FR 764 Email: ana@ackl.io 766 Laurent Toutain (editor) 767 Institut MINES-TELECOM ; TELECOM Bretagne 768 2 rue de la Chataigneraie 769 Cesson-Sevigne, Bretagne 35510 770 FR 772 Email: laurent.toutain@telecom-bretagne.eu 774 Yannick Delibie (editor) 775 Kerlink 776 1 rue Jacqueline Auriol 777 Thorigne-Fouillard, Bretagne 35235 778 FR 780 Email: yannick.delibie@kerlink.fr