idnits 2.17.1 draft-watteyne-6tsch-tsch-lln-context-02.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 (May 23, 2013) is 3989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 544, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 550, but not defined == Missing Reference: 'WHART' is mentioned on line 556, but not defined == Missing Reference: 'ISA100' is mentioned on line 560, but not defined == Missing Reference: 'Emerson' is mentioned on line 564, but not defined == Missing Reference: 'CurrentCalculator' is mentioned on line 583, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 569, but not defined == Missing Reference: 'OpenWSNETT' is mentioned on line 572, but not defined == Missing Reference: 'IPSO' is mentioned on line 580, but not defined == Missing Reference: 'TSMP' is mentioned on line 595, but not defined == Missing Reference: 'TASA-PIMRC' is mentioned on line 625, but not defined == Missing Reference: 'TASA-SENSORS' is mentioned on line 632, but not defined == Missing Reference: 'TASA-WCNC' is mentioned on line 639, but not defined == Missing Reference: 'PANA' is mentioned on line 654, but not defined == Unused Reference: 'RFC2119' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 519, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-thubert-roll-forwarding-frags-01 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-04 == Outdated reference: A later version (-05) exists of draft-sarikaya-core-sbootstrapping-04 == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-00 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-16 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 Summary: 2 errors (**), 0 flaws (~~), 32 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH T. Watteyne, Ed. 3 Internet-Draft Linear Technology 4 Intended status: Informational MR. Palattella 5 Expires: November 24, 2013 University of Luxembourg 6 LA. Grieco 7 Politecnico di Bari 8 May 23, 2013 10 Using IEEE802.15.4e TSCH in an LLN context: 11 Overview, Problem Statement and Goals 12 draft-watteyne-6tsch-tsch-lln-context-02 14 Abstract 16 This document describes the environment, problem statement, and goals 17 for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. 18 The set of goals enumerated in this document form an initial set 19 only. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 24, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4 57 3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7 59 3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7 60 3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 8 61 3.4. Routing and Timing Parents . . . . . . . . . . . . . . . 8 62 3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8 63 3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 9 64 3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 9 65 3.8. Path Computation Engine . . . . . . . . . . . . . . . . . 9 66 3.9. Secure Communication . . . . . . . . . . . . . . . . . . 9 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 5.2. Informative References . . . . . . . . . . . . . . . . . 10 71 5.3. External Informative References . . . . . . . . . . . . . 13 72 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 15 73 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 15 74 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 16 75 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 16 76 A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16 77 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17 78 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17 79 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 17 80 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18 81 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19 82 A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19 83 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 20 84 A.12. Information Elements . . . . . . . . . . . . . . . . . . 20 85 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 21 86 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 21 87 B.1. Collision Free Communication . . . . . . . . . . . . . . 21 88 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21 89 B.3. Cost of (continuous) Synchronization . . . . . . . . . . 21 90 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 22 91 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 95 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 96 amendment to the Medium Access Control (MAC) protocol defined by the 97 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 98 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. 100 In particular, this document describes the main issues arising from 101 the adoption of the IEEE802.15.4e TSCH in the LLN context, mainly 102 following the terminology defined in 103 [I-D.palattella-6tsch-terminology]. 105 TSCH was designed to "allow IEEE802.15.4 devices to support a wide 106 range of industrial applications" [IEEE802154e]. At its core is a 107 medium access technique which uses time synchronization to achieve 108 ultra low-power operation and channel hopping to enable high 109 reliability. This is very different from the "legacy" IEEE802.15.4 110 MAC protocol, and is therefore better described as a "redesign". 111 TSCH does not amend the physical layer; i.e., it can operate on any 112 IEEE802.15.4-compliant hardware. 114 IEEE802.15.4e can be seen as the latest generation of ultra-lower 115 power and reliable networking solutions for LLNs. Its core 116 technology is similar to the one used in industrial networking 117 technologies such as WirelessHART [WHART] or ISA100.11a [ISA100]. 118 These protocol solutions have been targeted essentially at the 119 industrial market. WirelessHART is for example the wireless 120 extension of HART, a long standing protocol suite for networking 121 industrial equipment. 123 [RFC5673] discusses industrial applications, and highlights the harsh 124 operating conditions as well as the stringent reliability, 125 availability, and security requirements for an LLN to operate in an 126 industrial environment. Industrial protocols such as WirelessHART 127 satisfy those requirements, and with tens of thousands of networks 128 deployed [Emerson], these types of networks have a large impact on 129 industrial applications. Commercial networking solutions are 130 available today in which motes consume 10's of micro-amps on average 131 [CurrentCalculator] with end-to-end packet delivery ratios over 132 99.999% [doherty07channel]. 134 IEEE802.15.4e builds on the same foundations as WirelessHART, and 135 therefore exhibits similar performance. Yet, unlike an industrial 136 protocol which is, by nature, application-specific, IEEE802.15.4e 137 TSCH focuses on the MAC layer only. This clean layering allows for 138 TSCH to fit under an IPv6 enabled protocol stack for LLNs, running 139 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap]. 141 Bringing industrial-like performance into the LLN stack developed by 142 the 6LoWPAN, ROLL and CORE working groups opens up new application 143 domains for these networks. Sensors deployed in smart cities 144 [RFC5548] will be able to be installed for years without needing 145 battery replacement. "Umbrella" networks will interconnect smart 146 elements from different entities in smart buildings [RFC5867]. Peel- 147 and-stick switches will obsolete the need for costly conduits for 148 lighting solutions in smart homes [RFC5826]. 150 While [IEEE802154e] defines the mechanisms for a TSCH mote to 151 communicate, it does not define the policies to build and maintain 152 the communication schedule, match that schedule to the multi-hop 153 paths maintained by RPL, adapt the resources allocated between 154 neighbor nodes to the data traffic flows, enforce a differentiated 155 treatment for data generated at the application layer and signaling 156 messages needed by 6LoWPAN and RPL to discover neighbors, react to 157 topology changes, self-configure IP addresses, or manage keying 158 material. 160 In other words, IEEE802.15.4e TSCH is designed to allow optimizations 161 and strong customizations, simplifying the merging of TSCH with a 162 protocol stack based on IPv6, 6LoWPAN, and RPL. 164 2. TSCH in the LLN Context 165 In many cases, to map the services required by the IP layer to the 166 services provided by the link layer, an adaptation layer is used 167 [palattella12standardized]. The 6LoWPAN working group started 168 working in 2007 on specifications for transmitting IPv6 packets over 169 IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are 170 characterized by small packet sizes, support for addresses with 171 different lengths, low bandwidth, star and mesh topologies, battery 172 powered devices, low cost, large number of devices, unknown node 173 positions, high unreliability, and periods during which communication 174 interfaces are turned off to save energy. Given these features, it 175 is clear that the adoption of IPv6 on top of a Low-Power WPAN is not 176 straightforward, but poses strong requirements for the optimization 177 of this adaptation layer. For instance, due to the IPv6 default 178 minimum MTU size (1280 bytes), an un-fragmented IPv6 packet is too 179 large to fit in an IEEE802.15.4 frame. Moreover, the overhead due to 180 the 40-byte long IPv6 header wastes the scarce bandwidth available at 181 the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working 182 group has defined an effective adaptation layer [RFC6568]. Further 183 issues encompass the auto-configuration of IPv6 addresses 184 [RFC2464][RFC6755], the compliance with the recommendation on 185 supporting link-layer subnet broadcast in shared networks [RFC3819], 186 the reduction of routing and management overhead [RFC6606], the 187 adoption of lightweight application protocols (or novel data encoding 188 techniques), and the support for security mechanisms (confidentiality 189 and integrity protection, device bootstrapping, key establishment, 190 and management). 192 These features can run on top of TSCH. There are, however, important 193 issues to solve, as highlighted in Section 3. 195 Routing issues are challenging for 6LoWPAN, given the low-power and 196 lossy radio-links, the battery supplied nodes, the multi-hop mesh 197 topologies, and the frequent topology changes due to mobility. 198 Successful solutions take into account the specific application 199 requirements, along with IPv6 behavior and 6LoWPAN mechanisms 200 [palattella12standardized]. The ROLL working group has defined RPL 201 in [RFC6550]. RPL can support a wide variety of link layers, 202 including ones that are constrained, potentially lossy, or typically 203 utilized in conjunction with host or router devices with very limited 204 resources, as in building/home automation [RFC5867][RFC5826], 205 industrial environments [RFC5673], and urban applications [RFC5548]. 206 RPL is able to quickly build up network routes, distribute routing 207 knowledge among nodes, and adapt to a changing topology. In a 208 typical setting, motes are connected through multi-hop paths to a 209 small set of root devices, which are usually responsible for data 210 collection and coordination. For each of them, a Destination 211 Oriented Directed Acyclic Graph (DODAG) is created by accounting for 212 link costs, node attributes/status information, and an Objective 213 Function, which maps the optimization requirements of the target 214 scenario. The topology is set up based on a Rank metric, which 215 encodes the distance of each node with respect to its reference root, 216 as specified by the Objective Function. Regardless of the way it is 217 computed, the Rank monotonically decreases along the DODAG towards 218 the destination, building a gradient. RPL encompasses different 219 kinds of traffic and signaling information. Multipoint-to-Point 220 (MP2P) is the dominant traffic in LLN applications. Data is routed 221 towards nodes with some application relevance, such as the LLN 222 gateway to the larger Internet, or to the core of private IP 223 networks. In general, these destinations are the DODAG roots and act 224 as data collection points for distributed monitoring applications. 225 Point-to-Multipoint (P2MP) data streams are used for actuation 226 purposes, where messages are sent from DODAG roots to destination 227 nodes. Point-to-Point (P2P) traffic allows communication between two 228 devices belonging to the same LLN, such as a sensor and an actuator. 229 A packet flows from the source to the common ancestor of those two 230 communicating devices, then downward towards the destination. RPL 231 therefore has to discover both upward routes (i.e. from nodes to 232 DODAG roots) in order to enable MP2P and P2P flows, and downward 233 routes (i.e. from DODAG roots to nodes) to support P2MP and P2P 234 traffic. 236 Section 3 highlights the challenges that need to be addressed to use 237 RPL on top of TSCH. 239 Several open-source initiatives have emerged around TSCH. The 240 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source 241 implementation of a fully standards-based protocol stack, which aims 242 at evaluating the applicability of TSCH to different applications. 243 This implementation was used as the foundation for an IP for Smart 244 Objects Alliance (IPSO) [IPSO] iteroperability event in 2011. In the 245 absence of a standardized scheduling mechanism for TSCH, a "slotted 246 Aloha" schedule was used. 248 3. Problems and Goals 250 As highlighted in Appendix A, TSCH is different for traditional low- 251 power MAC protocols because of its scheduled nature. TSCH defines 252 the mechanisms to execute a communication schedule, yet it is the 253 entity that sets up that schedule which controls the topology of the 254 network. This scheduling entity also contriols the resources 255 allocated to each link in that topology. 257 How this entity should operate is out of scope of TSCH. The 258 remainder of this section highlights the problems this entity needs 259 to address. For simplicity, we will refer to this entity by the 260 generic name "6TSCH", without loss of generality. In particular, we 261 do not assume any specific nature of 6TSCH, whether an adaptation 262 layer, a distributed reservation protocol, a centralized path 263 computation engine, or any combination thereof. 265 Some of the issues 6TSCH need to target might overlap with the scope 266 of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this case, it 267 is entailed that 6TSCH will profit from the services provided by 268 other protocols to pursue these objectives. 270 3.1. Network Formation 272 6TSCH needs to control the way the network is formed, including how 273 new motes join, and how already joined motes advertise the presence 274 of the network. 6TSCH needs to: 276 1. Define the Information Elements to include in the Enhanced 277 Beacons advertising the presence of the network. 279 2. For a new mote, define rules to process and filter received 280 Enhanced Beacons. This includes a mechanism to select the best 281 mote through which to join the network. 283 3. Define the joining procedure. This includes a mechanism to 284 assign a unique 16-bit address to a mote, and the management of 285 initial keying material. 287 4. Define a mechanism to secure the joining process and the 288 subsequent optional process of scheduling more communication 289 links. 291 3.2. Network Maintenance 293 Once a network is formed, 6TSCH needs to maintain the network's 294 health, allowing for motes to stay synchronized. 6TSCH needs to: 296 1. Manage each mote's time source neighbor(s). 298 2. Define a mechanism for a mote to update the join priority it 299 announces in its Enhanced Beacon. 301 3. Schedule transmissions of Enhanced Beacons to advertise the 302 presence of the network. 304 3.3. Multi-Hop Topology 306 RPL, given a weighted connectivity graph, determines multi-hop 307 routes. 6TSCH needs to: 309 1. Define a mechanism to gather topological information, which it 310 can then feed to RPL. 312 2. Ensure that the TSCH schedule contains links along the multi-hop 313 routes identified by RPL. 315 3. Where applicable, maintain independent sets of links to transport 316 independent flows of data. 318 3.4. Routing and Timing Parents 320 At all times, a TSCH mote needs to have at least one time source 321 neighbor it can synchronize to. 6TSCH therefore needs to assign time 322 source neighbors to allow for correct operation of the TSCH network. 323 These time source neighbors could, or not, be related to RPL routing 324 parents. 326 3.5. Resource Management 328 A link in a TSCH schedule is a "unit" of resource. The number of 329 links to assign between neighbor motes needs to be appropriate for 330 the size of the traffic flow. 6TSCH needs to: 332 1. Define rules on when to create or delete a slotframe. 334 2. Define rules to determine the length of a slotframe, and the 335 trigger to modify the length of a slotframe. 337 3. Define rules on when to add or delete links in a particular 338 slotframe. 340 4. Define a mechanism for neighbor nodes to exchange information 341 about their schedule and, if applicable, negotiate the addition/ 342 deletion of links. 344 5. Allow for a (possibly centralized) entity to take full control 345 over the schedule. 347 6. Define a set of metrics to evaluate the tradeoff between latency, 348 bandwidth and energy consumption achieved by a particular 349 schedule. 351 3.6. Dataflow Control 353 TSCH defines mechanisms for a mote to signal it cannot accept an 354 incoming packet. It does not, however, define the policy which 355 determines when to stop accepting packets. 6TSCH need to: 357 1. Define a queueing policy for incoming and outgoing packets. 359 2. Manage the buffer space, and indicate to TSCH when to stop 360 accepting incoming packets. 362 3. Handle transmissions that have failed. A transmission is 363 declared failed when TSCH has retransmitted the packet multiple 364 times, without receiving an acknowledgment. This covers both 365 dedicated and shared links. 367 3.7. Deterministic Behavior 369 As highlighted in [RFC5673], in some applications, data is generated 370 periodically and has a well understood data bandwidth requirement, 371 which is deterministic and predictable. 6TSCH need to: 373 1. Ensure timely delivery of such data. 375 2. Provide a mechanism for such deterministic flows to coexist with 376 bursty or infrequent traffic flows of different priorities. 378 3.8. Path Computation Engine 380 As highlighted in [I-D.phinney-roll-rpl-industrial-applicability], 381 bandwidth allocation and multi-hop routes can be optimized by an 382 external Path Computation Engine (PCE). 6TSCH need to: 384 1. Provide a mechanism for an external PCE to be able to control the 385 entire schedule of the network, including the slotframes, links 386 and time source neighbor assignment. 388 2. Define a optional mechanism for the schedule managed by this PCE 389 to coexist with scheduling elements (slotframes, links) managed 390 up by a different mechanism such as a distribute scheduling 391 algorithm. 393 3.9. Secure Communication 395 Given some keying material, TSCH defines mechanisms to encrypt and 396 authenticate MAC frames. It does not define how this keying material 397 is generated. 6TSCH need to: 399 1. Define the keying material and authentication mechanism needed by 400 a new mote to join an existing network. 402 2. Define a mechanism to allow for the secure transfer of 403 application data between neighbor motes. 405 3. Define a mechanism to allow for the secure transfer of signaling 406 data between motes and 6TSCH. 408 4. Acknowledgements 410 Special thanks to Jonathan Simon for his review and valuable 411 comments. 413 5. References 415 5.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 5.2. Informative References 422 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 423 Networks", RFC 2464, December 1998. 425 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 426 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 427 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 428 RFC 3819, July 2004. 430 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 431 over Low-Power Wireless Personal Area Networks (6LoWPANs): 432 Overview, Assumptions, Problem Statement, and Goals", RFC 433 4919, August 2007. 435 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 436 "Transmission of IPv6 Packets over IEEE 802.15.4 437 Networks", RFC 4944, September 2007. 439 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 440 "Routing Requirements for Urban Low-Power and Lossy 441 Networks", RFC 5548, May 2009. 443 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 444 Routing Requirements in Low-Power and Lossy Networks", RFC 445 5826, April 2010. 447 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 448 "Building Automation Routing Requirements in Low-Power and 449 Lossy Networks", RFC 5867, June 2010. 451 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 452 "Industrial Routing Requirements in Low-Power and Lossy 453 Networks", RFC 5673, October 2009. 455 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 456 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 457 September 2011. 459 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 460 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 461 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 462 Lossy Networks", RFC 6550, March 2012. 464 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 465 Application Spaces for IPv6 over Low-Power Wireless 466 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 468 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 469 Statement and Requirements for IPv6 over Low-Power 470 Wireless Personal Area Network (6LoWPAN) Routing", RFC 471 6606, May 2012. 473 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 474 for OAuth", RFC 6755, October 2012. 476 [I-D.thubert-roll-forwarding-frags] 477 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 478 Recovery", draft-thubert-roll-forwarding-frags-01 (work in 479 progress), February 2013. 481 [I-D.tsao-roll-security-framework] 482 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 483 Security Framework for Routing over Low Power and Lossy 484 Networks", draft-tsao-roll-security-framework-02 (work in 485 progress), March 2010. 487 [I-D.thubert-roll-asymlink] 488 Thubert, P., "RPL adaptation for asymmetrical links", 489 draft-thubert-roll-asymlink-02 (work in progress), 490 December 2011. 492 [I-D.ietf-roll-terminology] 493 Vasseur, J., "Terminology in Low power And Lossy 494 Networks", draft-ietf-roll-terminology-12 (work in 495 progress), March 2013. 497 [I-D.ietf-roll-p2p-rpl] 498 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 499 Martocci, "Reactive Discovery of Point-to-Point Routes in 500 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 501 (work in progress), March 2013. 503 [I-D.ietf-roll-trickle-mcast] 504 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 505 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 506 mcast-04 (work in progress), February 2013. 508 [I-D.thubert-6lowpan-backbone-router] 509 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 510 6lowpan-backbone-router-03 (work in progress), February 511 2013. 513 [I-D.sarikaya-core-sbootstrapping] 514 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 515 Cragie, "Security Bootstrapping Solution for Resource- 516 Constrained Devices", draft-sarikaya-core- 517 sbootstrapping-04 (work in progress), April 2012. 519 [I-D.gilger-smart-object-security-workshop] 520 Gilger, J. and H. Tschofenig, "Report from the 'Smart 521 Object Security Workshop', 23rd March 2012, Paris, 522 France", draft-gilger-smart-object-security-workshop-00 523 (work in progress), October 2012. 525 [I-D.phinney-roll-rpl-industrial-applicability] 526 Phinney, T., Thubert, P., and R. Assimiti, "RPL 527 applicability in industrial networks", draft-phinney-roll- 528 rpl-industrial-applicability-02 (work in progress), 529 February 2013. 531 [I-D.ietf-core-coap] 532 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 533 Application Protocol (CoAP)", draft-ietf-core-coap-16 534 (work in progress), May 2013. 536 [I-D.palattella-6tsch-terminology] 537 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 538 "Terminology in IPv6 over Time Slotted Channel Hopping", 539 draft-palattella-6tsch-terminology-00 (work in progress), 540 March 2013. 542 5.3. External Informative References 544 [IEEE802154e] 545 IEEE standard for Information Technology, "IEEE std. 546 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 547 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 548 2012. 550 [IEEE802154] 551 IEEE standard for Information Technology, "IEEE std. 552 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 553 and Physical Layer (PHY) Specifications for Low-Rate 554 Wireless Personal Area Networks", June 2011. 556 [WHART] www.hartcomm.org, "Highway Addressable Remote Transducer, 557 a group of specifications for industrial process and 558 control devices administered by the HART Foundation", . 560 [ISA100] ISA, "ISA100, Wireless Systems for Automation", May 2008, 561 < http://www.isa.org/Community/ 562 SP100WirelessSystemsforAutomation>. 564 [Emerson] Emerson Process Management, "Emerson Process Management 565 Smart Wireless Homepage", , < http:// 566 www2.emersonprocess.com/en-US/plantweb/wireless/Pages/ 567 WirelessHomePage-Flash.aspx>. 569 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 570 . 572 [OpenWSNETT] 573 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 574 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 575 a standards-based low-power wireless development 576 environment", Transactions on Emerging Telecommunications 577 Technologies 2012, August 2012, . 580 [IPSO] , "IP for Smart Objects Alliance Homepage", , 581 . 583 [CurrentCalculator] 584 Linear Technology, "Application Note: Using the Current 585 Calculator to Estimate Mote Power", August 2012, . 589 [doherty07channel] 590 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific 591 Wireless Sensor Network Path Data", IEEE International 592 Conference on Computer Communications and Networks (ICCCN) 593 2008, 2007. 595 [TSMP] Pister, K. and L. Doherty, "TSMP: Time Synchronized Mesh 596 Prootocol", International Symposium on Distributed Sensor 597 Networks (DSN) 2008, Nov. 2008, < http:// 598 robotics.eecs.berkeley.edu/~pister/publications/2008/ 599 TSMP%20DSN08.pdf>. 601 [tinka10decentralized] 602 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized 603 Scheduling Algorithm for Time Synchronized Channel 604 Hopping", Ad Hoc Networks 2010, 2010, < http:// 605 robotics.eecs.berkeley.edu/~pister/publications/2008/ 606 TSMP%20DSN08.pdf>. 608 [watteyne09reliability] 609 Watteyne, T., Mehta, A., and K. Pister, "Reliability 610 Through Frequency Diversity: Why Channel Hopping Makes 611 Sense", International Conference on Performance Evaluation 612 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE- 613 WASUN) 2009, Oct. 2009, . 616 [kerkez09feasibility] 617 Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility 618 analysis of controller design for adaptive channel 619 hopping", International Workshop on Performance 620 Methodologies and Tools for Wireless Sensor Networks 621 (WSNPERF) 2009, Oct. 2009, . 625 [TASA-PIMRC] 626 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 627 and G. Boggia, "Traffic Aware Scheduling Algorithm for 628 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept. 629 2012, < http://www.cttc.es/resources/doc/120531-submitted- 630 tasa-25511.pdf>. 632 [TASA-SENSORS] 633 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 634 and G. Boggia, "Traffic-Aware Time-Critical Scheduling In 635 Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT", 636 IEEE SENSORS 2012, Oct. 2012, < http://www.cttc.es/ 637 resources/doc/120821-sensors2012-4396981770946977737.pdf>. 639 [TASA-WCNC] 640 Accettura, N., Palattella, MR., Dohler, M., Grieco, LA., 641 and G. Boggia, "Standardized Power-Efficient and Internet- 642 Enabled Communication Stack for Capillary M2M Networks", 643 IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/ 644 doc/120109-1569521283-submitted-58230.pdf>. 646 [palattella12standardized] 647 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, 648 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized 649 Protocol Stack For The Internet Of (Important) Things", 650 IEEE Communications Surveys and Tutorials 2012, Dec. 2012, 651 < http://www.cttc.es/resources/doc/121025 652 -completestackforiot-clean-4818610916636121981.pdf>. 654 [PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA 655 applicability in constrained environments", Febr. 2012, 656 . 659 Appendix A. TSCH Protocol Highlights 661 This appendix gives an overview of the key features of the 662 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes 663 no attempt at repeating the standard, but rather focuses on the 664 following: 666 o Concepts which are sufficiently different from traditional 667 IEEE802.15.4 networking that they may need to be defined and 668 presented precisely. 670 o Techniques and ideas which are part of IEEE802.15.4e and which 671 might be useful for the work of 6TSCH. 673 A.1. Timeslots 675 All motes in a TSCH network are synchronized. Time is sliced up into 676 timeslots. A timeslot is long enough for a MAC frame of maximum size 677 to be sent from mote A to mote B, and for mote B to reply with an 678 acknowledgment (ACK) frame indicating successful reception. 680 The duration of a timeslot is not defined by the standard. With 681 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band, 682 a maximum-length frame of 127 bytes takes about 4ms to transmit; a 683 shorter ACK takes about 1ms. With a 10ms slot (a typical duration), 684 this leaves 5ms to radio turnaround, packet processing and security 685 operations. 687 A.2. Slotframes 689 Timeslots are grouped into one of more slotframes. A slotframe 690 continuously repeats over time. TSCH does not impose a slotframe 691 size. Depending on the application needs, these can range from 10s 692 to 1000s of timeslots. The shorter the slotframe, the more often a 693 timeslot repeats, resulting in more available bandwidth, but also in 694 a higher power consumption. 696 A.3. Node TSCH Schedule 698 A TSCH schedule instructs each mote what to do in each timeslot: 699 transmit, receive or sleep. The schedule indicates, for each 700 scheduled (transmit or receive) cell a channelOffset and the address 701 of the neighbor to communicate with. 703 Once a mote obtains its schedule, it executes it: 705 o For each transmit cell, the mote checks whether there is a packet 706 in the outgoing buffer which matches the neighbor written in the 707 schedule information for that timeslot. If there is none, the 708 mote keeps its radio off for the duration of the timeslot. If 709 there is one, the mote can ask for the neighbor to acknowledge it, 710 in which case it has to listen for the acknowledgment after 711 transmitting. 713 o For each receive cell, the mote listens for possible incoming 714 packets. If none is received after some listening period, it 715 shuts down its radio. If a packet is received, addressed to the 716 mote, and passes security checks, the mote can send back an 717 aknowledgment. 719 How the schedule is built, updated and maintained, and by which 720 entity, is outside of the scope of the IEEE802.15.4e standard. 722 A.4. Cells and Bundles 724 Assuming the schedule is well built, if mote A is scheduled to 725 transmit to mote B at slotOffset 5 and channelOffset 11, mote B will 726 be scheduled to receive from mote A at the same slotOffset and 727 channelOffset. 729 A single element of the schedule characterized by a slotOffset and 730 channelOffset, and reserved for mote A to transmit to mote B (or for 731 mote B to receive from mote A) within a given slotframe, is called a 732 "scheduled cell". 734 If there is a lot of data flowing from mote A to mote B, the schedule 735 might contain multiple cells from A to B, at different times. 736 Multiple cells scheduled to the same neighbor are typically 737 equivalent, i.e. the MAC layer sends the packet on whichever of 738 these cells happens to show up first after the packet was put in the 739 MAC queue. The union of all cells between two neighbors, A and B, is 740 called a "boundle". Since the slotframe repeats over time (and the 741 length of the slotframe is typically constant), each cell gives a 742 "quantum" of bandwidth to a given neighbor. Modifying the number of 743 equivalent cells in a boundle modifies the amount of resources 744 allocated between two neighbors. 746 A.5. Dedicated vs. Shared Cells 748 By default, each scheduled transmit cell within the TSCH schedule is 749 dedicated, i.e., reserved only for mote A to transmit to mote B. 750 IEEE802.15.4e allows also to mark a cell as shared. In a shared 751 cell, multiple motes can transmit at the same time, on the same 752 fequency. To avoid contention, TSCH defines a back-off algorithm for 753 shared cells. 755 A scheduled cell can be marked as both transmitting and receiving. 756 In this case, a mote transmits if it has an appropriate packet in its 757 output buffer, or listens otherwise. Marking a cell as 758 [transmit,shared,receive] results in slotted-Aloha behavior. 760 A.6. Absolute Slot Number 762 TSCH defines a timeslot counter called Absolute Slot Number (ASN). 763 When a new network is created, the ASN is initialized to 0; from then 764 on, it increments by 1 at each timeslot. In detail: 766 ASN = (k*S+t) 768 where k is the slotframe cycle (i.e., the number of slotframe 769 occurences over time), S the slotframe size and t the slotOffset. A 770 mote learns the current ASN when it joins the network. Since motes 771 are synchronized, they all know the current value of the ASN, and any 772 time. The ASN is encoded as a 5-byte number: this allows it to 773 increment for hundreds of years (the exact value depends on the 774 duration of a timeslot) without wrapping. The ASN is used (i) to 775 calculate the frequency to communicate on, jointly with the 776 channelOffset, (ii) to build unique security nonce counters used by 777 CCM*. 779 A.7. Channel Hopping 780 For each scheduled cell, the schedule specifies a slotOffset and a 781 channelOffset. In a well-built schedule, when mote A has a transmit 782 cell to mote B on channelOffset 5, mote B has a receive cell from 783 mote A on the same channelOffset. The channelOffset is translated by 784 both nodes into a frequency using the following function: 786 frequency = F {(ASN + channelOffset) mod nFreq} 788 The function F consists of a look-up table containing the set of 789 available channels. The value nFreq (the number of available 790 frequencies) is the size of this look-up table. There are as many 791 channelOffset values as there are frequencies available (e.g. 16 792 when using IEEE802.15.4-compliant radios at 2.4GHz, when all channels 793 are used). Since both motes have the same channelOffset written in 794 their schedule for that scheduled cell, and the same ASN counter 795 since they are synchronized, they compute the same frequency. At the 796 next iteration (cycle) of the slotframe, however, the channelOffset 797 will be the same, but the ASN will have changed, resulting in the 798 computation of a different frequency. If the slotframe size, S (used 799 for computing ASN), and the number of channeloffsets, nFreq, are 800 relatively prime, the translation function ensures that each link 801 rotates through k available channels over k slotframe cycles. This 802 results in "channel hopping": even with a static schedule, pairs of 803 neighbors "hop" between the different frequencies when communicating. 805 The look-up table F can be built to contain only a subset of all 806 available channels. This results in frequency "blacklisting". 808 Channel hopping is a technique known to efficiently combat multi-path 809 fading and external interference. This results in a TSCH network 810 having a more stable topology than if only a single channel were used 811 for the entire network. 813 A.8. Time Synchronization 815 Because of the slotted nature of communication in a TSCH network, 816 motes have to maintain tight synchronization. All motes are assumed 817 to be equipped with clocks to keep track of time (32kHz crystal 818 oscillators are typically used). Yet, because clocks in different 819 motes drift with respect to one another, neighbor motes need to 820 periodically re-synchronize. 822 In detail, each mote periodically synchronizes its network clock to 823 at least one other mote, and it also provides its network time to its 824 neighbors. It is up to the entity that manages the schedule to 825 assign adequate time source neighbor(s) to each mote, i.e., to 826 indicate in the schedule which of its neighbor(s) are its "time 827 source neighbors". While setting the time source neighbor, it is 828 important to avoid synchronization loops, which could result in the 829 formation of independent clusters of motes. 831 Typically, in a IEEE802.15.4e TSCH network, time propagates outwards 832 from the PAN coordinator (i.e., the root node). But the direction of 833 time propagation is independent of data flow in the network. A new 834 mote joining a TSCH network, because it does not have a schedule yet, 835 maintains time synchronization, using the information carried by the 836 Enhanced Beacons (EBs), sent by the advertising motes. 838 TSCH adds timing information in all packets that are exchanged (both 839 data and ACK frames). This means that neighbor motes can 840 resynchronize to one another whenever they exchange data. In detail, 841 in the IEEE 802.15.4e standard two methods are defined for allowing a 842 device to synchronize in a TSCH network: (I) Acknowledgment-Based and 843 (II) Frame-Based synchronization. In both cases, the receiver 844 calculates the difference in time between the expected time of frame 845 arrival and its actual arrival. In Acknowledgment-Based 846 synchronization, the receiver provides such information to the sender 847 mote in its acknowledgment. Thus, in this case, it is the sender 848 mote that synchronizes to the clock of the receiver. In Frame-Based 849 synchronization, the receiver uses the computed delta for adjusting 850 its own clock. Therefore, it is the receiver mote that synchronizes 851 to the clock of the sender. 853 Different synchronization policies are possible. Motes can keep 854 synchronization exclusively by exchanging EBs. Motes can also keep 855 synchronized by periodically sending valid frames to time source 856 neighbors to use the acknowledgement to resynchronize. Both method 857 (or a combination thereof) are valid synchronization policies; which 858 one to use depends on network requirements. 860 A.9. Power Consumption 862 There are only a handful of activities a mote can perform during a 863 timeslot: transmit, receive, or sleep. Each of these operations has 864 some energy cost associated to them, the exact value depending on the 865 the hardware used. Given the schedule of a mote, it is 866 straighforward to calculate the expected average power consumption of 867 that mote. 869 A.10. Network TSCH Schedule 871 The schedule defines entirely the synchronization and communication 872 between motes. By adding/removing cells between neighbors, one can 873 adapt a schedule to the needs of the application. Intuitive examples 874 are: 876 o Make the schedule "sparse" for applications where motes need to 877 consume as little energy as possible, at the price of reduced 878 bandwidth. 880 o Make the schedule "dense" for applications where motes generate a 881 lot of data, at the price of increased power consumption. 883 o Add more cells along a multi-hop route over which many packets 884 flow. 886 A.11. Join Process 888 Motes already part of the network can periodically send Enhanced 889 Beacon (EB) frames to announce the presence the network. These 890 contain information about the size of the timeslot used in the 891 network, the current ASN, information about the slotframes and 892 timeslots the beaconing mote is listening on, and a 1-byte join 893 priority. This join priority corresponds to the number of hops 894 separating the mote sending the EB, and the PAN coordinator. Because 895 of the channel hopping nature of TSCH, these EB frames are sent on 896 all frequencies. 898 A mote wishing to join the network listens on some frequency for EBs. 899 It can wait to receive multiple, and can use the join priority in 900 those EBs to identify the best mote through which to join the 901 network. Using the ASN and the other timing information of the EB, 902 the new mote synchronizes to the network. Using the slotframe and 903 link information from the EB, it knows how to contact the mote it 904 just joined. 906 The TSCH standard does not define the steps beyond this "kickstart". 907 These steps can include a security handshake and the addition of more 908 scheduled cells to the new mote's schedule. 910 A.12. Information Elements 912 TSCH introduces the concept of Information Elements (IES). An 913 information element is a list of Type-Length-Value containers placed 914 at the end of the MAC header. A small number of types are defined 915 for TSCH (e.g., the ASN in the EB is contained in an IE), and an 916 unmanaged range is available for extensions. 918 A data bit in the MAC header indicates whether the frame contains 919 IEs. IEs are grouped into Header IEs, consumed by the MAC layer and 920 therefore typically invisible to the next higher layer, and Payload 921 IEs, which are passed untouched to the next higher layer, possibly 922 followed by regular payload. Payload IEs can therefore be used for 923 the next higher layers of two neighbor motes to exchange information. 925 A.13. Extensibility 927 The TSCH standard is designed to be extensible. It introduces the 928 mechanisms as "building block" (e.g., cells, boundles, slotframes, 929 etc.), but leaves entire freedom to the upper layer to assemble 930 those. The MAC protocol can be extended by defining new Header IEs. 931 An intermediate layer can be defined to manage the MAC layer by 932 defining new Payload IEs. 934 Appendix B. TSCH Gotchas 936 This section lists features of TSCH which we believe are important 937 and beneficial to the work of 6TSCH. 939 B.1. Collision Free Communication 941 TSCH allows one to easily design a schedule which yields collision- 942 free communication. This is done by building the schedule with 943 dedicated cells in such a way that at most one node can communicate 944 with a specific neigbor in each slotOffset/channelOffset cell. 945 Multiple pairs of neighbor motes can exchange data at the same time, 946 but on different frequencies. If a deployment is done over a large 947 area, slotOffset/channelOffset cells can be reused by pairs of 948 neigbors sufficiently far appart not to interfere. 950 B.2. Multi-Channel vs. Channel Hopping 952 A TSCH schedule looks like a matrix of width "slotframe size", S, and 953 of height "number of frequencies", nFreq. For a scheduling 954 algorithm, these can be considered atomic "units" to schedule. In 955 particular, because of the channel hopping nature of TSCH, the 956 scheduling algorithm should not worry about the actual frequency 957 communication happens on, since it changes at each slotframe 958 iteration. 960 B.3. Cost of (continuous) Synchronization 962 When there is traffic in the network, motes which are communicating 963 implicitly re-synchronize using the data frames they exchange. In 964 the absence of data traffic, motes are required to synchronize to 965 their time source neighbor(s) periodically not to drift in time. If 966 they have not been communicating for some time (typically 30s), motes 967 can exchange an empty data frame, often referred to as a "Keep-alive" 968 message, to re-synchronize. The frequency at which such message need 969 to be transmitted depends on the stability of the clock source, and 970 on how "early" each mote starts listening for data (the "guard 971 time"). Theoretically, with a 10ppm clock and a 1ms guard time, this 972 period can be 100s. When acknowledgment-based synchronization is 973 used, re-synchronizing consists in sending any valid frame to the 974 time source neighbor and using the timing information in the ACK to 975 realign the clocks. Assuming this exchange causes the mote's radio 976 to be on for 5ms, this yields a radio duty cycle needed to keep 977 synchronized of 5ms/100s=0.005%. While TSCH does requires motes to 978 resynchronize periodically, the cost of doing so can be considered 979 almost negligible in many applications. 981 B.4. Topology Stability 983 The channel hopping nature of TSCH causes links to be very "stable". 984 Wireless phenomena such as multi-path fading and external 985 interference impact a wireless link between two motes differently on 986 each frequency. If a transmission from mote A to mote B fails, 987 retransmitting on a different frequency has a higher likelihood of 988 succeeding that retransmitting on the same frequency. As a result, 989 even when some frequencies are "behaving bad", channel hopping 990 "smoothens" the contribution of each frequency, resulting in more 991 stable links, and therefore a more stable topology. 993 B.5. Multiple Concurrent Slotframes 995 The TSCH standard allows for multiple slotframes to coexist in a 996 mote's schedule. It is possible that at some timeslot, a mote has 997 multiple activities scheduled (e.g. transmit to mote B on slotframe 998 2, receive from mote C on slotframe 1). To handle this situation, 999 the TSCH standard defines the following precedence rules: 1001 1. Transmissions take precedence over receptions; 1003 2. Lower slotframe identifiers take precedence over higher slotframe 1004 identifiers. 1006 In the example above, the mote would transmit to mote B on slotframe 1007 2. 1009 Authors' Addresses 1011 Thomas Watteyne (editor) 1012 Linear Technology 1013 30695 Huntwood Avenue 1014 Hayward, CA 94544 1015 USA 1017 Phone: +1 (510) 400-2978 1018 Email: twatteyne@linear.com 1019 Maria Rita Palattella 1020 University of Luxembourg 1021 Interdisciplinary Centre for Security, Reliability and Trust 1022 4, rue Alphonse Weicker 1023 Luxembourg L-2721 1024 LUXEMBOURG 1026 Phone: (+352) 46 66 44 5841 1027 Email: maria-rita.palattella@uni.lu 1029 Luigi Alfredo Grieco 1030 Politecnico di Bari 1031 Department of Electrical and Information Engineering 1032 Via Orabona 4 1033 Bari 70125 1034 Italy 1036 Phone: 00390805963911 1037 Email: a.grieco@poliba.it