idnits 2.17.1 draft-dujovne-6tisch-on-the-fly-06.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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 155: '... computed is out of the scope. It MAY...' RFC 2119 keyword, line 324: '...nning within OTF MUST be event-oriente...' RFC 2119 keyword, line 414: '...ber and the parameters MUST be invoked...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2015) is 3190 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 496, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 502, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-04 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-08 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH D. Dujovne, Ed. 3 Internet-Draft Universidad Diego Portales 4 Intended status: Informational LA. Grieco 5 Expires: January 5, 2016 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 University of California Berkeley 10 July 4, 2015 12 6TiSCH On-the-Fly Scheduling 13 draft-dujovne-6tisch-on-the-fly-06 15 Abstract 17 This document describes the environment, problem statement, and goals 18 of On-The-Fly (OTF) scheduling, a Layer-3 mechanism for 6TiSCH 19 networks. The purpose of OTF is to dynamically adapt the aggregate 20 bandwidth, i.e., the number of reserved soft cells between neighbor 21 nodes, based on the specific application constraints to be satisfied. 22 When using OTF, softcell reservation is distributed: through the 6top 23 interface, neighbor nodes negotiate the cell(s) to be (re)allocated/ 24 deleted, with no intervention needed of a centralized entity. This 25 document aims at defining a module which uses the functionalities 26 provided by the 6top sublayer to (i) extract statistics and (ii) 27 determine when to reserve/delete soft cells in the schedule. The 28 exact reservation and deletion algorithm, and the number and type of 29 statistics to be used in the algorithm are out of scope. OTF deals 30 only with the number of softcells to be reserved/deleted; it is up to 31 6top to select the specific soft cells within the TSCH schedule. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 5, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Allocation policy . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Allocation method . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Cell and Bundle Reservation/Deletion . . . . . . . . . . . . 6 71 5. Getting statistics and other information about cells through 72 6top . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Events triggering algorithms in OTF . . . . . . . . . . . . . 8 74 7. Bandwidth Estimation Algorithms . . . . . . . . . . . . . . . 9 75 8. OTF external CoAP interface . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Informative References . . . . . . . . . . . . . . . . . 11 79 10.2. External Informative References . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 85 amendment to the Medium Access Control (MAC) protocol defined by the 86 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 87 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. 89 On-The-Fly (OTF) scheduling is a 1-hop protocol with which a node 90 negotiates the number of soft cells scheduled with its neighbors, 91 without requiring any intervention of a centralized entity (e.g., a 92 PCE). This document describes the OTF allocation policies and 93 methods used by two neighbors to allocate one or more softcells in a 94 distribution fashion. It also proposes an algorithm for estimating 95 the required bandwidth (BW). This document defines the interface 96 between OTF and the 6top sublayer ([I-D.wang-6tisch-6top]), to 97 collect and retrieve statistics, or allocate/delete soft cells. It 98 also defines two threshold values for bounding the number of 99 triggered 6top allocate/delete commands. This document defines a 100 framework; the algorithm and statistics used are out of scope. This 101 draft follows the terminology defined in 102 [I-D.ietf-6tisch-terminology] and addresses the open issue related to 103 the scheduling mechanisms raised in [RFC7554]. 105 2. Allocation policy 107 OTF is a distributed scheduling protocol which increases/decreases 108 the bandwidth between two neighbor nodes (i.e., adding/deleting soft 109 cells) by interacting with the 6top sublayer. It retrieves 110 statistics from 6top, and uses that information to trigger 6top to 111 add/delete softcells to a particular neighbor. The algorithm which 112 decides how many softcells to add/delete is out of scope. For 113 example, OTF might decide to add a cell if some queue of outbound 114 frames is overflowing. Similarly, OTF can delete cells when the 115 queue has been empty for some time. OTF only triggers 6top to add/ 116 delete the soft cells, it is the responsibility of the 6top sublayer 117 to determine the exact slotOffset/channelOffset of those cells. In 118 this document, the term "cell" and "soft cell" are used 119 interchangeably. 121 OTF is a Layer-3 Mechanism, and as such, it operates on L3 links, on 122 the best effort track, i.e. with TrackID=00, as defined in 123 [I-D.wang-6tisch-6top]. Inside an intermediate node, a track is 124 uniquely associated with only one bundle: the outgoing bundle. For 125 an IP link, the bundle is identified by the peer mac address. For 126 instance (macA, macB, TrackID=00) will be the bundle associated to 127 the L3 link between node A and node B. The cells on the best effort 128 track can be used for forwarding any packet in the queue, regardless 129 of the specific L2 bundle (and thus, end-to-end L2 track) the packet 130 belongs to. OTF manages the global bandwidth requirements between 131 two neighbor nodes; per-track management is currently out of scope. 133 OTF is prone to schedule collisions. Nodes might not be aware of the 134 cells allocated by other pairs of nodes. A schedule collision occurs 135 when the same cell is allocated by different pairs in the same 136 interference space. The probability of having allocation collision 137 may be kept low by grouping cells into chunks (see 138 [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture] for 139 more details). The use of chunks is outside the scope of this 140 current version of the OTF draft. 142 The "allocation policy" is the algorithm used by OTF to decide when 143 to increase/decrease the bandwidth allocated between two neighbor 144 nodes in order to satisfy the traffic requirements. These 145 requirements can be expressed in terms of throughput, latency or 146 other constraints. 148 This document introduces the following parameters for describing the 149 behavior of the OTF allocation policy: 151 SCHEDULEDCELLS: The amount of soft cells scheduled in a bundle on 152 the best effort track between two neighbors. 154 REQUIREDCELLS: Number of cells requested by OTF to 6top, a non- 155 negative value. How this is computed is out of the scope. It MAY 156 be an instantaneous request, or a value averaged on several 157 measurements. 159 OTFTHRESHLOW: Threshold parameter introducing cell over-provisioning 160 in the allocation policy. It is a non-negative value expressed as 161 number of cells. Which value to use is application-specific and 162 out of OTF scope. 164 OTFTHRESHHIGH: Threshold parameter introducing cell under- 165 provisioning in the allocation policy. It is a non-negative value 166 expressed as number of cells. Which value to use is application- 167 specific and out of OTF scope. 169 The OTF allocation policy compares the number of required cells 170 against the number of scheduled ones, using the OTF threshold for 171 bounding the signaling overhead due to negotiations of new cells. In 172 details: 174 SCHEDULEDCELLS 175 <-------------------------------------> 176 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 177 | | | | | | | | | | | | | | | 178 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 179 |<----------------->|<------------->| 180 | OTFTHRESHLOW | OTFTHRESHHIGH | 181 | | | 182 REQUIREDCELLS | | | 183 +---+---+---+ | | | ADD 184 | | | | | | | SOME 185 +---+---+---+ | | | CELLS 186 | | | 187 REQUIREDCELLS | | 188 +---+---+---+---+---+---+---+ | | DO 189 | | | | | | | | | | NOTHING 190 +---+---+---+---+---+---+---+ | | 191 | | | 192 REQUIREDCELLS | | 193 +---+---+---+---+---+---+---+---+---+---+---+ | DO 194 | | | | | | | | | | | | | NOTHING 195 +---+---+---+---+---+---+---+---+---+---+---+ | 196 | | | 197 | REQUIREDCELLS | | 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ REMOVE 199 | | | | | | | | | | | | | | | | SOME 200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ CELLS 202 Figure 1: Relation among the OTF parameters used for triggering 6top 203 add/remove soft cell commands 205 1. If REQUIREDCELLS is greater than (SCHEDULEDCELLS + 206 OTFTHRESHHIGH), OTF asks 6top to add one or more soft cells to 207 the bundle on the best effort track. 209 2. If REQUIREDCELLS is greater or equal than (SCHEDULEDCELLS - 210 OTFTHRESHLOW), and it is lower than or equal to (SCHEDULEDCELLS + 211 OTFTHRESHHIGH), OTF does not perform any bundle resizing, since 212 the scheduled cells are sufficient for managing the current 213 traffic conditions. 215 3. If REQUIREDCELLS is lower than (SCHEDULEDCELLS - OTFTHRESHLOW), 216 OTF asks 6top to delete one or more soft cells from the bundle on 217 the best-effort track. 219 When both OTFTHRESHLOW and OTFTHRESHHIGH are equal to 0, any 220 discrepancy between REQUIREDCELLS and SCHEDULEDCELLS triggers a 6top 221 negotiation of soft cells. Other values for the thresholds, 222 different from 0, reduce the number of triggered 6top negotiations. 224 The number of soft cells to be scheduled/deleted for bundle resizing 225 is out of the scope of this document and implementation-dependant. 227 3. Allocation method 229 Beyond the allocation policies that describe the approach used by OTF 230 for fulfilling the node bandwidth requests, the OTF framework also 231 includes the Allocation Method that specify how OTF issues commands 232 to the 6top sublayer. As specified in [I-D.wang-6tisch-6top], 6top 233 provides a set of commands that allows OTF to allocate/delete soft 234 cells. Such commands are used by the OTF soft cell allocation 235 method. 237 With the soft cell allocation method, OTF can ask 6top to reserve one 238 (or N > 1) soft cell(s) on the best effort L3 boundle, between two 239 neighbor nodes. The 6top layer allocates and maintains these cells. 240 If a L3 bundle with TrackID=00 was already reserved between the same 241 pair of neighbors, 6top translates the OTF request into a bundle 242 resize request. The newly allocated cell increases the size of the 243 already existing bundle. Similarly, when OTF realizes there is a 244 reduction of traffic exchanged between the two neighbors, it may asks 245 6top to delete a softcell (or N > 1) from the best effort track, i.e. 246 to decrease the size of the best effort L3 bundle. If no bundle with 247 TrackID=00 exists when 6top receives the OTF request, then the 6top 248 softcell create command generates a new bundle of size 1. 250 4. Cell and Bundle Reservation/Deletion 252 In order to reserve/delete softcells, OTF interacts with 6top 253 sublayer. To this aim OTF uses the following set of commands offered 254 by 6top: CREATE.softcell, and DELETE.softcell. When creating 255 (deleting) a softcell, OTF specifies the track the cell belongs to 256 (i.e., best effort track, TrackID=00), but not its slotOffset nor the 257 channelOffset. If at least one cell on the best effort L3 bundle 258 already exists, the CREATE.softcell and DELETE.softcell, translate 259 into INCREASE and DECREASE the bundle size, respectively. 6top is 260 responsible for picking the specific cell to be added/deleted within 261 the bundle. Before being able to do so, source and destination nodes 262 go through a cell negotiation process. This process is out of scope 263 of 6top and OTF. By using the CREATE.softcell command, OTF can ask 264 6top to add multiple softcells on the best effort L3 bundle. 265 Following OTF request, 6top either (i) creates a new bundle, if no 266 cells were reserved already on the best effort track, or (ii) 267 increases the L3 bundle size of the already existing best-effort 268 bundle. By using the DELETE.softcell command, OTF can ask 6top to 269 delete cells from the best effort bundle. 271 OTF provides a policy for 6top to generate CREATE/DELETE.softcells 272 commands, policy that is out of 6top scope [I-D.wang-6tisch-6top]. 273 Such policy is not the only one that can be used by 6top. Others may 274 be defined in the future. 276 5. Getting statistics and other information about cells through 6top 278 Statistics are kept in 4 data structures of 6top MIB: CellList, 279 MonitoringStatusList, NeighborList, and QueueList. 281 CellList provides per-cell statistics. From this list, an upper 282 layer can get per-bundle statistics. OTF may have access to the 283 CellList, by using the CoAP-YANG Model, but actually cell-specific 284 statistics are not significant to OTF, since softcells can be re- 285 allocated in time by 6top itself, based on network conditions. 287 MonitoringStatusList provides per-neighbor and slotframe statistics. 288 From it an upper layer (e.g., OTF) can get per bundle overview of 289 scheduling and its performance. Such list contains information about 290 the number of hard and soft cells reserved to a given node with a 291 specific neighbor, and the QoS (that can be expressed in form of 292 different metrics: PDR, ETX, RSSI, LQI) on the actual bandwidth, and 293 the over-provisioned bandwidth (which includes the over-provisioned 294 cells). 6top can use such list to operate 6top Monitoring Functions, 295 such as re-allocating cells (by changing their slotOffset and/or 296 channelOffset) when it finds out that the link quality of some 297 softcell is much lower than average. Unlike 6top, OTF does not 298 operate any re-allocation of cells. In fact, OTF can ask for more/ 299 less bandwidth, but cannot move any cell within the schedule. Thus, 300 the 6top Monitoring function is useful to OTF, because it can provide 301 better cells for a given bandwidth requirement, specified by OTF. 302 For instance, OTF may require some additional bandwidth (e.g. 2 cells 303 in a specific slotframe) with PDR = 75%; then, 6top will reserve 3 304 slots in the slotframe to meet the bandwidth requirement. In 305 addition, when the link quality drops to 50%, 6top will reserve 4 306 slots to keep meeting the bandwidth requirement. Given that OTF 307 operates on the global bandwidth between two neighbor nodes, it does 308 not need to be informed from 6top about cells' re-allocation. 310 NeighborList provides per-neighbor statistics. From it, an upper 311 layer can understand the connectivity of a pair of nodes, e.g. based 312 on the queue length increase, OTF may ask 6top to add some cells, in 313 order to increase the available bandwidth. 315 QueueList provides per-Queue statistics. From it, an upper layer can 316 know the traffic load. OTF, based on such queue statistics (e.g., 317 average length of the queue, average age of the packet in queue, 318 etc.) may trigger a 6top CREATE.softcell (DELETE.softcell) command 319 for increasing (decreasing) the bandwidth and be able to better serve 320 the packets in the queue. 322 6. Events triggering algorithms in OTF 324 The Algorithms running within OTF MUST be event-oriented. As a 325 consequence, OTF requires to connect the algorithms with external 326 events to trigger their execution. The algorithm also generates one 327 or more events when it is executed, such as a new soft cell 328 allocation. Both type of events, the one which triggers the 329 algorithm and the ones which are generated by the execution of the 330 algorithm are called OTF events. We define the following elements: 332 A set of parameters P(E): parameters used to define E and its 333 triggering conditions; 335 a set of triggering variables V(E): variables that can trigger the 336 event; 338 a set of triggering conditions C(E): conditions to satisfy on the 339 variables V(E) to trigger E; 341 a set of process handlers H(E): handlers required to respond and 342 process the triggering conditions C(E). 344 To illustrate how P(E), V(E), C(E) and H(E) can be used to define a 345 real event, the allocation policy described in Sec. 2 is considered 346 hereby. 348 P(E) consists of the OTFTHRESHLOW and OTFTHRESHHIGH parameters (P1 349 and P2, respectively); 351 V(E) consists of the REQUIREDCELLS and SCHEDULEDCELLS parameters 352 (V1 and V2, respectively); 354 C(E) consists of the following conditions: 356 C1: V1 > V2+P2 358 C2: V1 <=V2-P1 360 H(E) consists of the following handlers (one handler for each 361 triggering condition) 363 H1(C1): OTF asks 6top to add one or more soft cells to the L3 364 best effort bundle. 366 H2(C2): OTF asks 6top to delete one or more soft cells from the 367 L3 best effort bundle. 369 7. Bandwidth Estimation Algorithms 371 OTF supports different bandwidth estimation algorithms that can be 372 used by a node in a 6TiSCH network for checking the statistics 373 provided by 6top and the actual bandwidth usage. By doing so, one 374 can adapt (increase or decrease) the number of scheduled soft cells 375 for a given pair of neighbors (e.g., parent node and its child), 376 according to their specific requirements. OTF supports several 377 bandwidth estimation algorithms numbered 0 to 255 in the OTF 378 implementation. The first algorithm (0) is reserved to the default 379 algorithm that is described below. By using SET and GET commands, 380 one can set the specific algorithm to be used, and get information 381 about which algorithm is implemented. 383 The steps of the default bandwidth estimation algorithm, running over 384 a parent node, are listed hereafter: 386 Step 1: Collect the bandwidth requests from child nodes (incoming 387 bundle soft cell allocation from 6top-to-6top negotiation). 389 Step 2: Collect the node bandwidth requirement from the application 390 (self/local traffic, from the application soft cell pending 391 requests). 393 Step 3: Collect the current outgoing scheduled bandwidth (outgoing 394 traffic). 396 Step 4: If (outgoing < incoming + self) then SCHEDULE soft cells to 397 satisfy bandwidth requirements. 399 Step 5: If (outgoing > incoming + self) then DELETE the soft cells 400 that are not used. 402 Step 6: Return to step 1. 404 The default bandwidth estimation algorithm introduced in this 405 document adopts a reactive allocation policy, i.e., it uses 406 OTFTHRESHLOW = 0 and OTFTHRESHHIGH = 0; the histeresys is not enabled 407 and the allocation/deallocation follows directly. The algorithm is 408 triggered either by Step 4 or Step 5. 410 8. OTF external CoAP interface 412 In order to select the current OTF algorithm and provide functional 413 parameters from outside OTF, this module uses CoAP with YANG as the 414 data model. The algorithm number and the parameters MUST be invoked 415 in different CoAP calls. 417 The path to select the algorithm is '6t/e/otf/alg' with A as the 418 algorithm number. 420 +------------------------------------------+ 421 Header | POST | 422 +------------------------------------------+ 423 Uri-Path| /6t/e/otf/alg | 424 +------------------------------------------+ 425 Options | CBOR( {AlgNo: 123} ) | 426 +------------------------------------------+ 428 Figure 2: Algorithm number POST message 430 To obtain the current algorithm number: 432 +------------------------------------------+ 433 Header | GET | 434 +------------------------------------------+ 435 Uri-Path| /6t/e/otf/alg | 436 +------------------------------------------+ 437 Options | Accept: application/cbor | 438 +------------------------------------------+ 440 Figure 3: Algorithm number GET message 442 An example is: 'coap://[aaaa::1]/6t/e/otf/alg' 444 The current algorithm parameter path is '6t/e/otf/alg/par'. 446 +------------------------------------------+ 447 Header | POST | 448 +------------------------------------------+ 449 Uri-Path| /6t/e/otf/alg/par | 450 +------------------------------------------+ 451 Options | CBOR( {Par: 0x1234} ) | 452 +------------------------------------------+ 454 Figure 4: Algorithm number POST message 456 An example follows: 'coap://[aaaa::1]/6t/e/otf/alg/par' 458 9. Acknowledgments 460 Special thanks to Prof. Kris Pister for his valuable contribution in 461 designing the default Bandwidth Estimation Algorithm, and to Prof. 462 Qin Wang for her support in defining the interaction between OTF and 463 6top sublayer. 465 Thanks to the Fondecyt 1121475 Project, to INRIA Chile "Network 466 Design" group and to the IoT6 European Project (STREP) of the 7th 467 Framework Program (Grant 288445). 469 10. References 471 10.1. Informative References 473 [I-D.ietf-6tisch-terminology] 474 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 475 "Terminology in IPv6 over the TSCH mode of IEEE 476 802.15.4e", draft-ietf-6tisch-terminology-04 (work in 477 progress), March 2015. 479 [I-D.ietf-6tisch-architecture] 480 Thubert, P., "An Architecture for IPv6 over the TSCH mode 481 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 482 in progress), May 2015. 484 [RFC7554] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE 485 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 486 Internet of Things (IoT): Problem Statement", RFC 7554, 487 May 2015. 489 [I-D.wang-6tisch-6top] 490 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 491 Operation Sublayer (6top)", draft-wang-6tisch-6top-00 492 (work in progress), October 2013. 494 10.2. External Informative References 496 [IEEE802154e] 497 IEEE standard for Information Technology, "IEEE std. 498 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 499 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 500 2012. 502 [IEEE802154] 503 IEEE standard for Information Technology, "IEEE std. 504 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 505 and Physical Layer (PHY) Specifications for Low-Rate 506 Wireless Personal Area Networks", June 2011. 508 Authors' Addresses 510 Diego Dujovne (editor) 511 Universidad Diego Portales 512 Escuela de Informatica y Telecomunicaciones 513 Av. Ejercito 441 514 Santiago, Region Metropolitana 515 Chile 517 Phone: +56 (2) 676-8121 518 Email: diego.dujovne@mail.udp.cl 520 Luigi Alfredo Grieco 521 Politecnico di Bari 522 Department of Electrical and Information Engineering 523 Via Orabona 4 524 Bari 70125 525 Italy 527 Phone: 00390805963911 528 Email: a.grieco@poliba.it 530 Maria Rita Palattella 531 University of Luxembourg 532 Interdisciplinary Centre for Security, Reliability and Trust 533 4, rue Alphonse Weicker 534 Luxembourg L-2721 535 LUXEMBOURG 537 Phone: (+352) 46 66 44 5841 538 Email: maria-rita.palattella@uni.lu 539 Nicola Accettura 540 University of California Berkeley 541 Berkeley Sensor & Actuator Center 542 490 Cory Hall 543 Berkeley, California 94720 544 USA 546 Email: nicola.accettura@eecs.berkeley.edu