idnits 2.17.1 draft-wang-6tisch-6top-coapie-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 513, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 519, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 525, but not defined == Unused Reference: 'I-D.ietf-6tisch-tsch' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 491, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-14 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-02 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-01 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-01 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-00 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: January 5, 2015 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 R. Sudhaakar 9 Cisco Systems 10 P. Zand 11 University of Twente 12 July 4, 2014 14 Transporting CoAP Messages over IEEE802.15.4e Information Elements 15 draft-wang-6tisch-6top-coapie-00 17 Abstract 19 This document describes the format of "CoAP IE", an IEEE802.15.4e 20 Information Element which allows CoAP messages to be transported as 21 part of the IEEE802.15.4e header. This enables 6top-to-6top 22 communication between neighbor nodes in a 6TiSCH network. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2 60 1.2. Context within 6TiSCH . . . . . . . . . . . . . . . . . . 2 61 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.4. Status of this Document . . . . . . . . . . . . . . . . . 3 63 2. CoAP IE Format . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Softcell Negotiation Interface RPC Definition . . . . . . . . 5 65 4. CoAP support . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. URI setting . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.2. CoAP Block option . . . . . . . . . . . . . . . . . . . . 7 68 4.3. Management Interface Protocol . . . . . . . . . . . . . . 8 69 4.4. Negotiation interface protocol . . . . . . . . . . . . . 8 70 4.5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 9 71 4.6. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Implementation Considerations . . . . . . . . . . . . . . . . 10 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 6.2. Informative References . . . . . . . . . . . . . . . . . 11 76 6.3. External Informative References . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 1.1. Requirements Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in RFC 86 2119 [RFC2119]. 88 1.2. Context within 6TiSCH 90 This document fits in the work done at the IETF 6TiSCH WG as follows: 92 o [I-D.wang-6tisch-6top-sublayer] defines the operation of the 6top 93 sublayer, which monitors and manages the communication schedule 94 used in the [IEEE802154e] TSCH network. 96 o [I-D.ietf-6tisch-6top-interface] defines the interface of the 6top 97 sublayer using the YANG data modeling language [RFC6020]. 99 o [I-D.ietf-6tisch-coap] translates this YANG model in CoAP 100 resources and interactions, allowing an Internet host (possibly 101 but not necessarily constrained) to monitor and manage the 6top 102 sublayer of a 6TiSCH device. 104 o This document defines a method for transporting those CoAP 105 messages as part of the IEEE802.15.4e header. It does so by 106 defining a new IEEE802.15.4e Information Element called "CoAP IE". 107 This allows a 6TiSCH node to monitor and manage the 6top sublayer 108 and enables pairwise communication for signaling and control 109 between neighbor nodes. 111 1.3. Motivation 113 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] allows for 114 both centralized and distributed monitoring and management of a 115 6TiSCH schedule. [I-D.ietf-6tisch-coap] defines the mechanisms 116 necessary for the centralized case. The present document defines a 117 mechanism enabling the communication of nodes in a 1 hop 118 neighborhood, enabling a distributed approach. 120 In particular, it allows a node to monitor and manage its neighbor 121 node's MIB. Through the CoAP IE defined in this document, a node 122 sends link-layer frames to its neighbor which contain, as part of the 123 link-layer header, the CoAP messages defined in 124 [I-D.ietf-6tisch-coap]. This allows a node to interact with the 6top 125 interface of its neighbor, in a way equivalent to an Internet host 126 interacting with a 6TiSCH device over CoAP. 128 In addition, this document describe the frame formats and interaction 129 between a node and its neighbor during softcell negotiation 130 [I-D.wang-6tisch-6top-sublayer], through the addition of an Remote 131 Procedure Call "RPC" element to the YANG model defined in 132 [I-D.ietf-6tisch-6top-interface]. 134 We call "6top-to-6top" communication the interaction between a node 135 and its neighbor using the CoAP IE. 137 1.4. Status of this Document 139 The authors decided to present the CoAP IE as a separate document to 140 request discussion and suggestions for improvement from the Internet 141 community. 143 If the document gets support, and after suggestions for improvement 144 have been integrated, the author propose to merge it in existing 145 6TiSCH I-Ds as follows: 147 o Section 3 would go into [I-D.ietf-6tisch-6top-interface]; 149 o Section 4 would go into [I-D.ietf-6tisch-coap]; 151 o Section 2 and Section 5 would go into 152 [I-D.wang-6tisch-6top-sublayer]. 154 2. CoAP IE Format 156 The CoAP IE is a container for transporting CoAP messages as part of 157 the IEEE802.15.4e header, as an Information Element. It is used by 158 both the management interface and the softcell negotiation interface 159 for 6top-to-6top communication. 161 This IE is not present in [IEEE802154e]; it is defined in this 162 document. 164 Format of a CoAP IE. 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Length | SubID |T| | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 170 // // 171 | Fragmented CoAP message | 172 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1 177 The fields in CoAP IE header are defined as follows. 179 o Length = 1 181 o SubID = 0x44 183 o T = 0 (short type) 185 The content of CoAP IE is a CoAP message compliant to [RFC7252]. The 186 CoAP message MAY use the CoAP Block option (see Section 4.2) in order 187 to fragment large CoAP messages. 189 Format of CoAP IE with CoAP message. 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | CoAP IE header |Ver| T | TKL | Code | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Message ID | Token (0-8B, assume 2B) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Uri-path option | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | 11111111 | | 200 +-+-+-+-+-+-+-+-+ | 201 // // 202 | CoAP message payload (variable) | 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2 208 The Token Length (TKL)is set to 2; 210 Per [RFC7252], the Uri-path field consists of the following sub- 211 fields: 213 o Option Delta: 4bits, set to 11 215 o Option Length: 4bits, set to 3 217 o Option value: 3 bytes 219 The first byte of the option value is set to "6" (for 6top), "4" (for 220 IEEE802.15.4), or "e" (for extension). The second and third bytes 221 refer to the resource name in the corresponding group. 223 3. Softcell Negotiation Interface RPC Definition 225 This document proposes to replace the "6top Communication Protocol" 226 defined in [I-D.wang-6tisch-6top-sublayer] by an extension to the 227 YANG data model defined in [I-D.ietf-6tisch-6top-interface]. This 228 allows neighbor nodes to negotiate the allocation of soft cells using 229 the CoAP IE. 231 rpc softcell-negotiation { 232 input { 233 leaf Opcode { 234 type enumeration { 235 enum RESERVATION; 236 enum REMOVE; 237 } 238 } 239 leaf RequiredBW { 240 type uint8; 241 } 242 leaf SlotframeID { 243 type uint8; 244 } 245 leaf TrackID { 246 type uint16; 247 description 248 "TrackID points to a tuple(TrackOwnerAddr, 249 InstanceID)"; 250 } 251 leaf NumofCandidate { 252 type uint8; 253 } 254 List CandidateList { 255 key "SlotOffset ChannelOffset"; 256 leaf SlotOffset{ 257 type uint16; 258 } 259 leaf ChannelOffset{ 260 type uint16; 261 } 262 } 263 } 264 output { 265 leaf NumOfCells { 266 type uint8; 267 } 268 List ResultedCells { 269 key "SlotOffset ChannelOffset"; 270 leaf SlotOffset{ 271 type uint16; 272 } 273 leaf ChannelOffset{ 274 type uint16; 275 } 276 } 277 } 278 } 280 4. CoAP support 282 4.1. URI setting 284 Uri-Host option = target node address; 286 Uri-Path option = 6t/6/[6top resource name], or 6t/4/[15.4 287 resource name], or 6t/e/[extension resource name], where [6top 288 resource name] refers to the data resources or RPC defined by 289 6top, [15.4 resource name] refers to the data resources defined 290 by IEEE802.15.4, and [extension resource name] refers to the 291 data resources defined by an extensions of 6top, e.g. OTF. 292 [6top resource name] , [154 resource name] and [extension 293 resource name] are RECOMMENDED to be at most 2 bytes long. 295 4.2. CoAP Block option 297 In [I-D.ietf-core-block], two block options (Block1 and Block2) are 298 defined to support block-wise transfers. The format of a fragmented 299 message in a CoAP IE is defined as follows. 301 Format of CoAP IE content with fragmented message. 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | CoAP IE header |Ver| T | TKL | Code | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Message ID | Token | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Uri-path option | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |option |option | option delta | NUM |M| SZX | 312 | delta |length | extended | | | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | 11111111 | | 315 +++++++++++++++++ | 316 // // 317 | fragmented payload (64B) | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 3 323 Per [I-D.ietf-core-block], the option Delta is 23 for Block1 and 27 324 for Block2. Related sub-fields are defined as follows. 326 o Option delta: 4bits, set to 13, indicates an 8-bit unsigned 327 integer follows the initial byte and the Option Delta minus 13. 329 o Option length: 4bits, set to 2. 331 o Option delta extended: 8bits, 23-13=10 and 27-13=14 for Block1 and 332 Block2, respectively. 334 Per [IEEE802154], assuming the IE size constraint is 81 bytes, the 335 related fields of the block option are defined as follows. 337 o The size of the block (SZX): 3 bits, representing block size 338 16B/32B/64B/128B/256B/512B/1024B. Considering the IE size 339 constrained by [IEEE802154], 16B/32B/64B block size will be used. 340 Invalid block size values will cause the packet to be dropped 341 quietly. 343 o Whether more blocks are following (M): 1 bit; 345 o The relative number of the block (NUM): 12 bits, within a sequence 346 of blocks with the given size. NUM is 4bits or 12bits, or 20bits 348 4.3. Management Interface Protocol 350 Management and MIB handling is handled by the protocol specification 351 defined in [I-D.ietf-6tisch-coap]. 353 4.4. Negotiation interface protocol 355 The negotiation protocol is used by neighbor nodes to agree at what 356 slotOffset/channelOffset to add/remove sotfcells. It uses a Uri-Path 357 option to identify the target resource (i.e the negotiation interface 358 of the neighbor). 360 The example below illustrates the use of this negotiation interface. 361 It assumes the RPC softcell-negotiation is at Uri-Path "6t/6/ng". 363 nodeA nodeB 364 | | 365 +------>| IEEE802.15.4e type: DATA 366 | POST | CoAP Header: POST (T=CON) 367 | | Uri-Path: "6t/6/ng" 368 | | Payload: CBOR( 369 | | Opcode=RESERVATION, 370 | | RequiredBW, 371 | | SlotframeID, 372 | | TrackID, 373 | | NumOfCandidate, 374 | | CandidateList 375 | | ) 376 | | 377 |<------+ IEEE802.15.4e type: ACK 378 | | 379 |<------+ IEEE802.15.4e type: DATA 380 | 2.04 | CoAP Header: 2.04 Changed (T=CON, Code=2.04) 381 | | Payload: CBOR( 382 | | NumOfCells, 383 | | ResultedCells 384 | | ) 385 | | 386 +-------> IEEE802.15.4e type: ACK 387 | | 389 Node A send a CoAP POST request, using a confirmable message. Node B 390 sends back a IEEE802.15.4e ACK to confirm reception. This layer 2 391 ACK does not give any indication about the correct handling of the 392 command, or even about whether this command is well formatted and 393 understood. Node B parses the CoAP IE, and if correct, calls the 394 appropriate 6top command to allocate softcells. When the allocation 395 is done, node B sends back a CoAP Response with the appropriate 396 return code to node A as a IEEE802.15.4e data packet. The CoAP ACK 397 MUST be piggybacked on the Response. 399 4.5. Acknowledgement 401 For both non-fragmented CoAP message and fragmented CoAP message, an 402 Acknowledgement message of CoAP is used. The Acknowledgement message 403 of CoAP is inserted into a CoAP IE, which is carried in the Data 404 Frame or Enhanced Acknowledgement frame of [IEEE802154e]. 406 4.6. Observe 408 The Observe mechanism is a option for 6top-to-6top communication. 409 The Token in the CoAP message is used to bind Observe message and its 410 Response messages. 412 5. Implementation Considerations 414 Similar to the formatting and the parser modules used by CoAP (Layer 415 5), a CoAP formatting and parser modules are present in the 6top 416 sublayer. 418 +-----------------------------------+ 419 | PCEP | CoAP | | 6LoWPAN | | 420 | PCC | DTLS | PANA | ND |RPL | 421 +------------------------------------------+ 422 | TCP | UDP | ICMP | RSVP | 423 +------------------------------------------+ 424 | IPv6 | 425 +------------------------------------------+ 426 | 6LoWPAN HC | 427 +------------------------------------------+ 428 | +--------------+ +----------------+ | 429 | | CoAP Parser | | CoAP Formatting| | 430 | +--------------+ +----------------+ | 431 | +--------------+ +----------------+ | 432 | | IE Parser | | IE Formatting | | 433 | +--------------+ +----------------+ | 434 +------------------------------------------+ 435 | IEEE802.15.4e TSCH | 436 +------------------------------------------+ 437 | IEEE802.15.4 | 438 +------------------------------------------+ 440 Figure 4 442 When the IE parser identifies a CoAP IE in the data packet, it passes 443 the IE content (i.e. the fragmented CoAP message) to the CoAP Parser. 444 The CoAP Parser then assembles those fragmented CoAP messages, and 445 takes the appropriate action based on the CoAP Code, Uri-Path, and 446 payload. 448 When a CoAP message is formatted, it MAY be fragmented, then passed 449 to the IE Formatting module. The IE Formatting module puts those 450 (possibly fragmented) CoAP message(s) into a CoAP IE and pases them 451 to the IEEE802.15.4e TSCH layer as separate packets. 453 6. References 455 6.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 6.2. Informative References 462 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 463 Network Configuration Protocol (NETCONF)", RFC 6020, 464 October 2010. 466 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 467 Application Protocol (CoAP)", RFC 7252, June 2014. 469 [I-D.ietf-core-block] 470 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 471 draft-ietf-core-block-14 (work in progress), October 2013. 473 [I-D.ietf-6tisch-tsch] 474 Watteyne, T., Palattella, M., and L. Grieco, "Using 475 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 476 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 477 progress), November 2013. 479 [I-D.ietf-6tisch-architecture] 480 Thubert, P., Watteyne, T., and R. Assimiti, "An 481 Architecture for IPv6 over the TSCH mode of IEEE 482 802.15.4e", draft-ietf-6tisch-architecture-02 (work in 483 progress), June 2014. 485 [I-D.ietf-6tisch-terminology] 486 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 487 "Terminology in IPv6 over the TSCH mode of IEEE 488 802.15.4e", draft-ietf-6tisch-terminology-01 (work in 489 progress), February 2014. 491 [I-D.ietf-6tisch-minimal] 492 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 493 Configuration", draft-ietf-6tisch-minimal-01 (work in 494 progress), June 2014. 496 [I-D.ietf-6tisch-6top-interface] 497 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 498 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 499 6top-interface-00 (work in progress), March 2014. 501 [I-D.ietf-6tisch-coap] 502 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 503 Interaction using CoAP", draft-ietf-6tisch-coap-00 (work 504 in progress), May 2014. 506 [I-D.wang-6tisch-6top-sublayer] 507 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 508 Operation Sublayer (6top)", draft-wang-6tisch-6top- 509 sublayer-00 (work in progress), February 2014. 511 6.3. External Informative References 513 [IEEE802154e] 514 IEEE standard for Information Technology, "IEEE std. 515 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 516 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 517 2012. 519 [IEEE802154] 520 IEEE standard for Information Technology, "IEEE std. 521 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 522 and Physical Layer (PHY) Specifications for Low-Rate 523 Wireless Personal Area Networks", June 2011. 525 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 526 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 527 a Standards-Based Low-Power Wireless Development 528 Environment", Transactions on Emerging Telecommunications 529 Technologies , August 2012. 531 [morell04label] 532 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 533 Watteyne, "Label Switching over IEEE802.15.4e Networks. 534 Transactions on Emerging Telecommunications Technologies", 535 June 2013. 537 Authors' Addresses 539 Qin Wang (editor) 540 Univ. of Sci. and Tech. Beijing 541 30 Xueyuan Road 542 Beijing, Hebei 100083 543 China 545 Phone: +86 (10) 6233 4781 546 Email: wangqin@ies.ustb.edu.cn 547 Xavier Vilajosana 548 Universitat Oberta de Catalunya 549 156 Rambla Poblenou 550 Barcelona, Catalonia 08018 551 Spain 553 Phone: +34 (646) 633 681 554 Email: xvilajosana@uoc.edu 556 Thomas Watteyne 557 Linear Technology 558 30695 Huntwood Avenue 559 Hayward, CA 94544 560 USA 562 Phone: +1 (510) 400-2978 563 Email: twatteyne@linear.com 565 Raghuram S Sudhaakar 566 Cisco Systems, Inc 567 Building 24 568 510 McCarthy Blvd 569 San Jose 95135 570 USA 572 Phone: +1 408 853 0844 573 Email: rsudhaak@cisco.com 575 Pouria Zand 576 University of Twente 577 Department of Computer Science 578 Zilverling Building 579 Enschede 7522 NB 580 The Netherlands 582 Phone: +31 619040718 583 Email: p.zand@utwente.nl