idnits 2.17.1 draft-dujovne-6tisch-on-the-fly-05.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 156: '... computed is out of the scope. It MAY...' RFC 2119 keyword, line 325: '...nning within OTF MUST be event-oriente...' RFC 2119 keyword, line 411: '...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 (March 7, 2015) is 3331 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 495, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 501, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-03 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-05 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-05 Summary: 3 errors (**), 0 flaws (~~), 6 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: September 8, 2015 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 University of California Berkeley 10 March 7, 2015 12 6TiSCH On-the-Fly Scheduling 13 draft-dujovne-6tisch-on-the-fly-05 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 September 8, 2015. 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 . . . . . . . . . . . . 11 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 [I-D.ietf-6tisch-tsch]. 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 when to add/delete softcells is out of scope. For example, 113 OTF might decide to add a cell if some queue of outbound frames is 114 overflowing. Similarly, OTF can delete cells when the queue has been 115 empty for some time. OTF only triggers 6top to add/delete the soft 116 cells, it is the responsibility of the 6top sublayer to determine the 117 exact slotOffset/channelOffset of those cells. In this document, the 118 term "cell" and "soft cell" are used interchangeably. 120 OTF is a Layer-3 Mechanism, and as such, it operates on L3 links, on 121 the best effort track, i.e. with TrackID=00, as defined in 122 [I-D.wang-6tisch-6top]. Inside an intermediate node, a track is 123 uniquely associated to a pair of bundles: one incoming bundle, and 124 one outgoing bundle. For an IP link, the two bundle are identified 125 by the same peer mac addresses. For instance (macA, macB, 126 TrackID=00) and (macB, macA, TrackID=00) will be the two bundles 127 associated to the L3 link between node A and node B. The cells on 128 the best effort track can be used for forwarding any packet in the 129 queue, regardless of the specific L2 bundle (and thus, end-to-end L2 130 track) the packet belongs to. OTF manages the global bandwidth 131 requirements between two neighbor nodes; per-track management is 132 currently out of scope. 134 OTF is prone to schedule collisions. Nodes might not be aware of the 135 cells allocated by other pairs of nodes. A schedule collision occurs 136 when the same cell is allocated by different pairs in the same 137 interference space. The probability of having allocation collision 138 may be kept low by grouping cells into chunks (see 139 [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture] for 140 more details). The use of chunks is outside the scope of this 141 current version of the OTF draft. 143 The "allocation policy" is the algorithm used by OTF to decide when 144 to increase/decrease the bandwidth allocated between two neighbor 145 nodes in order to satisfy the traffic requirements. These 146 requirements can be expressed in terms of throughput, latency or 147 other constraints. 149 This document introduces the following parameters for describing the 150 behavior of the OTF allocation policy: 152 SCHEDULEDCELLS: The amount of soft cells scheduled in a bundle on 153 the best effort track between two neighbors. 155 REQUIREDCELLS: Number of cells requested by OTF to 6top, a non- 156 negative value. How this is computed is out of the scope. It MAY 157 be an instantaneous request, or a value averaged on several 158 measurements. 160 OTFTHRESHLOW: Threshold parameter introducing cell over-provisioning 161 in the allocation policy. It is a non-negative value expressed as 162 number of cells. Which value to use is application-specific and 163 out of scope. 165 OTFTHRESHHIGH: Threshold parameter introducing cell under- 166 provisioning in the allocation policy. It is a non-negative value 167 expressed as number of cells. Which value to use is application- 168 specific and out of scope. 170 The OTF allocation policy compares the number of required cells 171 against the number of scheduled ones, using the OTF threshold for 172 bounding the signaling overhead due to negotiations of new cells. In 173 details: 175 SCHEDULEDCELLS 176 <-------------------------------------> 177 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 178 | | | | | | | | | | | | | | | 179 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 180 |<----------------->|<------------->| 181 | OTFTHRESHLOW | OTFTHRESHHIGH | 182 | | | 183 REQUIREDCELLS | | | 184 +---+---+---+ | | | ADD 185 | | | | | | | SOME 186 +---+---+---+ | | | CELLS 187 | | | 188 REQUIREDCELLS | | 189 +---+---+---+---+---+---+---+ | | DO 190 | | | | | | | | | | NOTHING 191 +---+---+---+---+---+---+---+ | | 192 | | | 193 REQUIREDCELLS | | 194 +---+---+---+---+---+---+---+---+---+---+---+ | DO 195 | | | | | | | | | | | | | NOTHING 196 +---+---+---+---+---+---+---+---+---+---+---+ | 197 | | | 198 | REQUIREDCELLS | | 199 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ REMOVE 200 | | | | | | | | | | | | | | | | SOME 201 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ CELLS 203 Figure 1: Relation among the OTF parameters used for triggering add/ 204 remove 6top commands 206 1. If REQUIREDCELLS is greater than (SCHEDULEDCELLS + 207 OTFTHRESHHIGH), OTF asks 6top to add one or more soft cells to 208 the bundle on the best effort track. 210 2. If REQUIREDCELLS is greater or equal than (SCHEDULEDCELLS - 211 OTFTHRESHLOW), and it is lower than or equal to (SCHEDULEDCELLS + 212 OTFTHRESHHIGH), OTF does not perform any bundle resizing, since 213 the scheduled cells are sufficient for managing the current 214 traffic conditions. 216 3. If REQUIREDCELLS is lower than (SCHEDULEDCELLS - OTFTHRESHLOW), 217 OTF asks 6top to delete one or more soft cells from the bundle on 218 the best-effort track. 220 When both OTFTHRESHLOW and OTFTHRESHHIGH equal 0, any discrepancy 221 between REQUIREDCELLS and SCHEDULEDCELLS triggers a 6top negotiation 222 of soft cells. Other values for the thresholds values reduce the 223 number of triggered 6top negotiations. 225 The number of soft cells to be scheduled/deleted for bundle resizing 226 is out of the scope of this document and implementation-dependant. 228 3. Allocation method 230 Beyond the allocation policies that describe the approach used by OTF 231 for fulfilling the node bandwidth requests, the OTF framework also 232 includes the Allocation Method that specify how OTF issues commands 233 to the 6top sublayer. As specified in [I-D.wang-6tisch-6top], 6top 234 provides a set of commands that allows OTF to allocate/delete soft 235 cells. Such commands are used by the OTF soft cell allocation 236 method. 238 With the soft cell allocation method, OTF can ask 6top to reserve one 239 (or N > 1) soft cell(s) on the best effort L3 boundle, between two 240 neighbor nodes. The 6top layer allocates and maintains these cells. 241 If a L3 bundle with TrackID=00 was already reserved between the same 242 pair of neighbors, 6top translates the OTF request into a bundle 243 resize request. The newly allocated cell increases the size of the 244 already existing bundle. Similarly, when OTF realizes there is a 245 reduction of traffic exchanged between the two neighbors, it may asks 246 6top to delete a softcell (or N > 1) from the best effort track, i.e. 247 to decrease the size of the best effort L3 bundle. If no bundle with 248 TrackID=00 exists when 6top receives the OTF request, then the 6top 249 softcell create command generates a new bundle of size 1. 251 4. Cell and Bundle Reservation/Deletion 253 In order to reserve/delete softcells, OTF interacts with 6top 254 sublayer. To this aim OTF uses the following set of commands offered 255 by 6top: CREATE.softcell, and DELETE.softcell. When creating 256 (deleting) a softcell, OTF specifies the track the cell belongs to 257 (i.e., best effort track, TrackID=00), but not its slotOffset nor the 258 channelOffset. If at least one cell on the best effort L3 bundle 259 already exists, the CREATE.softcell and DELETE.softcell, translate 260 into INCREASE and DECREASE the bundle size, respectively. 6top is 261 responsible for picking the specific cell to be added/deleted within 262 the bundle. Before being able to do so, source and destination nodes 263 go through a cell negotiation process. This process is out of scope 264 of 6top and OTF. By using the CREATE.softcell command, OTF can ask 265 6top to add multiple softcells on the best effort L3 bundle. 266 Following OTF request, 6top either (i) creates a new bundle, if no 267 cells were reserved already on the best effort track, or (ii) 268 increases the L3 bundle size of the already existing best-effort 269 bundle. By using the DELETE.softcell command, OTF can ask 6top to 270 delete cells from the best effort bundle. 272 OTF provides a policy for 6top to generate CREATE/DELETE.softcells 273 commands, policy that is out of 6top scope [I-D.wang-6tisch-6top]. 274 Such policy is not the only one that can be used by 6top. Others may 275 be defined in the future. 277 5. Getting statistics and other information about cells through 6top 279 Statistics are kept in 4 data structures of 6top MIB: CellList, 280 MonitoringStatusList, NeighborList, and QueueList. 282 CellList provides per-cell statistics. From this list, an upper 283 layer can get per-bundle statistics. OTF may have access to the 284 CellList, by using the CoAP-YANG Model, but actually cell-specific 285 statistics are not significant to OTF, since softcells can be re- 286 allocated in time by 6top itself, based on network conditions. 288 MonitoringStatusList provides per-neighbor and slotframe statistics. 289 From it an upper layer (e.g., OTF) can get per bundle overview of 290 scheduling and its performance. Such list contains information about 291 the number of hard and soft cells reserved to a given node with a 292 specific neighbor, and the QoS (that can be expressed in form of 293 different metrics: PDR, ETX, RSSI, LQI) on the actual bandwidth, and 294 the over-provisioned bandwidth (which includes the over-provisioned 295 cells). 6top can use such list to operate 6top Monitoring Functions, 296 such as re-allocating cells (by changing their slotOffset and/or 297 channelOffset) when it finds out that the link quality of some 298 softcell is much lower than average. Unlike 6top, OTF does not 299 operate any re-allocation of cells. In fact, OTF can ask for more/ 300 less bandwidth, but cannot move any cell within the schedule. Thus, 301 the 6top Monitoring function is useful to OTF, because it can provide 302 better cells for a given bandwidth requirement, specified by OTF. 303 For instance, OTF may require some additional bandwidth (e.g. 2 cells 304 in a specific slotframe) with PDR = 75%; then, 6top will reserve 3 305 slots in the slotframe to meet the bandwidth requirement. In 306 addition, when the link quality drops to 50%, 6top will reserve 4 307 slots to keep meeting the bandwidth requirement. Given that OTF 308 operates on the global bandwidth between two neighbor nodes, it does 309 not need to be informed from 6top about cells' re-allocation. 311 NeighborList provides per-neighbor statistics. From it, an upper 312 layer can understand the connectivity of a pair of nodes, e.g. based 313 on the queue length increase, OTF may ask 6top to add some cells, in 314 order to increase the available bandwidth. 316 QueueList provides per-Queue statistics. From it, an upper layer can 317 know the traffic load. OTF, based on such queue statistics (e.g., 318 average length of the queue, average age of the packet in queue, 319 etc.) may trigger a 6top CREATE.softcell (DELETE.softcell) command 320 for increasing (decreasing) the bandwidth and be able to better serve 321 the packets in the queue. 323 6. Events triggering algorithms in OTF 325 The Algorithms running within OTF MUST be event-oriented. As a 326 consequence, OTF requires to connect the algorithms with external 327 events to trigger their execution. The algorithm also generates one 328 or more events when it is executed, such as a new soft cell 329 allocation. Both type of events, the one which triggers the 330 algorithm and the ones which are generated by the execution of the 331 algorithm are called OTF events. 333 A set of parameters P(E): parameters used to define E and its 334 triggering conditions; 336 a set of triggering variables V(E): variables that can trigger the 337 event; 339 a set of triggering conditions C(E): conditions to satisfy on the 340 variables V(E) to trigger E; 342 a set of process handlers H(E): handlers required to respond and 343 process the triggering conditions C(E). 345 To illustrate how P(E), V(E), C(E) and H(E) can be used to define a 346 real event, the allocation policy described in Sec. 2 is considered 347 hereby. 349 P(E) consists of the OTFTHRESHLOW and OTFTHRESHHIGH parameters (P1 350 and P2, respectively); 352 V(E) consists of the REQUIREDCELLS and SCHEDULEDCELLS parameters 353 (V1 and V2, respectively); 355 C(E) consists of the following conditions: 357 C1: V1 > V2+P2 359 C2: V1 <=V2-P1 361 H(E) consists of the following handlers (one handler for each 362 triggering condition) 364 H1(C1): OTF asks 6top to add one or more soft cells to the L3 365 best effort bundle. 367 H2(C2): OTF asks 6top to delete one or more soft cells from the 368 L3 best effort bundle. 370 7. Bandwidth Estimation Algorithms 372 OTF supports different bandwidth estimation algorithms that can be 373 used by a node in a 6TiSCH network for checking the statistics 374 provided by 6top and the actual bandwidth usage. By doing so, one 375 can adapt (increase or decrease) the number of scheduled soft cells 376 for a given pair of neighbors (e.g., parent node and its child), 377 according to their specific requirements. OTF supports several 378 bandwidth estimation algorithms numbered 0 to 255 in the OTF 379 implementation. The first algorithm (0) is reserved to the default 380 algorithm that is described below. By using SET and GET commands, 381 one can set the specific algorithm to be used, and get information 382 about which algorithm is implemented. 384 Default bandwidth estimation algorithm, running over a parent node: 386 Step 1: Collect the bandwidth requests from child nodes (incoming 387 traffic). 389 Step 2: Collect the node bandwidth requirement from the application 390 (self/local traffic). 392 Step 3: Collect the current outgoing scheduled bandwidth (outgoing 393 traffic). 395 Step 4: If (outgoing < incoming + self) then SCHEDULE soft cells to 396 satisfy bandwidth requirements. 398 Step 5: If (outgoing > incoming + self) then DELETE the soft cells 399 that are not used. 401 Step 6: Return to step 1. 403 The default bandwidth estimation algorithm introduced in this 404 document adopts a reactive allocation policy, i.e., it uses 405 OTFTHRESHLOW = 0 and OTFTHRESHHIGH = 0. 407 8. OTF external CoAP interface 409 In order to select the current OTF algorithm and provide functional 410 parameters from outside OTF, this module uses CoAP with YANG as the 411 data model. The algorithm number and the parameters MUST be invoked 412 in different CoAP calls. 414 The path to select the algorithm is '6t/e/otf/alg' with A as the 415 algorithm number. 417 +------------------------------------------+ 418 Header | POST | 419 +------------------------------------------+ 420 Uri-Path| /6t/e/otf/alg | 421 +------------------------------------------+ 422 Options | CBOR( {AlgNo: 123} ) | 423 +------------------------------------------+ 425 Figure 2: Algorithm number POST message 427 To obtain the current algorithm number: 429 +------------------------------------------+ 430 Header | GET | 431 +------------------------------------------+ 432 Uri-Path| /6t/e/otf/alg | 433 +------------------------------------------+ 434 Options | Accept: application/cbor | 435 +------------------------------------------+ 437 Figure 3: Algorithm number GET message 439 An example is: 'coap://[aaaa::1]/6t/e/otf/alg' 441 The current algorithm parameter path is '6t/e/otf/alg/par'. 443 +------------------------------------------+ 444 Header | POST | 445 +------------------------------------------+ 446 Uri-Path| /6t/e/otf/alg/par | 447 +------------------------------------------+ 448 Options | CBOR( {Par: 0x1234} ) | 449 +------------------------------------------+ 451 Figure 4: Algorithm number POST message 453 An example follows: 'coap://[aaaa::1]/6t/e/otf/alg/par' 455 9. Acknowledgments 457 Special thanks to Prof. Kris Pister for his valuable contribution in 458 designing the default Bandwidth Estimation Algorithm, and to Prof. 459 Qin Wang for her support in defining the interaction between OTF and 460 6top sublayer. 462 Thanks to the Fondecyt 1121475 Project, to INRIA Chile "Network 463 Design" group and to the IoT6 European Project (STREP) of the 7th 464 Framework Program (Grant 288445). 466 10. References 468 10.1. Informative References 470 [I-D.ietf-6tisch-terminology] 471 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 472 "Terminology in IPv6 over the TSCH mode of IEEE 473 802.15.4e", draft-ietf-6tisch-terminology-03 (work in 474 progress), January 2015. 476 [I-D.ietf-6tisch-architecture] 477 Thubert, P., Watteyne, T., Struik, R., and M. Richardson, 478 "An Architecture for IPv6 over the TSCH mode of IEEE 479 802.15.4e", draft-ietf-6tisch-architecture-05 (work in 480 progress), January 2015. 482 [I-D.ietf-6tisch-tsch] 483 Watteyne, T., Palattella, M., and L. Grieco, "Using 484 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 485 Statement and Goals", draft-ietf-6tisch-tsch-05 (work in 486 progress), January 2015. 488 [I-D.wang-6tisch-6top] 489 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 490 Operation Sublayer (6top)", draft-wang-6tisch-6top-00 491 (work in progress), October 2013. 493 10.2. External Informative References 495 [IEEE802154e] 496 IEEE standard for Information Technology, "IEEE std. 497 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 498 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 499 2012. 501 [IEEE802154] 502 IEEE standard for Information Technology, "IEEE std. 503 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 504 and Physical Layer (PHY) Specifications for Low-Rate 505 Wireless Personal Area Networks", June 2011. 507 Authors' Addresses 509 Diego Dujovne (editor) 510 Universidad Diego Portales 511 Escuela de Informatica y Telecomunicaciones 512 Av. Ejercito 441 513 Santiago, Region Metropolitana 514 Chile 516 Phone: +56 (2) 676-8121 517 Email: diego.dujovne@mail.udp.cl 519 Luigi Alfredo Grieco 520 Politecnico di Bari 521 Department of Electrical and Information Engineering 522 Via Orabona 4 523 Bari 70125 524 Italy 526 Phone: 00390805963911 527 Email: a.grieco@poliba.it 529 Maria Rita Palattella 530 University of Luxembourg 531 Interdisciplinary Centre for Security, Reliability and Trust 532 4, rue Alphonse Weicker 533 Luxembourg L-2721 534 LUXEMBOURG 536 Phone: (+352) 46 66 44 5841 537 Email: maria-rita.palattella@uni.lu 538 Nicola Accettura 539 University of California Berkeley 540 Berkeley Sensor & Actuator Center 541 490 Cory Hall 542 Berkeley, California 94720 543 USA 545 Email: nicola.accettura@eecs.berkeley.edu