UNIVERSITÀ DI PISA Facoltà di Ingegneria. 6LoWPAN conform ITS-Station for non safety-critical services and applications

Transcription

1 UNIVERSITÀ DI PISA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Curriculum Networking e Multimedia 6LoWPAN conform ITS-Station for non safety-critical services and applications Candidato: Giovanni Pellerano Relatori: Prof. Paolo Ancilotti Dr. Paolo Pagano Dr. Matteo Petracca Anno accademico

2

3 Alla mia famiglia

4

5 Abstract The term Intelligent Transportation System (ITSs) refers to efforts to collect, store and provide real-time traffic informations by applying advanced electronics, information and telecommunication technologies into roads, vehicles and goods. ITSs make it possible to imagine a future in which cars will be able to foresee and avoid collisions, navigate the quickest route to their destination, making use of up-to-the-minute traffic reports, identify the nearest available parking slot and minimize their carbon emissions. ITSs can significantly contribute to a cleaner, safer and more efficient transport system; consequently, ITSs have become the focus of several policy and legislative initiatives. Responding to the increasing interest to connect wireless sensor networks (WSNs) to the Internet, the IETF has proposed a standard that enable IPv6-based WSNs built atop IEEE (6LoWPAN). In this Master Thesis we investigate a new set of standards - Communications Access for Land Mobiles (CALM) - for vehicular environments, we analyze the 6LoWPAN networking stack capabilities and we evaluates its applicability as a basis for large scale low-cost roadside ITS-Station networks aimed at delivering non safety-critical services and applications. Following a practical approach and basing this research on the Internet of Things (IoT) paradigm, a working CoAP-based prototype of the proposed architecture is presented, a Wide Area Network testbed is instantiated and main results discussed; the prototype has been built porting the Contiki OS to a microcontroller-based board, specifically designed for ITS applications. Keywords: Intelligent Transportation Systems, IoT, 6LoWPAN, CoAP

6

7 Acknowledgment First of all I would like to thank Prof. Paolo Ancilotti for giving me the opportunity to write this thesis in collaboration with Scuola Superiore Sant Anna. In particular I would like to express my sincere gratitude to my direct supervisor Dr. Paolo Pagano for his constant suggestions and support during the work at CNIT National Laboratory of Photonic Networks. Finally, I thank all the guys composing the Real-Time Networks Area of TeCIP Institute for continuous assistance during the development of the architecture prototype.

8

9 Table of Contents List of Figures List of Tables List of Acronyms vii ix xi 1 Introduction Intelligent Transportation Systems Short Problem Statement Scientific Contribution Structure of This Thesis Background ITSs Standards Internet of Things IEEE Physical Layer Data Link Layer Node Types and Network Topologies IPv Addressing Model UDP LoWPAN Adaptation Layer Stateless Address Autoconfiguration IPv6 Header compression IPv6 Packet Fragmentation

10 2.6 RPL CoAP CoAP Messages Blockwise Transfers Resource Observe Pattern Resource Directory LoWPAN ITS-S Design Concepts Behind CALM Standardization CALM ITS-S Reference Architecture CALM ITS-S Sub-Systems CALM Complex ITS-S Reference Architecture CALM ITS-S Roadside Network LoWPAN ITS-S Specification Proposal An envisioned Use Case and its Requirements Example: Intelligent Traffic Monitoring LoWPAN ITS-S Implementation Hardware and Software Adopted Hardware Components Adopted Software Components Porting Contiki over SEED-EYE Board ITS-S Network Stack Implemented Access Layer Implemented Network & Trasport Layer Implemented ITS-S Node Specialization ITS-S Border Router ITS-S Host LoWPAN ITS-S Roadside Network Analysis and results Methodology ITS-S Roadside Network Testbed

11 5.2 The Testbed ITS-S Roadside Network Testbed ITS-S Central Station Testbed Functional Tests Performance Analysis Firmware Analysis Conclusions 67 7 Future Work 69 Appendix A 6LoWPAN ITS-S PoC 71 Bibliography 73

12

13 List of Figures 1.1 Intelligent Transportation Systems Scenario Standardization process of cooperative ITS The Internet of Things IEEE frequency bands IEEE stack IEEE PHY and MAC frame structure IEEE network topologies LoWPAN adaptation layer Examples of various 6LoWPAN header stacks RPL DODAG Examples of CoAP transactions CALM ITS-S General Architecture CALM ITS-S Complex Architecture CALM ITS-S Node Specialization CALM ITS-S Roadside Network LoWPAN ITS-S Proposed Architecture IPERMOB Testbed at the Pisa International Airport SEED-EYE hardware components Implemented and configured modules LoWPAN ITS-S Border Router prototype design AICCU software used to connect to SixXS IPv6 tunnel broker LoWAN ITS-S Host functions implemented Examples of possible ITS-S host specializations LoWAN ITS-S RoadSide Network envisioned use case vii

14 5.1 Microchip MPLAB X IDE during a software debugging session An on-line packet analysis using Wireshark LoWPAN ITS-S Roadside Network Testbed Examples of CoAP ITS-S Hosts exporting internal resources RTT and PLOSS according to ICMP payload size Cross-Layer design possibilities offered by CALM architecture 70

15 List of Tables 2.1 IEEE main frequencies and data rates IEEE frame types Address types of IPv6 according to RFC Comparison between typical IPv6 and IEEE networks Comparison between CALM and OSI models Firmware size comparison of the presented implementation. 65 ix

16

17 List of Acronyms 6LoWPAN IPv6 over Low power Wireless Personal Area Networks CALM Communications Access for Land Mobiles CoAP Constrained Application Protocol IoT Internet of Things IPv6 Internet Protocol version 6 ITS Intelligent Transportation System ITS-S ITS-Station LLN Low power and Lossy Network LR-WPAN Low-Rate Wireless Personal Area Network M2M machine-to-machine MP2P multipoint-to-point communication MTU Maximum Transfer Unit PAN Personal Area Network P2P peer-to-peer communication P2MP point-to-multipoint communication REST Representational State Transfer RPL Routing Protocol for Low-power and Lossy networks SAP Service Access Point UDP User Datagram Protocol VANET Vehicular Ad-hoc Network WPAN Wireless Personal Area Network WSN Wireless Sensor Network xi

18

19 1 Introduction 1.1 Intelligent Transportation Systems Figure 1.1: Intelligent Transportation Systems Scenario The term Intelligent Transportation System (ITS) refers to efforts to collect, store and provide real-time traffic informations by applying advanced electronics, information and telecommunication technologies into roads, vehicles and goods. ITS make it possible to imagine a future in which cars will be able to foresee and avoid collisions, navigate the quickest route to their destination, making use of up-to-the-minute traffic reports, identify the nearest available parking slot and minimize their carbon emissions. ITSs vary in technologies applied, from basic management systems such as car navigation; traffic signal control systems; variable message signs; automatic number plate recognition and speed cameras; and to more advanced applications that integrate live data and feedback from am high number of sources to implement traffic congestion and vehicles collision avoidance.

20 2 Chapter 1 ITSs can significantly contribute to a cleaner, safer and more efficient transport system; consequently, ITSs have become the focus of a number of policy and legislative initiatives. 1.2 Short Problem Statement Currently, ITSs depend on Commercial Off-The-Shelf (COTS) components and on traditional monitoring sensors including inductive loops, video cameras, ultrasonic sensors, radars. Regardless of sensors used, ITSs technologies require costly infrastructures to be in place to support the deployment; furthermore most existing sensor network systems require custom gateways and tools. It follows that these systems result generally power-hungry, expensive to install, maintain and repair. These characteristics subvert the scalability of ITSs and is one of the main reasons why ITS do not usually cover an entire city but tend to cover only the major arteries of the city s roadways preventing ITSs to obtain their major objectives, e.g., effective traffic monitoring through a pervasive diffusion. This thesis examinates a set of upcoming telecommunication standards and evaluates the feasibility for an implementation of low-cost WSN-based roadside networks; In particular a specific implementation of the 6LoWPAN communication stack [1] is proposed as an extension of the present CALM ITS-Station (CALM ITS-S) architecture. Following the technological trend of the Internet of Things (IoT), embedded devices formerly inter-operating at MAC layer in compliance with the IEEE [2] specification for WPANs, are nowadays IP-enabled thanks to the specific tailoring of IPv6 to resource constrained networks standardized by IETF in [3] and [4]. To interoperate with 6LoWPAN devices making use of the web services paradigm (thus also enabling them for M2M, at the application layer a specific adaptation of the HTTP protocol, known as CoAP [5], has been proposed. Leveraging low-cost sensor devices, it will be possible to scale the collection layer of the ITS roadside network over a large scale, as the typical

21 Introduction 3 footprint of megacities; moreover the investment cost can be affordable for developing countries willing to consider ITS to improve their transportation facilities. 1.3 Scientific Contribution The contributions of this thesis are: 6LoWPAN-ITS-S Analysis: we analyze the capabilities offered by the 6LoWPAN network stack and we evaluate its applicability as a basis for large scale low-cost roadside networks of ITS-Ss. 6LoWPAN-ITS-S Specification: we give a specification for a new 6LoWPAN ITS-S inspired by the IoT paradigm and concepts. 6LoWPAN-ITS-S Implementation: we implement a working 6LoW- PAN ITS-S prototype leveraging the most promising IoT technologies and ideas. 6LoWPAN-ITS-S Testing: we evaluate the performance of our prototype through a real WAN testbed and check the feasibility of a large scale low-cost roadside networks aimed at delivering non safetycritical services and applications. 1.4 Structure of This Thesis The remainder of this document is organized as follows: in Chapter 2 we list and discuss all enabling technologies (at different ISO/OSI stack layers) available from standards in force or in draft status; in Chapter 3 we describe the roadside segment of the CALM infrastructure as standardized by ISO TC 204 WG16 and propose a new architecture for an ITS-S based on low cost microcontrollers and implementing the 6LoWPAN IP-like stack and the CoAP suite protocols; in Chapter 4 we describe our implementation work starting from the node level and finally considering a network

22 4 Chapter 1 of systems (i.e., the 6LoWPAN ITS-S Roadside Network); in Chapter 5 we discuss the experimental tests run on a real testbed and show a set of results eligible to be extended to any specific non-safety critical ITS applications through a specialization of the observed resources; in Chapter 6 we shortly summarize the results of this thesis and in Chapter 7 we discuss the proposal for a possible future work. Implementation details are attached in Appendix A.

23 2 Background In this chapter we provide an overview of ITS standards drafted or published by Standard Development Organizations (SDOs); we also discuss IPconnected Wireless Sensor Networks (WSNs) enabling technologies such as IEEE , 6LoWPAN and CoAP. This background is needed to help to understand our solution for large scale ITS roadside networks. 2.1 ITSs Standards Figure 2.1: Standardization process of cooperative ITS ITS standardization is promoted by several bodies at the national, regional and international levels. In the following we report about those having an international and widely-considered scope and prestige. In such

24 6 Chapter 2 respect standardization activities developed by the following working committees is taken into consideration: CEN TC 278 [6], ETSI TC ITS [7] and ISO TC 204 [8] and ITU C-ITS [9]. The European ones (namely CEN TC 278 and ETSI TC ITS) play a relevant role for EU legislation [10] [11]. The scope of what is being standardized is very broad and covers more or less the complete architectural hierarchy in various usage domains. This thesis refers mainly to the ISO TC204 Working Group 16 (WG16) [12] outcomes. The group is one of the most active and is composed by more than 80 experts registered from 17 countries around the world. Although the WG16 production is publicly available for a variety of technical communication options, the general architecture and the directives for a large-scale ITS deployments are continuously updated an this field is widely felt as under development. The overall goal of WG16 activities is to achieve interoperability in data formats and transfer capabilities so systems can "talk together", seamlessly exchange information and participate to distributed systems applications; the main output of the group is a general ITS architecture and a set of specific communications standards popularly known under the label of Communications Access for Land Mobiles (CALM) [13]. CALM standards aim at organizing a common architectural framework around which communication entities called ITS-Ss are instantiated. The ITS-Ss hosted in roadside infrastructure, vehicular equipment, or central systems are expected to exchange messages making use of the ITS network infrastructure and eventually the Internet [14]. Examples of EU-funded projects that have already tested CALM Architecture include CVIS, SAFESPOT, COOPERS [15]. 2.2 Internet of Things The Internet scenario has changed; more and more embedded devices are becoming connected and all benefit from interacting with each other and sharing resources. This new context, generically referred as Internet of Things (IoT) [16], offers the possibility to develop new and innovative ap-

25 Background 7 Figure 2.2: The Internet of Things plications in several domains. IoT devices are intended to produce large data sets, possibly handled by structured virtual information systems based on clouds. The IoT paradigm will provide added-value to build high-level information by processing data leveraging the interconnections and the complementarity among devices. IoT represents the next evolution of the Internet, enhancing its ability to gather, distribute and analyze data and turning information into knowledge. Including IoT-based WSNs in ITSs scenario will open new perspectives; by applying IoT paradigm to ITSs, any object including computer appliance, sensors/actuators, and RFID tags will be able to dynamically join the ITSs network, collaborate and cooperate efficiently to fulfill different tasks. IoT-based WSNs can be deployed along a road with very little installation and maintenance costs. They can be used to constantly acquire information related to the road condition and the traffic state and, in addition, execute collaborative in-road processing for safety purposes. These properties make WSN an effective complement to Vehicular Ad-hoc Network (VANET), since they can cooperate with them in order to mitigate their limitations. An important metric to be considered when deploying a network of things is the overall cost of the solution including installation and maintenance; this results important especially when the building blocks are a large number of wireless inexpensive products. To this aim, over the past few years, the research community has focused the attention on specific protocols suited for embedded devices that are usually constrained in terms of com-

26 8 Chapter 2 puting power, memory, and network interfaces. Main results of this research are presented and discussed in the following sections. 2.3 IEEE Wireless transmission technologies are nowadays available for a wide range of use cases and scenarios. In the field of ITS, several Wireless technologies have been promoted over the last years; currently, Cellular Based (2G/3G, WiMAX, WIFI), Dedicated Short Range Communication (CEN DSRC 5.8 GHz), Vehicular Communications (WAVE/CALM-M5/IEEE p 5.9 GHz) and Infrared (CALM-IR), while Wireless Personal Area Network (WPAN) technologies are still little used in this application field. The IEEE standard developed by the IEEE Task Group within the IEEE specifies the physical layer and media access control layer for Low-Rate Wireless Personal Area Networks (LR-WPAN) providing nodeto-node frame delivery between devices within reachable distance from each other. The first version was completed in May 2003 [17] and several revisions have been already published, such as IEEE [2], IEEE a-2007 [18], IEEE c-2009 [19] and IEEE d-2009 [20]. An other important candidate for WPANs is IEEE (Bluetooth); IEEE is often preferred over Bluetooth, because it only standardizes the lower communication layers (PHY and MAC). Applications, network configuration, routing protocols and other parts are not standardized by IEEE , resulting in more freedom in the usage of the most appropriate communication modules (possibly developed or integrated by industries). In IEEE communications, the 2.45 Ghz ISM band is used so that it is worldwide permitted to perform R&D using a public license-free communication channel. The protocol was designed to support low power usage and low cost transceivers, trying to minimize the sources of Inter-Technology Interference caused by WSN nodes. The combination of these reasons is the determining factor for the selection of IEEE as the wireless technology of choice for further investigations in this thesis.

27 Background Physical Layer The PHY layer defines the physical and electrical characteristics of the network, for example, specifying the receiver sensitivity and transmitting output (in order to conform to national regulations) power. The physical layer (PHY) provides the data transmission service, as well as the interface to the physical layer management entity, which offers access to every layer management function and maintains a database of information on related Personal Area Network (PAN). The PHY data service enables the transmission and reception of PHY protocol data units (PPDU) across the physical radio channel. The features of the PHY are activation and deactivation of the radio transceiver, energy detection (ED), link quality indication (LQI), channel selection, clear channel assessment (CCA) and transmitting as well as receiving packets across the physical medium. In Figure 2.3: IEEE frequency bands Frequency Channel Region Data Rate (Mhz) (kbit/s) EUROPE USA GLOBAL 250 Table 2.1: IEEE main frequencies and data rates the original version [17] of the standard two physical layers based on Direct Sequence Spread Spectrum (DSSS) techniques are specified: one working in the 868/915 MHz bands with transfer rates of 20 and 40 kbit/s, and one

28 10 Chapter 2 in the 2450 MHz band with a rate of 250 kbit/s. The 2006 [2] revision improves the maximum data rates of the 868/915 MHz bands, bringing them up to support 100 and 250 kbit/s as well. Moreover, it goes on to define four physical layers depending on the modulation method used. Three of them preserve the DSSS approach: in the 868/915 MHz bands, using either binary or offset quadrature phase shift keying (BPSK) (the second of which is optional); in the 2450 MHz band, using the latter. An alternative, optional 868/915 MHz layer is defined using a combination of binary keying and amplitude shift keying (QPSK) (thus based on parallel, not sequential spread spectrum, PSSS). Dynamic switching between supported 868/915 MHz PHYs is possible. Beyond these three bands, the IEEE c study group is considering the newly opened MHz, MHz, and MHz bands in China (O-QPSK or MPSK), while the IEEE Task Group 4d is defining an amendment to the existing standard IEEE to support the new 950 MHz-956 MHz band in Japan (GFSK or BPSK). First standard amendments by these groups were released in April 2009 [19] [20]. In August 2007, IEEE a [18] was released expanding the four PHYs available in the earlier 2006 version to six, including one PHY using Direct Sequence Ultra-Wide Band (UWB) and another using Chirp Spread Spectrum (CSS). The UWB PHY is allocated frequencies in three ranges: below 1 GHz, between 3 and 5 GHz, and between 6 and 10 GHz. The CSS PHY is allocated spectrum in the 2450 MHz ISM band Data Link Layer Like all the others IEEE 802 protocols, the Data Link layer (DLL) of IEEE (Figure 2.4) is split into two sublayers; the logical link (LLC) and the media access control (MAC) sublayer. The LLC is standardized in IEEE and is common among the IEEE 802 standards while the MAC sublayer is specific in respect to physical implementation. The IEEE MAC provides services to an IEEE type I LLC through the service specific convergence sublayer (SSCS), or a proprietary LLC can

29 Background 11 Figure 2.4: IEEE stack access the MAC services directly without going through the SSCS. The SSCS ensures compatibility between different LLC sublayers and allows the MAC to be accessed through a single set of access points. The MAC sublayer enables the transmission of MAC frames through the use of the physical channel. Besides the data service, it offers a management interface and itself manages access to the physical channel and network beaconing. It also controls frame validation, guarantees time slots and handles node associations. Finally, it offers hook points for secure services. The MAC sublayer provides two services to higher layers that can be accessed through two service access points (SAPs). The MAC data service is accessed through the MAC common part sublayer (MCPS-SAP), and the MAC management services are accessed through the MAC layer management entity (MLME-SAP). These two services provide an interface between the SSCS or another LLC and the PHY layer. MAC and PHY layers share a single packets structure Figure 2.5: the MAC protocol data unit (MPDU) consists of the MAC header

30 12 Chapter 2 Figure 2.5: IEEE PHY and MAC frame structure (MHR), MAC service data unit (MSDU) and MAC footer (MFR). The MHR consists of a 2 byte frame control field that specifies the frame type, the address format and controls the acknowledgement, 1 byte sequence number which matches the ACK frame with the previous transmission, and a variable sized address field (4-20 bytes). This allows either only the source address or both source and destination address. The payload field is variable in length but the maximum possible size of an MPDU is 127 bytes. The MFR is a frame check sequence field which is basically a 16-bit CRC code. the PHY protocol data unit (PPDU) consists of a 32-bit preamble or synchronization header, a PHY header for the packet length, and the payload itself which is also referred to as the PHY service data unit (PSDU). The synchronization header is used for acquisition of symbol and chip timing and possible coarse frequency adjustment and an 8- bit start of packet delimiter. Out of the 8 bits in the PHY header, seven are used to specify the length of the PSDU which can range from bytes. The standard follows the OSI principle for layered communication systems and defines four frame types (Table 2.2): MAC, used to used for handling all MAC (e.g., coordinate association, disassociation and synchronization between nodes;

31 Background 13 MAC DATA ACK BEACON used to used for handling all MAC used for data transmission used for confirming successful frame reception used by the coordinator to transmit beacons Table 2.2: IEEE frame types DATA, used for all data transmission; ACKNOWLEDGMENT, used for confirming successful frame reception: the receiver node sends an acknowledgement 12 symbol period (192µs) after the reception of a frame. this behavior is taken if explicitly requested by an ack bit in the MAC header data; BEACON, used by the PAN coordinator in the beacon-enabled mode for the beacon distribution Node Types and Network Topologies The IEEE standard distinguishes between two types of nodes: reduced-function devices (RFDs) and full-function devices (FFDs). FFDs typically have more resources, implement the complete protocol set and may be mains powered. This characteristics enables FDDs devices to act as a network coordinators or a network end-devices. When acting as a network coordinator, FFDs will have the ability to send beacon, offering synchronization, communication and network join services. RFDs instead can only act as end-devices and are equipped with sensors/actuators like transducers, light switches, lamps, etc. and may only interact with a single FFD at a time. Therefore, RFDs implement minimal subset of the IEEE protocol and can be implemented using minimal resources and memory capacity. An IEEE network may operate in either the Star or the peerto-peer (P2P) topology (Figure 2.6): Star: in the Star topology devices communicate through a single central PAN coordinator. While RFDs act as communication end-

32 14 Chapter 2 Figure 2.6: IEEE network topologies points only, a PAN coordinator mainly routes communication around the network. Different star networks operate independently of each other. This is achieved by using a PAN identifier which is unique within the radio range. After the PAN coordinator has chosen a PAN identifier, it can allow other devices, both FFDs and RFDs, to join the network; Peer-to-Peer: in P2P topology, the coordinator still provides management functionality, but the normal communication takes place directly between entities, without the assistance of the coordinator. A peer-to-peer network can be ad hoc, self-organizing and self-healing. Applications such as industrial control and monitoring, wireless sensor networks, asset and inventory tracking would benefit from such a topology. It also allows multiple hops to route messages from any device to any other device in the network. It can provide reliability by multipath routing. Different usage scenarios are therefore possible with these different topologies. An example of P2P topology is the Cluster Tree Network: different networks are arranged in a tree topology, whereby several networks are combined into a bigger one. This topology is often used in WSN scenarios; the advantage of this clustered structure is the increased coverage area at the cost of increased

33 Background 15 message latency. Because power consumption is a primary concern in WSNs to achieve long battery life, the energy must be drained continuously at an extremely low rate, or in small amounts at a low power duty cycle; to this end IEEE allows some devices (RFDs devices generally) to operate with both the transmitter and the receiver inactive for over 99% of the time. 2.4 IPv6 Internet Protocol Version 4 (IPv4) is a widely accepted IP and is used for any connections with the Internet. The protocol is implemented in most network components and almost any communication software is based on IPv4. IP was first defined by Vint Cerf and Robert Kahn in an IEEE journal paper entitled "A Protocol for Packet Network Interconnection" [21]. The protocol was later revised and updated up to ITS fourth version (IPv4), which is defined in RFC 791 [22], and became the first widely deployed version of IP. In December 1998, with the RFC 2460 [23], the IETF designated Internet Protocol Version 6 (IPv6) as the successor to IPv4. In contrast to IPv4 (which has 32 bits of address space), IPv6 has 128 bits of address space, pushing the theoretical limit of unique IPv6 nodes to roughly This expansion provides flexibility in allocating addresses and routing traffic and eliminates the primary need for network address translation (NAT). Other changes from IPv4 include an header format simplification, improved support for extensions and options, flow labeling capability, authentication extensions and privacy extensions. As a complete description of IPv6 would be beyond the scope of this document, only details relevant details for this dissertation are discussed. IPv6 application in ITSs is assumed to provide the following benefits: the pervasive nature of IP networks allows use of existing infrastructures and services;

34 16 Chapter 2 IP-based devices can be connected readily to other IP-based networks, without the need for intermediate entities like translation gateways or proxies; IP-based technologies already exist, are well-known, open and free, and proven to be working; Tools for diagnostics, management, and commissioning of IP networks already exist Addressing Model The addressing architecture of IPv6 is defined in RFC 1884 [24], now RFC 4291 [25]. RFC 4291 differs between several types of IPv6 address classes: Unicast: a single network interface is identified by a unicast address. (i.e. Global Unicast, Site-Local Unicast (which are now deprecated), Link-Local Unicast). Anycast: an address assigned to more than one interface. A packet sent to an anycast address is routed to the nearest interface with this address. Multicast: a multicast address identifies multiple nodes together, i.e., it is an identifier for a group of interfaces. If one sends a packet to a multicast address, the message is delivered to all interfaces identified by that address. IPv6 addresses are assigned to interfaces rather than nodes. As a unicast address refer to a single interface and an interface belongs to a single node, unicast addresses can also be used as node identifiers. A common representation of IPv6 address is xx:xx:xx:xx:xx:xx:xx:xx, where each x denotes a byte. Also it can be represented as eight group of four hexadecimal digits. An example of an IPv6 address is as following: 2001:1418:100:823c:201:0000:0000:4b4

35 Background 17 To shorten the writing and presentation of addresses, some simplifications to the notation are permitted. Any leading zeros in a group may be omitted, thus the above example becomes: 2001:1418:100:823c:201:0:0:4b4 Furthermore consecutive groups of 0 values can be replaced by two colons "::" : 2001:1418:100:823c:201::4b4 However only one "::" simplification is allowed in any address, to avoid ambiguity. To represent a prefix, the format ipv6 address/prefix length is used: ipv6 address is an IPv6 address in any of notations given above; prefix length is a decimal value specifying how many of remaining most contiguous bits of the address comprise of the prefix. For example, the following are legal representations of 32-bit prefix (hexadecimal): 2001:1337:0000:0000:0000:0000:0000:0000/32; 2001:1337:0:0:0:0:0:0/32; 2001:1337::/32. Unspecified (128 bits) ::/128 Loopback (128 bits) ::1/128 Multicast FF00::/8 Link-Local Unicast FE80::/10 Global Unicast (everything else) Table 2.3: Address types of IPv6 according to RFC 4291 A list of IPv6 address prefixes and notation is given in 2.3; the type of an address can be identified by considering its higher-order bits and, like in IPv4, in IPv6 some address have are special meaning or are reserved for a particular case; the all zeros :: address is the unspecified address, which

36 18 Chapter 2 indicates the absence of an address; the ::1 address is the loopback address. It can be used by a node to send a packet to itself. link-local addresses are for use on a single link for purposes such as automatic address configuration, neighbor discovery or when no router is present. A packet with a link-local source or destination address will not be forwarded by a router UDP The User Datagram Protocol (UDP) [26] is a state-less, unreliable, besteffort datagram transport protocol that can be used over the IPv6 protocol. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an IP network without requiring prior communications to set up special transmission channels or data paths. The delivery of datagrams is not guaranteed and they may get reordered during the transport. UDP uses a simple transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes any unreliability of the underlying network protocol to the user s program. As this is normally IP over unreliable media, there is no guarantee of delivery, ordering or duplicate protection. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram. Several UDP s attributes make it especially fitted for certain non safetycritical ITS-S applications: it is transaction-oriented, suitable for simple query-response protocols such as the or the Network Time Protocol; it provides datagrams, suitable for modeling other protocols such as in IP tunneling or Network File System; it is stateless, suitable for very large numbers of clients, such as in streaming media applications for example CCTV; the lack of retransmission delays makes it suitable for non critical real-time applications such as Voice over IP;

37 Background 19 works well in unidirectional communication, suitable for broadcast information such as infotainment messaging and road congestion alerts. Furthermore UDP is suitable for the ITS-S applications where error checking and correction is either not necessary or performed by the application itself, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time systems and safety critical applications LoWPAN The IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) working group of the IETF is concerned with the specification of mechanisms to allow IPv6 packet transmission over IEEE based networks. IETF 6LoWPAN standard [3] aims at integrating existing IP based infrastructures and sensor networks by specifying how IPv6 packets are to be transmitted over an IEEE network; the 6LoWPAN concept originated from the idea that "the Internet Protocol could and should be applied even to the smallest devices" [27] and that low-power devices with limited processing capabilities should be able to participate in the Internet of Things. RFC 4919 [1] describes an overview, assumptions, problem statement, and goals, while RFC 4944 [28] (now RFC 6282 [3]) defines the standard itself. As previusly stated the IPv6 standard defines certain requirements for the link-layers over which it is to be transported. However, the IEEE MAC layer does not fulfil these requirements in certain points. Hence, the 6LoWPAN specification defines not only the frame format for the transmission of IPv6 packets over IEEE , but also some methods to compress and decompress IPv6 packets. IPv6 packets must only be carried on data frames of IEEE , which

38 20 Chapter 2 can optionally request that they may be acknowledged. It is recommended to do so (request acknowledgments) in order to aid link-level recovery. This specification does not require that IEEE networks run in beacon enabled mode. It is however, recommended in this specification that beacons to be configured so as to assist association and disassociation events. This specification also requires both source and destination addresses to be included in the IEEE frame header. The source or destination PAN ID may also be included. The advantages from utilizing 6LoWPAN includes flattening the naming and addressing hierarchy in addition to simplifying the connectivity model. This means that gateways are not required to translate between proprietary protocols and standard IP, but they can be replaced with much simpler bridges and routers. Also the tools and knowledge of developers for commissioning, configuring, managing and debugging IP based protocols are readily established Adaptation Layer Figure 2.7: 6LoWPAN adaptation layer As previously stated, IPv6, requires the MTU to be at least 1280 Bytes [23]. In contrast, IEEE s standard packet size is 127 octets. Taking into account the maximum frame overhead of 25 octets (disabled security), 102 octets are left at the media access control layer. An optional but highly recommended security feature at the link layer poses an additional overhead. For example, 21 octets are consumed for AES-CCM-128 leaving only 81 octets for upper layers. This leaves only 81 octets available for

39 Background 21 IPv6 transport. As the IPv6 header length is 40 bytes, only 41 bytes are available for transport layers and so on. In order to meet the IPv6 minimum MTU requirements, 6LoWPAN defines a fragmentation and reassembly mechanism that allows splitting IPv6 packets at the 6LoWPAN adaptation layer into smaller fragments that can be handled by the link-layer, with this process being transparent to the Internet layer. Table 2.4 summarizes the main difference between typical IPv6 networks and networks. Sleeping static. Devices do not sleep and are always connected. Typical IPv6 Network IEEE Network Packet Size Maximum Transmission Maximum payload of a Unit (MTU): at least 1280 physical layer packet: 127 bytes. bytes. Addressing 128-bit IPv6 addresses 16-bit short or IEEE 64-bit extended MAC addresses. Bandwidth 54 Mbps (IEEE g) / Typically 250 Kbps 1000 Mbps (Ethernet) Power No constraint, most devices are connected to a power Low, most devices run on battery. network. Reliableness Connection is often almost Connection is often unreliable. Devices conserve energy by sleeping for long time. Table 2.4: Comparison between typical IPv6 and IEEE networks The 6LoWPAN format defines how IPv6 communication is carried in frames and specifies an adaptation layer based on the following key elements: Header Compression IPv6 header fields are compressed by assuming usage of common values. Header fields are elided from a packet when the adaptation layer can derive them from link-level information carried in the frame or based on simple assumptions of shared context. Fragmentation; IPv6 packets are fragmented into multiple link-level

40 22 Chapter 2 frames to accommodate the IPv6 minimum MTU requirement. Layer-two forwarding. To support layer-two forwarding of IPv6 datagrams, the adaptation layer can carry link-level addresses for the ends of an IP hop. Alternatively, the IP stack might accomplish intra- PAN routing via layer-three forwarding, in which each radio hop is an IP hop. (a) 6LoWPAN packet using only the IPv6 header compression, which has a size of only three bytes in the bestcase. (b) 6LoWPAN packet using the IPv6 header compression subheader and the fragmentation header. (c) 6LoWPAN packet using the IPv6 header compression subheader, the fragmentation header and the mesh addressing header. Figure 2.8: Examples of various 6LoWPAN header stacks Analogous to IPv6 extension headers, 6LoWPAN expresses each capability in a self-contained subheader: IPv6 datagrams transported over IEEE are prefixed by an encapsulation header stack (Figure 2.8). Each header in the stack contains a header type followed by zero or more header fields. There are four encapsulation headers defined: Mesh Addressing Header, Broadcast Header, Fragmentation Header and Dispatch Header. The first three of them are optional, whereas the last one is required. The key concept applied throughout the 6LoWPAN adaptation layer is the use of stateless or shared-context compression to elide adaptation,

41 Background 23 network, and transport layer header fields compressing all three layers down to a few bytes. Traditional IP header compression techniques are stateful and generally focus on optimizing individual flows over a highly constrained link. These methods assume that the compressor and decompressor are in direct and exclusive communication and compress both network and transport layer headers together. They optimize for long-lived flows by exploiting redundancies across packets within a flow over time, requiring the endpoints to initially send packets uncompressed. Flow-based compression techniques are poorly suited for LoWPANs. Traffic in many LoWPAN applications is driven by infrequent readings or notifications, rather than longlived flows Stateless Address Autoconfiguration 6LoWPAN also provides support for stateless address autoconfiguration, which means that a host can generate its own addresses using a combination of locally available information and information advertised by routers, without making stateful binding with routers. This represent one of the first interesting compression applied by 6LoW- PAN to IPv6 packets; 6LoWPAN defines a compression algorithm that permits to obtain a unique IPv6 address from either, the 16-bit or the 64-bit IEEE MAC addresses (using a Stateless Address Autoconfiguration defined in RFC 4862 [29]); this algorithm relies on the assumption that a PAN maps to a specific IPv6 link (as recommended by RFC3819 [30]). Even though all devices have an EUI-64 address, the 16-bit short addresses also can be used for address autoconfiguration. In this case, a pseudo 48-bit address is formed by concatenating 16 zero bits to the 16-bit PAN ID, the resulting 32 bits are concatenated with the 16-bit short address. The interface identifier is formed from this 48-bit address as defined in the "IPv6 over Ethernet" specification [31]. For example and IPv6 link-local address for an IEEE interface is formed by appending the interface identifier to the prefix FE80::/64.

42 24 Chapter IPv6 Header compression RFC 4944 defines HC1, a stateless compression scheme optimized for linklocal IPv6 communication. HC1 is identified by an encoding byte following the Compressed IPv6 dispatch header, and it operates on fields in the upper-layer headers. 6LoWPAN elides some fields by assuming commonly used values. For example, it compresses the 64-bit network prefix for both source and destination addresses to a single bit each when they carry the well-known link-local prefix. 6LoWPAN compresses the Next Header field to two bits whenever the packet uses UDP, TCP, or ICMPv6. 6LoWPAN elides other fields by exploiting cross-layer redundancy. It can derive Payload Length - which is always elided - from the frame or 6LoWPAN fragmentation header. The 64-bit interface identifier (IID) for both source and destination addresses are elided if the destination can derive them from the corresponding link-layer address in the or mesh addressing header. Finally, 6LoWPAN always elides Version by communicating via IPv6. An HC1 compression scheme may be followed by an HC2: a stateless compression techniques to reduce the overhead of UDP headers; Fully compressed, the HC1 encoding reduces the IPv6 header to three bytes, including the dispatch header. When the HC2 bit is set in the HC1 encoding, an additional 8-bits is included immediately following the HC1 encoding bits that specify how the UDP header is compressed. To effectively compress UDP ports, 6LoWPAN introduces a range of well known ports ( ). When ports fall in the well-known range, the upper 12 bits may be elided. If both ports fall within range, both Source and Destination ports are compressed down to a single byte. HC2 also allows elision of the UDP Length, as it can be derived from the IPv6 Payload Length field. The best-case compression efficiency occurs with link-local unicast communication, where HC1 and HC2 can compress a UDP/IPv6 header down to 7 bytes. The Version, Traffic Class, Flow Label, Payload Length, Next Header, and link-local prefixes for the IPv6 Source and Destination addresses are all elided. The suffix for both IPv6 source and destination

43 Background 25 addresses are derived from the IEEE header. Although H1 and H2 define a powerful stateless compression mechanism, it can only reach its maximum effectiveness in link-local packet transmissions. This approach is inefficient for most practical cases, where 6LoW- PAN devices communicate with devices external to the 6LoWPAN using routable addresses, hence the header compression mechanism defined in RFC 4944 has been recently updated by RFC6282 [3] were IPC, a widely accepted new and optimized context based compression, is defined. IPHC compression mechanism permits compressing the 40-byte IPv6 header down to 2 octets for link-local communications and to 3 octets for non-link-local transmissions, which corresponds to compression rates of 95% and 92.5% respectively IPv6 Packet Fragmentation In order to comply with the IPv6 specification, 6LoWPAN provides support also for packet fragmentation. 6LoWPAN packet fragmentation is based on the following principles: IPv6 packets to large to fit into a single IEEE frame are fragmented; A first fragment carries a header that includes the datagram size (11 bits) and a datagram tag (16 bits); Subsequent fragments carry a header that includes the datagram size, the datagram tag, and the offset (8 bits); Time limit for reassembly is 60 seconds. When an entire IPv6 datagram does not fit within a single IEEE MAC frame, such datagrams should be split into fragments. Each of these fragments needs to be encapsulated into a 6LoWPAN packet adding a fragmentation header which specifies an IPv6 packet identifier (so each fragment can be associated with its corresponding IPv6 datagram), an offset, and the total IPv6 packet length. This fragmentation header adds a 4

44 26 Chapter 2 octet overhead for the first fragment, and 5 for the second and subsequent fragments. Therefore, in order to minimize this overhead, fragmentation should be avoided as mush as possible. Furthermore, the fragmentation of large payloads is known to increase delay, packet loss probability and congestion so that it is recommended to use application layer payload lengths that avoid the need for 6LoWPAN fragmentation [32]. 2.6 RPL One of the most discussed topic with reference to IoT concepts and ad-hoc mesh networking is the routing protocol to be used. Routing Protocol for Low-power and Lossy networks RPL, defined in RFC6550 [4], can be considered to be state-of-the-art routing algorithm developed by the networking community. RPL has been proposed by the IETF Routing over Low-power and Lossy networks Working Group (ROLL) as a standard routing protocol for 6LoWPAN, since existing routing protocols do not satisfy all the requirements for Low power and Lossy Networks (LLNs). Particular applications are specified for Building Automation [33], Home Automation [34], Industrial and Urban automation [35] [36]. Although RPL is specified according to the requirements of these application requirements, it s use is not meant to be any way limited to these applications. RPL protocol is primaly thought for collection networks based on typical traffic of multipoint-to-point (MP2P) and point-to-multipoint (P2MP), and occasional P2P traffic. RPL routes are optimized for traffic to or from one or more roots that act as sinks for the topology. As a result, RPL organizes a topology as a Directed Acyclic Graph (DAG) (Figure 2.9) that is partitioned into one or more Destination Oriented DAGs (DODAGs), one DODAG per sink. It forms a non-transitive, non-broadcast multiple-access (NBMA), flexible network topologies upon which it computes routes. Multiple DAG could be instantiated to handle different networks optimizations.

45 Background 27 (a) a DAG tree (b) a DODAG network Figure 2.9: RPL DODAG 2.7 CoAP The interfacing of resource-constrained embedded devices to the Internet requires extensions to its current architecture and new lightweight representations. HTTP is less able to handle machine-to-machine (M2M) interactions efficiently with the additional overhead of heavy-weight resource representation formats such as HTML and XML. There is a need for a compact Representational State Transfer (REST) architectural style to connect Internet-enabled physical objects and access them through universally accepted standards-based methods. Constrained Application Protocol (CoAP) [5] is a specialized Web transfer protocol optimized for resource constrained networks typical of IoT and M2M applications defined by the IETF CoRE Working Group; the main objective of the CoAP application protocol is to provide a generic Web protocol for the special requirements of constrained wireless nodes. CoAP is similar to HTTP but its goal is not to simply compress HTTP but to implement a subset of REST operations optimized for M2M interactions. The interaction model is similar to the client/server model of the HTTP protocol. Clients request an action to a resource; then, the server sends a response with a response code, which may include a resource representation. Messages are exchanged asynchronously over a datagram-oriented

46 28 Chapter 2 transport (UDP). CoAP application areas include different forms of M2M communication in construction, health care, transportation or any other area utilizing sensor and actuator devices for monitoring and interacting with the environment [37]. The goal of the protocol is not only to compress HTTP, but also to include constraints such as statelessness, cache-ability, layered system, uniform interface common in current web protocols. Unlike HTTP based protocols, CoAP operates over UDP and employs a simple retransmission mechanism instead of using complex congestion control as used in standard TCP; TCP s flow control mechanism is not appropriate for LLNs and its overhead is considered too high for short-lived transactions. In addition, TCP does not have multicast support and is rather sensitive to mobility. CoAP operates over UDP and therefore has significantly lower overhead. It employs a simple retransmission mechanism instead of using complex congestion control as used in standard TCP and uses a unique Transaction ID to identify each GET request for retransmission purposes to keep reliability. In addition, the use of UDP enable CoAP at delivering multicast support. CoAP includes the following main characteristics: use of the UDP binding to avoid costly TCP handshakes; support for a subset of the methods defined in HTTP: GET, POST, PUT and DELETE. And three types of response codes: 2.xx (success), 4.xx (client error), 5.xx (server error); possibility for unicast and multicast requests, where multicast requests can be useful to query several similar devices simultaneously (e.g., group communications); URI based resource representation (e.g., coap://its-s.com/traffic-light) and support for different payload content types; support for simple stop-and-wait retransmission; reliability offered through an exponential back-off mechanism;

47 Background 29 support for simple proxy and caching capabilities; support for duplicate message detection. In addition with respect to HTTP, CoAP supports: transmission for larger amounts of data by splitting the data into blocks called Blockwise Transfer [38]; a Resource Observe mechanism built using a publish/subscribe pattern [39]; some resource discovery capabilities to allow clients to discover new resources handled by servers CoAP Messages (a) a CoAP transaction (b) a CoAP retrasmission Figure 2.10: Examples of CoAP transactions As mentioned before, CoAP uses the datagram-oriented UDP transport protocol to exchange messages. Different message types are used to establish a message exchange between client and server: Confirmable (CON): this message is sent when a reliable transmission is needed. The protocol guarantees that the message will not be lost within certain conditions. Because messages are transported over UDP, the reliability is accomplished with packet retransmission if a response is not received in a given time out. It increases exponentially with every new retransmission and, thus, provides a simple congestion mechanism. The packet will be lost if the maximum number of retransmissions is reached;

48 30 Chapter 2 Non-Confirmable (NON): this message is sent if a reliable transmission is not needed. It is useful for requests that are sent regularly. This message may carry a response for a NON request; Acknowledge (ACK): this message carries a response to acknowledge a CON request. This type of messages may carry response data or not. In the first case, the response is called piggy-backed response and in the second case separate response. The second one is used when the server cannot process the request immediately but promises that it will be processed; Reset (RST): this messages indicates that a CON messages has arrived but there is no context to process it. Independent of the message type, a message may carry a request, a response, or be empty. The type of the message is signaled by the type field in the CoAP header together with a response code to indicate the result of an request. The protocol is organized in two layers. A Transaction layer handles the single message exchange between end points, while a Request/Response layer is responsible for the transmission of requests and responses for the resource manipulation and transmission. A REST request is piggybacked on a Confirmable or Non-Confirmable message, while a REST response is piggybacked on the related Acknowledgment message. The dual layer approach allows CoAP to provide reliability mechanisms even without the use of TCP as transport protocol; in fact, a Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends the Acknowledgement message. In addition, it enables asynchronous communication which is a key requirement for IoT and M2M applications; when a CoAP server receives a request which is not able to handle immediately, it first acknowledges the reception of the message and sends back the response in an off-line fashion. Tokens are used for request/response matching in asynchronous communication.

49 Background Blockwise Transfers Basic CoAP messages work well for the small payloads we expect from simple sensors and actuators disseminated in the ITS infrastructure, simple switches like one on traffic lights, and similar automotive devices. Occasionally, however, applications will need to transfer larger payloads for instance, for camera acquisitions and firmware updates. Although UDP supports larger payloads through IP fragmentation, it s limited to 64 KiB and, more importantly, it doesn t work well for constrained applications and networks as previously stated. Blockwise Transfers pattern is one of the recommendations explained in the IETF draft exposed by the IETF CoRE Working Group in [38]. Block patter allows to define the request/response between clients and servers when a resource representation is larger than can be comfortably transferred in a single 6LoWPAN-based datagram. This option allows that a single REST operation can be split into multiple message exchanges, in order to satisfy the requirements on constrained networks such as 6LoWPAN. Therefore, this pattern results useful when huge quantity of data needs to be transferred; for example, when a large ITS dataset is requested. Since each packet 6LoWPAN could have about 81 bytes of payload (considering limitations due to IEEE LoWPAN, and UDP Headers). Thus, such as explained in previous sections, the payload is very constrained in size so applying even more fragmentation could be even worse. Due to that, in order to avoid operations that could cause fragmentation at network level, with the implementation of a blockwise transfers pattern it is possible to carry the fragmentation of the data transmission from network to application layer Resource Observe Pattern In HTTP, transactions are always client-initiated, and the client must perform GET operations again and again (polling) if it wants to stay up-todate about a resource s status. This pull model becomes expensive in an environment with limited power, limited network resources, and nodes that

50 32 Chapter 2 sleep most of the time. Instead of trying to create another complex publishsubscribe architecture, CoAP effectively provides a minimal enhancement to the REST model, just adding the well-known observer design pattern [40]. CoAP uses an asynchronous approach [41] to support pushing information from servers to clients observation. In a GET request, a client can indicate its interest in further updates from a resource by specifying the Observe option. If the server accepts this option, the client becomes an observer of this resource and receives an asynchronous notification message each time it changes. Each such notification message is identical in structure to the response to the initial GET request Resource Directory In the M2M environments that will be typical of CoAP applications, devices must be able to discover each other and their resources; Resource discovery is common on the Web, and is called Web discovery in the HTTP community. One form of Web discovery occurs when humans access a server s default resource (such as index.html), which often includes links to other Web resources available on that or related servers. Machines can also perform Web discovery if standardized interfaces and resource descriptions are available. New approaches from the IETF include the well-known resource path /.well-known/ scheme (RFC5785) [42] and the HTTP link header (RFC5988) [43]. Several related techniques are common today. In CoRE, we re dealing with autonomous devices and embedded systems; thus, the importance of uniform, interoperable resource discovery is much greater than on the current Web. To ensure interoperability between CoAP end points, the protocol includes a technique for discovering and advertising resource descriptions; to achieve resource discovery, CoAP servers are encouraged to provide a resource description available via the well-known URI /.well-known/core for resource discovery and CoAP clients then access this description with

51 Background 33 a GET request on that URI. The same description could be advertised, or even posted to a description directory. The description format is based on the HTTP link header format as an Internet media type carried in the payload, which is simple and easy to parse [44].

52

53 3 6LoWPAN ITS-S Design In this chapter the ITS-Station (ITS-S) architecture is presented. After a brief introduction to the generic ITS-S architecture, specific characteristics of the CALM Roadside Network are outlined along with a discussion with the open challenges. The focus is finally given to our proposal of mapping of a 6LoWPAN compliant stack onto the CALM reference architecture along with description of typical application use cases. 3.1 Concepts Behind CALM Standardization The CALM ITS-S architecture presented hereby is a result of discussion and consensus of various stakeholders in the ITS domain. The development of the ITS Station architecture will progressively continue following the feedback from Field Operational Tests (FOTs). A successful and validated development of ITS-S functions deployed as services in Smart Cities will disclose a business case for automotive and suppliers industries so that commercial solutions of products and software will be let available to final uses in the near future. CALM standardization aims at accelerating the development by enforcing the interoperability among products from different vendors. With open standards, an hardware product on the market can be easily replaced by another product. The same applies to softwares modules where well-known standardized interfaces are defined. An open R&D cycle permits to incrementally meet the CALM requirements in ITS deployments; moreover it allows to include recent advances into existing set-ups. In CALM definition an ITS station is a component in a communication

54 36 Chapter 3 network that executes ITS applications within a bounded secured managed domain. The standard describes the communications architecture of intelligent transport systems (ITS); the architecture is described in an abstract way with several graphical views and examples that partially follows the principles of the the ISO Open Systems Interconnection (OSI) model [45]. Figure 3.1: CALM ITS-S General Architecture The architecture (Figure 3.1) consists of six main parts. In the data plane, the ITS Station architecture has four layers that perform different tasks; from the bottom to the top, Access, Network & Transport, Facilities and Application layers are stacked. The layers next to each other are connected via a Service Access Point (SAP). In addition to the OSI 7-layer stack, a Management entity and a Security entity are connected to all the layers via the SAPs in a cross-layer fashion. This cross-layer design have been originally introduced by ISO TC204

55 6LoWPAN ITS-S Design 37 WG 16 [12] and is now clearly represented on the architecture diagram (ITS station management plane); The cross-layer functions to be offered are still under discussion at the ETSI and ISO standardization levels. The ITS station concept is based on the abstraction of ITS applications from communication protocols serving these ITS applications along with the ability to securely manage those applications and communications. The access technologies layer reflects CALM s objective to allow seamless communication over several coexisting access technologies; In fact the CALM basic idea is that on a typical ITS node there are a number of medias or physical (radio) interfaces available, and each of these tries to stay continuously connected to the external world. The available connections together with key parameters such as cost, available rate, latency and so on are continuously sent to a Communications Manager. At the same time the applications and services that need connection, register with the same Communications Manager. The communications manager has a simple task in mix-and-match the available interfaces with the applications that need service. It also means that applications might be using different interfaces. Such an interface management component requires input from various layers and is thus a cross-layer function. Table 3.1 summarizes the main difference between CALM and OSI models. CALM OSI Access Physical (1) Data Link (2) Networking and Transport Network (3) Transport (4) Facilities Session (5) Presentation (6) Application (7) Management None Security None Table 3.1: Comparison between CALM and OSI models

56 38 Chapter CALM ITS-S Reference Architecture First, in the ITS communication modes, four main system components, which can communicate with one another are described, that are Roadside ITS-S, Vehicle ITS-S, Personal ITS-S and Central ITS-S. Second, the function of communication and application are separated into routers and hosts; An ITS Station has at least one router to control the communication functions. And in the ITS-S, hosts run road safety, traffic efficiency, comfort and infotainment applications. However the function of the router and the host can be installed in a single node as it is an implementation choice CALM ITS-S Sub-Systems Figure 3.2: CALM ITS-S Complex Architecture In CALM an implementation of an ITS-S together with additional functionality is called ITS Sub-System (Figure 3.2). Actually four ITS-S Sub-Systems have been currently defined: vehicular ITS sub-system, i.e., an ITS sub-system installed in a vehicle (e.g., passenger car, bus, truck or motor-cycle);

57 6LoWPAN ITS-S Design 39 roadside ITS sub-system, i.e., an ITS sub-system installed at the side of a road, (e.g., on a gantry); personal ITS sub-system, i.e., an ITS sub-system installed in personal device (e.g., a mobile smart phone); central ITS sub-system, i.e., an ITS sub-system installed in an office, (e.g., a traffic management center). In the following we focus the attention on the roadside ITS Sub-System CALM Complex ITS-S Reference Architecture As described in the working documents, the roles of an ITS-S can be implemented not only as a whole but also in physical units in a distributed fashion. Figure 3.3: CALM ITS-S Node Specialization Typical roles separation (Figure 3.3) defined in the standard follow:

58 40 Chapter 3 ITS-S router, i.e., an ITS-S node comprised of routing functionality of an ITS station used to connect two networks, at least one of which is an ITS station-internal network; ITS-S border router, i.e., an ITS-S router used to connect external networks of ITSs or legacy nodes; ITS-S gateway, i.e., an ITS-S node used to interconnect two different OSI protocol stacks at layers 5 through to 7; ITS-S host, i.e., an ITS-S node comprised of ITS-S functionalities except from those covered by ITS-S router role, ITS-S border router role and ITS-S gateway role. 3.2 CALM ITS-S Roadside Network Figure 3.4: CALM ITS-S Roadside Network A typical CALM roadside network (Figure 3.4) consists of several components: i.e., ITS-S Border Router devices connecting to the Internet via a public network, ITS-S Gateway devices connecting to proprietary networks and legacy roadside infrastructure systems (e.g., Variable Message

59 6LoWPAN ITS-S Design 41 Signs (VMS)), ITS-S Router/Host devices and a number of ITS-S Router devices acting as infrastructure for the other nodes. ITS-S Router devices can be installed along a road in order to allow both vertical and horizontal handover between subsequent devices to ensure continuous communications e.g., between an ITS-S in a vehicle running on the road and for example a central ITS-S on the Internet. The ITS sub-system illustrated contains a roadside ITS-S which is physically split into an ITS-S host, an ITS-S router, and parts of a roadside ITS-S gateway and an ITS-S border routers. A roadside ITS-S gateway connects the ITS station-internal network with a legacy and eventually proprietary roadside network; The part of the vehicle ITS-S gateway which connects to the proprietary roadside network is not considered in the CALM suite of standards LoWPAN ITS-S Specification Proposal A lot of IP topics are addressed through CALM standardization and several working documents are related to VANET connections, host mobility and security issues. ISO draft of International Standard [14] determines the network protocols to support reachability at a global IP address, continuous Internet connectivity and the handover of a session performed by a mobile router from a point of attachment to the infrastructure to another point of attachment either using the same media or using different CALM media. Recently an EU funded project called ITSSv6 [46] is focusing on research issues related to IPv6 applicability to intelligent transportation; the main scope of the project is the development of an interoperable IPv6 stack conform to CALM architecture [47]. Goal of the project is to develop an open-source IPv6 ITS Station stack freely available to European and national third parties (projects, industry and academia) using IPv6 for Internet-based communications in Field Operational Tests (FOTs) and the input is taken from the FP6 CVIS [15] core communication software and additional modules developed by FP7 GeoNet [48].

60 42 Chapter 3 An open issue regards the possibility to interconnect WSNs with ITS-Ss. Roadside networks compliant with CALM are expected to interact with local access networks to send the information retrieved from sensors to other ITS-Ss and would thus benefit from a seamless integration. The main limitation of the current CALM architecture is related to the lack of fully interoperability between ITS-Ss and WSNs. The actual ISO solutions address the problem using an adaptation gateway similar to ones just referred for legacy and proprietary devices. To obtain seamless design and overcome the limitation previously discussed we propose [49] an extension of the CALM general architecture taking into account the possibility offered by 6LoWPAN protocol stack discussed before. Figure 3.5: 6LoWPAN ITS-S Proposed Architecture In particular we propose to evaluate the integration of the following modules: Network & Transport level: 6LoWPAN and RPL are proposed at Network & Transport level as they permit a seamless IP integration between ITS-S defined by the actual CALM standard and WSNs based on the IEEE Access Medium; Facility level: the adoption of CoAP is proposed at Facility level

61 6LoWPAN ITS-S Design 43 as it permits, together with its most promising specifications (e.g., Resource Observe pattern, Blockwise Transfers pattern) reliable and efficient UDP transmission with reduced overhead. Leveraging the results just obtained by 6LoWPAN in others fields of applications and briefly described in the background chapter we judge feasible to implement low-cost ITS-S nodes and deploy real pervasive roadside networks in order to cover the typical footprint of megacities. This argument has been addressed as a prominent target of ITS by ITU within its C-ITS initiative [50] [51]. Furthermore we consider this architecture, based on interesting and innovative ideas, able to deliver next generation non safetycritical application allowing each ITS node to be accessed worldwide for its data and services. 3.4 An envisioned Use Case and its Requirements Example: Intelligent Traffic Monitoring 6LoWPAN ITS-Ss can be pervasively deployed at the same time of the road construction; retrieving real-time information on traffic permits to fine-regulate the access to the road. The lifetime of the 6LoWPAN nodes incorporated on top of light poles is expected to be as long as the life time of the roads (about 10 years). Multi hop communication is possible between 6LoWPAN Nodes, and the network should be able to cope with the deterioration over time of the node density due to power fails. Sink nodes placed at the side of road are most likely mains-powered, while 6LoWPAN Nodes in the roads run on battery. Power saving schemes might intermittently disconnect the nodes. Dominant parameters in roadside monitoring applications follow: Deployment: pre-planned (standardization is needed in order to permit upgrades);

62 44 Chapter 3 Network Size: very large (pervasive); Connectivity: intermittent (due to path loss and urban interference); Multi-hop communication: multi-hop, especially adhoc; Traffic Pattern: mostly Multi-Point-to-Point (MP2P), Point-to- Multi-Point (P2MP); Mobility: absent or limited (road infrastructure); Power Source: hybrid. Scope of the following of this dissertation is the presentation of a working prototype of the proposal here detailed.

63 4 6LoWPAN ITS-S Implementation In this chapter a working prototype for a 6LoWPAN ITS-S is presented. The implementation follows the design principles described in the CALM standard, labeled as Complex architecture and described in the previous chapter. Following a bottom-up approach, all the building blocks chosen for the design are illustrated and the main features are sketched out. This approach seems especially appropriate because all the components of the systems, although specialized at Application and Facility levels share the bottom layers components. 4.1 Hardware and Software Adopted Hardware Components By design, to keep the prototype idea simple, we have decided to develop all the CALM component of our 6LoWPAN ITS-S Roadside Network implementation using the same embedded architecture: the SEED-EYE board. SEED-EYE [52], designed by Scuola Superiore Sant Anna [53] and Evidence Srl. [54], is an advanced WSN node specifically thought for ITS applications. The board has been widely used in IPERMOB [55] [56], a research project on ITS funded by the Tuscan Regional Board through the European Regional Development Fund recently ended in June 2011; the IPERMOB project proposes a pervasive and heterogeneous infrastructure to monitor and control urban mobility. Within the project, a prototype of

64 46 Chapter 4 Figure 4.1: IPERMOB Testbed at the Pisa International Airport such infrastructure has been implemented and deployed at the Pisa International Airport (Figure 4.1). SEED-EYE board (Figure 4.2) incorporates a Microchip PIC32 Systemon-Chip (SoC) integrated circuit. This unit incorporates an 80Mhz MIPS M4K processor based on a MIPS 32-bit architecture; the SoC operative voltage ranges from 2.3V to 3.6V and implement some power sleeping modes (RUN, IDLE, and SLEEP modes) along with multiple switchable clock modes useful for the development of power saving policies. From a network layer and radio communications point of view, SEEDEYE offers a platform based on IEEE : the Microchip MRF24J40B transceiver; this transceiver is IEEE compliant and operate in the 2.4 GHz to GHz ISM unlicensed bands. The main features of the device are: MCU: the Microchip PIC32MX795F512L implements a MIPS architecture and can provide up-to 80 MIPS of computational power. It implements in hardware IrDA, SPI, I2C, UART, USB, and CAN communication protocols easing the connection with external units; RAM: 128KB; FLASH: 512KB Flash (plus 12KB boot Flash); IEEE interface: a Microchip MRF24J40MB transceiver. IEEE interface: the MCU implements the IEEE MAC

65 6LoWPAN ITS-S Implementation 47 Figure 4.2: SEED-EYE hardware components

66 48 Chapter 4 layer and by using an external on-board SMSC8720 PHY adapter the unit can communicate with other ITS-Ss units or PCs; USB interface: a microusb-a connector is directly connected to the MCU allowing the device to operate in Master or Slave Mode; Connectors: SEED-EYE exports all the MCU pins that are not used by on-board peripherals. Designers can access SPI, I2C, UART and CAN ports; I/O: SEED-EYE exports also some Analogic and Generic pins, Single and multiple point of access Interrupts; DC/DC input power conversion: the board can be powered either by standard power jack or by USB. Power efficiency of the board is extremely high and it is possible to power down various components of the board changing the status of some MCU pins. We selected the SEED-EYE board for our development for the following arguments: SEED-EYE board is especially suited for a CALM Complex Architecture prototyping due to its flexibility as it does include, all-in-one, some useful data bus used in automotive applications; in particular the CAN bus. Controller Area Network (CAN) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host computer. Original designed in 1983 at Robert Bosch GmbH, CAN bus is a messagebased protocol thought specifically for automotive applications but now also used in other areas such as industrial automation and medical equipment. the on-board MRF24J40B radio transceiver along with its internal power amplifier (20dBm) enables the SEED-EYE for long range communication(up to 100 meters in open space at maximum power). The MRF24j40B also provides a Turbo mode to transmit and receive at

67 6LoWPAN ITS-S Implementation kbps (2.5 times larger than nominal bit rate in IEEE networks) enabling for higher data rates for proprietary protocols Adopted Software Components Each node runs Contiki [57], an operating system especially designed for constrained embedded applications. Contiki was created by Adam Dunkels in 2003 [58] and is has been further developed by a world-wide team from Atmel, Cisco, Enea, ETH, Oxford University, SAP, Sensinode, SICS, ST Microelectronics, Zolertia, and many others. Contiki [58] can be considered the state of the art operating system for IoT and does implements an lightweight configurable 6LoWPAN stack that implements almost all the capabilities detailed in the background chapter. Contiki provides three network mechanisms: the Rime stack [59], which is a set of custom lightweight networking protocols designed specifically for low-power wireless networks, the µip TCP/IP stack [60], which provides IPv4 networking and the µipv6 stack [61], which provides IPv6 networking. The IPv6 stack was contributed by Cisco and was at the time of release, the smallest IPv6 stack to receive the IPv6 Ready certification. The IPv6 stack also contains the RPL routing protocol for low-power lossy IPv6 networks and the 6LoWPAN header compression and adaptation layer for IEEE links. Contiki does also implement a quite complete CoAP protocol stack including its most interesting features such as Blockwise Transfers and Resource Observe patterns discussed in the background chapter. Application concurrency in Contiki is realized by Protothreads [62], a event-driven pattern implementation that that provide a linear, thread-like programming style on top of the event-driven kernel. This programming model has the advantage over multi-threading that it does not require as much memory because event-driven processes all share one stack. Contiki has been just ported to a set of common low-power wireless hardware platforms manufactured by several industries (e.g., TI MSP430x, Atmel AVR and ST STM32w).

68 50 Chapter Porting Contiki over SEED-EYE Board The first phase of the presented implementation consisted in the porting of the Contiki operating system to Microchip PIC32 (PIC32MX795F512L) [63], the microcontroller integrated on the SEED-EYE board. This has been necessary because at the time the project started in the community there were no ports for Microchip MCUs and therefore our work is relevant also to other research groups. Figure 4.3: Implemented and configured modules This porting phase concerned mainly in the: study of the Contiki software organizations and drivers requirements; analysis of the hardware capabilities offered by the Microchip PIC32 MCU and by the Microchip MRF24J40B radio transceiver; implementation of the timer routines required by the Contiki OS exploiting the hardware timer;

69 6LoWPAN ITS-S Implementation 51 implementation of a IEEE driver for the radio transceiver; development of some low-level drivers for peripherals like UART (e.g., for debugging purpose), the SPI bus (e.g., by expansion boards such as the camera module and also by the radio transceiver itself); development of other drivers such as the ones for buttons, leds and ADC used in validation and testbed applications. This task presented several challenges which were tackled sequentially. At first it was important to familiarize with the concepts of this operating system. To such an objective we referenced to a series of papers and several websites containing useful information. Next we addressed the comprehension of a large and diverse code base. Thanks to this project we were also able to increase our knowledge of operating systems and especially memory constrained operating systems; we learned about the state of the art in this field and about existing challenges. We also learned how to develop code for event driven kernels and the limitations of it. Moreover, we learned about hardware and the Integrated Development Environment used to program it. Also, we got some experience in debugging weird behaviours of embedded devices. 4.3 ITS-S Network Stack Implemented All the building blocks at Access and Network & Transport layers (referring to CALM model) are shared between the nodes of the proposed roadside ITS-S architecture and are specified below. This particular design choice allows to define a P2P mesh topology where all the involved objects in the network participate in the network routing and thus adheres to the CALM ITS-S Router functionality Access Layer Implemented At Access level, our Contiki port has been configured to use the CSMA module in hardware for the MAC layer and a NULL RDC module for the

70 52 Chapter 4 radio duty cycling (RDC) layer, which effectively keeps the radio always on. Extensive tests and evaluations have been also taken on other radio duty cycling implementations like ContikiMAC [64] and some others [65], but due to the preliminary results these are not shown and further investigations will follow Network & Trasport Layer Implemented At Network & Transport level, nodes implements 6LoWPAN and we enabled the most recent 6LoWPAN header compression scheme available in Contiki (IPHC as defined in RFC6282 [3]). The network stack has been configured with UDP and ICMPv6 enabled, while routing has been handled using RPL routing protocol. 4.4 ITS-S Node Specialization In this section we present the additional node specialization requested to deploy all the others CALM Roadside Network entities ITS-S Border Router (a) prototype architecture (b) proposed architectures Figure 4.4: 6LoWPAN ITS-S Border Router prototype design

71 6LoWPAN ITS-S Implementation 53 CALM ITS-S Border Router functionality has been developed using a Serial Line IP (SLIP) interface. SLIP [66] is a very simple protocol that frames IP datagrams to send them over serial connections. Although it is mostly obsolete now, thanks to its small overhead, it is still used for connecting constrained embedded systems; this implementation has been proposed in [67] and results especially suited also for ITSs purposes as it allows a seamless interconnection between the implemented IoT network to the ITS backbone and additionally to the Internet. SLIP interface has been implemented developing an interrupt driven driver for the UART module in the MCU; a UART port has been used to interconnect a SEED-EYE with a Linux PC acting as IPv6 route forwarder. Figure 4.5: AICCU software used to connect to SixXS IPv6 tunnel broker A border router application for Contiki OS has been customized to address some performance issues and to allow a global IPv6 address resolution that has been deployed and tested making use of an IPv6 tunnel broker (SixXS) [68] and the software AICCU (Figure 4.5) to build an IPv6 tunnel over a IPv4 network; this has been necessary due to the lack of global IPv6

72 54 Chapter 4 addressability of the laboratory PCs and has been used to emulate a Wide Area Network (WAN) through a remote PC acting as a CALM ITS-S Central Station; specifically we enabled the Border Router to distribute the 2001:1418:100:823c::/64 global subnet over the WPAN ITS-S Host Figure 4.6: 6LoWAN ITS-S Host functions implemented

73 6LoWPAN ITS-S Implementation 55 CALM ITS-S Host specific functions 4.6 have been implemented by means of virtualization and thus not need a particular detail in this dissertation; traffic light devices have been emulated using simple leds, light switch by using on-board buttons and sensors/actuators by using ADC analog to digital converts. Figure 4.7: Examples of possible ITS-S host specializations Previous studies related to SEED-EYE ITS application has been conducted by CNIT and TeCIP Institute to support for example RFID [69] and smart distributed cameras [70] functionality (Figure 4.7); these projects along with the IPERMOB [55] pilot demostrated the feasibility for WSN nodes to deliver ITS application. In our prototype, ITS-S Hosts export their specific resources through a CoAP server (e.g ITS-S Hosts export analog switch, RSSI sensor and some timing information permitting studies on node energy consumption [71]); The Contiki CoAP library used is called Erbium and has been developed by Matthias Kovatsch [72] LoWPAN ITS-S Roadside Network Below the typical use cases for the proposed architecture are envisioned; having implemented all the specific components, the interconnection results quite common (Figure 4.8):

74 56 Chapter 4 specific WSN-based ITS-S nodes could be implemented for proprietary devices and data bus (up-to layer OSI 7) and could be interconnected to legacy roadside equipment (e.g., line/speed sensors [73] [74], traffic-light and variable message signs); a large number of router-only nodes could be widely deployed, due to the low-cost and small-size nature of the nodes, creating a routing topology suited for the application; border router nodes could be added to the network enabling a remote ITS Central Station to direct manage and reconfigure specific nodes functionality by uniquely reach it by using global IPv6 addressing. Figure 4.8: 6LoWAN ITS-S RoadSide Network envisioned use case

75 5 Analysis and results In order to verify the correctness of the implementation and to analyze the capabilities of the system, several tests have been performed at the TeCIP Institute of Scuola Superiore Sant Anna and CNIT National Laboratory of Photonic Networks (LNRF) using some testbeds simulating typical ITSs non safety-critical services (i.e. exchanges of simple infotainment messages through CoAP Resource Observe pattern). The test can be classified into two groups: firstly we have verified that basic functional requirements are met (the network stack implemented works) and secondly we have analyzed system performance with reference to typical ITS use cases (the network stack works well). 5.1 Methodology During the entire development and analysis of the presented prototype we use a set of softwares able to statically and dynamically analyze the firmware behavior under both functional and performance perspectives ITS-S Roadside Network Testbed MPLAB X IDE and Wireshark are the main software used during the entire process of development and analysis; other debugging software extensively used for network debugging include ping6 and traceroute6. Microchip MPLAB X IDE (Figure 5.1) is the official development IDE for Microchip MCUs; based on Netbeans IDE it includes a set of facilities for the development (i.e. an advanced editor) along with a set of

76 58 Chapter 5 Figure 5.1: Microchip MPLAB X IDE during a software debugging session static and dynamic firmware analysis routines. PICkit3 is the microprocessor programmer used for firmware flashing and on-line debugging tasks. Wireshark (Figure 5.2) is a very popular network analyzer tool. It is perhaps one of the best open source packet analyzers tools that are available these days. It allows the user to capture and browse running traffic on the network. It is widely used in cross educational institutions and industries. Its development started in 1998 and is still active. Recent implementations include some IEEE , 6LoWPAN and CoAP packets dissectors. 5.2 The Testbed ITS-S Roadside Network Testbed In order to give a system characterization and evaluate the system performance at delivering non safety-critical applications we deployed a specific testbed involving a WAN connection between two peers. The system architecture is formed by two ITS-S Sub-Systems interconnected through a WAN: a roadside network and a central station.

77 Analysis and results 59 Figure 5.2: An on-line packet analysis using Wireshark Figure 5.3: 6LoWPAN ITS-S Roadside Network Testbed

78 60 Chapter 5 The roadside network has been implemented with reference to the CALM Complex Architecture and in particular is composed by the following three entities: an ITS-S Host acting as CoAP server; a ITS-S device acting as simple ITS-S Router; an ITS-S Border Router providing WAN connectivity and global addressability to the entire ITS-S network. As previosly stated, due to the particular design choice, in this implementation all the instantiated nodes act as ITS-S Routers. The nodes have been deployed in a regular line topology at a distance of 10 mt one from the other and transmission power has been set to the minimum allowing neighbours to ear each others ITS-S Central Station Testbed To test the proposed architecture and to evaluate the behavior of the components over a Wide Area Network (WAN) we have also developed a simple Central Station. The deployed Central Station is composed as follows: generic PCs using Linux Ubuntu OS [75] as base system; the same AICCU [76] software just used to develop the WAN IPv6 interconnection through a SixXS tunnel broker [68] and here used for the same reason; traditional IP tools for network diagnostics such as ping6 and traceroute6 ; a Firefox browser enhanced with the Copper (Cu) plugin [77] developed by Matthias Kovatsch to test CoAP facilities and ITS-S Host functions.

79 Analysis and results Functional Tests The following are some examples of functional tests executed on the testbed: ITS-S Hosts have been connected to simple devices (e.g., to a power switch using an ADC) and device functionality has been exported on the ITS-S network using CoAP applications; Figure 5.4 illustrates two examples of requests executed using Copper Firefox plugin. simple ITS-S Routers nodes have been used to build several network topologies and have been connected to Hosts using the RPL protocol; all nodes have been enabled for IPv6 global networking and addressing by using a node acting as ITS-S Border Router; an ITS-S Remote Central Station has been simulated using simple PCs interconnected to a IPv6 tunnel broker and executing some queries to other ITS-S nodes using CoAP protocol. 5.4 Performance Analysis Targets of the presented architecture are non safety-critical services; to prove that the system is capable to deliver such service we analyzed the network response in terms of Round Trip Time and Packet Loss metrics. Round Trip Time In telecommunications, the round-trip delay time (RTD) or roundtrip time (RTT) is the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgment of that signal to be received. This time delay therefore consists of the sum of transmission times between two points. In the context of computer networks, the signal is generally a data packet, and the RTT is also known as the ping time. Packet Loss Packet Loss (PLOSS) occurs when one or more data packets traveling

80 62 Chapter 5 (a) An example of CoAP ITS-S Host exporting a Power Switch resource (b) An example of the Resource Observe pattern applied to a Time Event Figure 5.4: Examples of CoAP ITS-S Hosts exporting internal resources