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