RDS-Based Intersystem Communication for Ultra-Low Data Platoon VANETs

(1)

RDS-Based Intersystem

Communication for Ultra-Low

Data Platoon VANETs

JONAS WALLMEIER

K T H R O Y A L I N S T I T U T E O F T E C H N O L O G Y

(2)

KTH Royal Institute of Technology

Information and Communication Technology

RDS-Based Intersystem Communication

for Ultra-Low Data Platoon VANETs

Master Thesis

Jonas Wallmeier

Supervisors: M. Sc. Florian Curinga (H&E Solutions) Prof. Johnny Öberg

Responsible Professor:

Prof. Mark Smith

(3)

(4)

Affidavit

I declare that all material presented in this paper is my own work or fully and specifically acknowledged wherever adapted from other sources.

I understand that if at any time it is shown that I have significantly misrep-resented material pmisrep-resented here, any degree or credits awarded to me on the basis of that material may be revoked.

I declare that all statements and information contained herein are true, cor-rect and accurate to the best of my knowledge and belief.

(5)

(6)

Abstract

Many experts agree that Vehicular Ad Hoc Networks (VANETs) are indis-pensable for the future of our transportation system. The applications that could be based on this technology are endless and stretch from automated breaking systems to multimedia streaming.

However, current approaches all rely on additional hardware which is not available in modern off-the-shelf vehicles.

(7)

(8)

Abstract

Många experter är överens om att Vehicular Ad Hoc Networks (VANETs) är indis- penslar för framtiden för vårt transportsystem. De applikationer som kan baseras på denna teknik är oändliga och sträcker sig från automatiserad bryta system till multimedia streaming.

Men nuvarande metoder är alla beroende av extra hårdvara som inte är Finns i moderna fordon utan hylla.

(9)

(10)

List of Figures

2.1 Networking challenges in VANETs . . . 4

2.2 Types of VANETs . . . 5

2.3 VANET Routing Overview . . . 6

2.4 RDS Radio . . . 9

2.5 RDS Message Type Structure . . . 11

2.6 Performance comparison between ALOHA and CSMA protocols 13 4.1 Non-persistent CSMA Flowchart . . . 22

4.2 Simulation Result . . . 23

4.3 GPS Encoding . . . 24

5.1 Simulation Interface . . . 30

5.2 Overall Software Architecture . . . 31

5.3 Timeline of a Network Handshake . . . 34

6.1 Fake Data GUI . . . 36

6.2 Fieldtest Vehicles . . . 37

6.3 Network response . . . 38

(13)

(14)

List of Tables

2.1 RDS Packet Overview . . . 10

2.2 RDS Data per Group . . . 10

4.1 A GPS En-/Decoding Example . . . 25

(15)

(16)

Chapter 1 Scope and Motivation

With the increasing autonomy of vehicles, connecting cars with one another is becoming more and more important. Companies around the world are pushing to bring this technology to the market as fast as possible as the number of applications that could be based on these so called Vehicular Ad Hoc Networks (VANETs) are sheer endless [1]. For instance, in a platooning scenario, a car could simply follow another vehicle autonomously, which could drastically increase efficiency and security, especially for trucks on long high-way rides. A breaking car could warn following vehicles, even if they are out of sight, using so-called electronic brake lights. And if that wasn’t enough to prevent an accident, traffic information systems could inform emergency ser-vices and other vehicles on the road only seconds after the accident happened. However, for all of those scenarios, general inter-compatibility between the vehicle’s communication systems is essential and will probably not hap-pen anytime soon. One of the biggest problems is that this requires additional hardware. So in order to get wide market acceptance for VANETs, car man-ufacturer around the world would have to agree on one protocol and start building in the additional modules.

(17)

2 CHAPTER 1. SCOPE AND MOTIVATION

quality of the service by interfering with their own signals. Therefore, the subject of this project was to extend the existing system by a networking feature, allowing vehicles to detect one another and adjust their sending pat-terns accordingly.

In particular, the following tasks had to be accomplished: • Research existing VANET solutions for inspiration • Develop a resilient protocol based on RDS that could:

– Detect nearby vehicles and start a network – Detect the leading vehicle of a group

– Find the vehicle best suited for transmitting the warning message • Verify the protocol

(18)

Chapter 2 State of the Art

This chapter describes the current state of the art of some of the methods and technologies upon which the developed system is based. First, the current state of research concerning Vehicular Ad Hoc Networks (VANETs) will be shown. The following section explains what exactly the Radio Data System is. Section 2.3 lists and explains Media Access Control techniques, which are necessary for any wireless network in order to coordinate having several nodes transmitting on the same frequency. Finally, 2.4 gives a short overview of the operating system and tools used to develop and run the application.

2.1 Vehicular Ad Hoc Networks

Vehicular Ad Hoc Networks (VANETs) are a subclass of Mobile Ad Hoc Net-works (MANETs) which have been heavily researched since the mid 1990s [2]. Typically, nodes in a MANETs are very restricted in terms of energy, computational power and memory. Numerous different protocols have been proposed, many of which with the ability to self heal. This means that they can detect suddenly missing or moved nodes and adapt their routing strategy accordingly.

(19)

ex-4 CHAPTER 2. STATE OF THE ART

tension to the IEEE 802.11 standard (known as Wi-Fi): IEEE 802.11p. It will be designed specifically for vehicular environments and operate at a fre-quency of 5.9 GHz. 802.11p promises to ensure delays of less than 100 ms for high-priority messages. [1]

Current approaches can be divided by use-case, routing method and type of network [2] (see Figure 2.1), which will be discussed in the following sections.

Figure 2.1: Networking challenges in VANETs

2.1.1 Types of VANETs

VANETs can be classified as either Vehicle to Vehicle (V2V) or Vehicle to Infrastructure (V2I) network, depending on their application. Some networks that support communication with both, other vehicles and infrastructure, are referred to as Vehicle to X (V2X) (see Figure 2.2).

(20)

CHAPTER 2. STATE OF THE ART 5

Figure 2.2: Types of VANETs (Overview) [3]

Safety and Traffic

Safety and traffic control are arguably the most important aspects of vehicle to vehicle communication enabling services like collision warning, road ob-stacle warning, cooperative driving, intersection collision warning and lane change assistance [4]. For this, two types of security messages are used: event-driven and periodic messages [2]. The latter contains the state of the sending vehicle, i.e. position, speed, direction, etc., as well as data collected from surrounding vehicles. Such a periodic message exchange (beaconing) can be used to detect potentially dangerous situations before they even ap-pear and react accordingly. Other applications could use this information for example for traffic monitoring and control or message routing.

(21)

6 CHAPTER 2. STATE OF THE ART

Comfort

Comfort applications in VANETs can send messages across the network using services such as unicast, multicast, broadcast or anycast, representing 1-to-1 with known destination, 1-to-many, 1-to-all and 1-to-1 communication with unknown destination, respectively [2]. Probably the most versatile use-cases for a comfort application is mobile internet access. For example by using Road Side Units (RSUs) as fixed access points alongside a road, a VANET could be used to distribute data from a RSU with internet access to vehicles that do not have a direct connection themselves.

2.1.2 Routing

There is a long list of reasons why efficient routing in VANETs is not a trivial task. The most critical aspect is the high speed of nodes and with that the rapidly changing topology of the network [5]. Other problems can be caused by the varying density of nodes. For instance, there can easily be hundreds of nodes in the range of one vehicle in urban regions, especially during rush hour while at night on the countryside it might be that there is not a single other vehicle around.

In most cases, the routing protocol of a VANET can be classified as either topology or position based. Figure 2.3 shows further sub-classification of both approaches, which will be explained in the remainder of this section. Other routing methods exist, but are not as common. Some of them are listed under ’Other Methods’.

VANET Routing Protocols Topology Based

Proactive Reactive

Location Based Non-DTN

Beacon Non-Beacon Hybrid

DTN Hybrid

Figure 2.3: VANET Routing Overview [5]

Topology Based

(22)

be further categorized as proactive (table driven) or reactive (on-demand). [6] Proactive protocols keep information about all connected nodes in tables and usually determine the optimal route to a receiving node using shortest path algorithms [5]. To also get information about one-hop neighbours1_{, all}

nodes periodically broadcast their tables. This approach is well suited for real time applications, as no route discovery is needed which allows for low latency transmissions. However, this comes at the cost of significant over-head for storing and transmitting information about all neighbours.

Reactive protocols on the other hand, don’t store data about neighbours, but try to collect this information whenever needed using route discovery al-gorithms [5]. This on-demand approach reduces network traffic significantly, as periodic messages are no longer required. However, excessive flooding of the network for route discovery can cause disruption of communication and increases the time it takes to establish a connection.

Position Based

Position based (sometimes location based or geographic) routing uses the ge-ographical position to address another node as opposed to a network ID as it is the case in topology based methods [6]. This approach assures scalability of the network and no longer requires route discovery or management. How-ever, it does requires a position determining service like GPS, which is not always available (e.g. in tunnels). Location based routing differentiates be-tween Delay Tolerant Networks (DTNs), Non-DTNs and a hybrid version. [5] Delay Tolerant Networks use a carry & forward strategy. This means a node will store packages that it cannot forward (e.g. because of a temporary disconnect) and use a metric based on its neighbours in order to determine a forwarding strategy.

Non-Delay Tolerant Networks cannot simply store messages and re-broadcast them at a later point in time. Instead, they often make use of beacons to make sure nodes are reachable or use an overlay, which is built

1_{Receiving nodes that are not directly reachable by the sender, but rely on an additional}

(23)

on top of an existing network and connects all nodes by a virtual or logical link.

Other Methods

• Cluster Based Routing: A cluster is a virtual infrastructure over a small subset of nodes. All nodes within one cluster can communicate with one another, but have to rely on a special node, the cluster head, for inter-cluster communication. [6]

• Broadcast Routing: This method is used for messages that concern all nodes in a network. Using a flooding technique, information can reach any node fairly quickly with little overhead. However, it might cause problems due to the high peak in network activity it can cause. [6]

• Geocast Routing: In order to send a message to a Zone Of Relevance (ZOR), a Geocast protocol can be used. [6]

2.2 Radio Data System

In 1974, the European Broadcasting Union (EPU) started the development for a Radio Data System (RDS), an additional layer of information to be sent simultaneously with traditional FM signals [7]. Its primary purpose is to as-sist users in finding the station they are looking for and ensuring the best possible signal reception even under changing conditions when travelling in a car. By embedding digital data in the transmission of audio signals, stations can inform receiving radios about the name of the station, the type of the program, song titles, different frequencies of the same station, etc. Figure 2.4 shows a typical RDS-enabled car radio.

(24)

Figure 2.4: A typical RDS-enabled car radio (with RDS logo in the bottom left corner)

2.2.1 Physical Layer

The RDS IEC 62106:1999 Standard [8] defines the RDS signal as an ampli-tude modulated signal carried on a 57 kHz sub carrier. In some European countries, this frequency was used for a similar service called Autofahrer-Rundfunk-Informationssystem (german: Carradio Information System) (ARI). To not interfere with that service, both signals could be sent with a phase shift of 90◦. However, since ARI was basically rendered obsolete due to the wide acceptance of RDS, it was shut down on March 1st, 2005 [9].

2.2.2 Transport Layer

There are a total of 32 packages, divided into 16 types of group A and B, defined in the RDS standard [8]. Each group fulfils a specific purpose by transmitting a certain type of information at a fixed repetition rate. Table 2.1 lists the possible data fields and Table 2.2 what type of information is carried in which packet and how often it is sent per second. The required repetition rates can be translated into a packet ratio of 40% for type 0 A or 0 B, 10% for type 1 A or B, 15% for type 2 A or B, 10% for type 14 A or B and a remainder of 25% for all other packages.

(25)

10 CHAPTER 2. STATE OF THE ART Table 2.1: RDS Packet Overview [8]

Short Explanation

PI Programme Identification: Station identifier PTY Programme Type, e.g. News, Rock, Jazz, etc.

TP Traffic Programme: Specifies whether a station sends traffic announcements

PS Programme Service Name: Name of the station

AF Alternative frequency: Used when a station transmits on mul-tiple frequencies

TA Traffic announcement: Specifies whether current programme is a traffic announcement

DI Decoder identification: Programme metadata (Compressed, mono, stereo, etc.)

MS Music Speech: Specifies whether current programme is music or speech

RT RadioText: Additional text to be displayed on a radio

EON Enhanced other networks information: Allows radio to dy-namically change the station for example for traffic announce-ments on a different channel

Table 2.2: RDS feature, containing group and respective repetition rate [8]

Feature Group Type Repetition per second

(26)

(a) Group A

(b) Group B

Figure 2.5: RDS Message Type Structure

T Papp= T Ptotal· 25% = 296.8 b s T Pdata= T Papp· bppdata bpptotal = T Papp· 37 104 = 105.6 b s

Where T Ptotal is the total throughput of the Radio Data System,

T Papp is the throughput usable for an application,and

T Pdata is the actual payload throughput of application

pack-ages after subtracting bits reserved for PI, PTY, Checksum, etc.

bpp stands for bits per packet.

2.3 Media Access Control

Whenever several devices share the same communications medium, Media Access Control (MAC) strategies should be implemented to handle collisions. This section explains some of the basic MAC protocols.

2.3.1 ALOHA

(27)

Pure ALOHA

The original version of ALOHA, now referred to as pure ALOHA, was ex-tremely simple. The protocol can be summed up in the following two steps [11]:

1. If there is data to send, send it.

2. If foreign data was received while sending, a collision occured. There-fore, wait for a random period of time and then try again. (If listening while sending is not possible, acknowledgement packets (ACKs) are needed)

While this approach might work fine for networks with low traffic, its throughput decreases rapidly with increasing network load (see Figure 2.6). One simple but effective way of improving ALOHA is by introducing slots. Slotted ALOHA

In slotted ALOHA devices are no longer allowed to send at any time they want. Instead, time is divided into slots of equal length at least as long as the average packet time and devices must only start transmitting at the be-ginning of a slot. This improves the performance of the network quite a bit (Figure 2.6) but requires global synchronization between devices [11].

An obvious downside to ALOHA protocols is that they only listen to the medium during or after transmission, never before to check if the medium is free to send. Carrier Sense Mutliple Access (CSMA) introduces this feature.

2.3.2 CSMA

Pure CSMA works like ALOHA, with the addition of checking the channel before transmitting. There are some strategies defining what a device should do if it finds the channel busy [11]:

1. 1-Persistent CSMA: Keep listening until the channel is free. Then send immediately.

2. Nonpersistent CSMA: Wait for a random period of time. Then try again.

(28)

Figure 2.6: Performance comparison between ALOHA and CSMA protocols [11]

There are more advanced variations of CSMA (CSMA/CD, CSMA/CA, etc.) which further improve performance and reliability. However, they are designed for systems with much higher throughput than RDS offers and are therefore out of scope of this document.

2.4 Embedded Linux and Buildroot

Having an Operating System (OS) comes with a lot of benefits like a file system, a scheduler, a wide range of programmes and a Graphical User In-terface (GUI). This is great for general purpose systems like a PC with plenty of memory, CPU power and little to no concerns about energy consumption. However, most embedded systems are much less powerful and have a single specific purpose which often only requires essential features of an operating system like the file system and scheduler, while advanced components like a GUI are not needed.

Embedded Linux is therefore often used as an OS for complex embedded systems, as it is highly customizable and can be modified to exactly suit the needs of an application. In order to simplify this process, the tool Buildroot is able to generate a cross-compilation toolchain, a root file system, a Linux kernel image and a bootloader [12].

(29)

Pack-14 CHAPTER 2. STATE OF THE ART

(30)

Chapter 3 System specifications and

requirements

This chapter aims to outline the general project settings. This includes the given hardware, as well as the requirements the final protocol has to meet.

3.1 Available Hardware

As the networking functionality is but an add on to an already existing system, its hardware is already given, installed and could not be changed. Each node features:

• GRINN System on Module:

– CPU: ARM Cortex A7, 528 MHz, with built-in support for I2C, UART, eMMC, WiFi and other peripherals

– RAM: 256 MB of SDRAM DDR3, 400 MHz – Flash: 2 GB of onboard eMMC storage • Transmitters:

– 2x Adafruit SI4713 Stereo FM Transmitter with RDS/RBDS sup-port

• Receivers:

– 2x Sparkfun SI4703 FM Tuner Evaluation Board • GPS Device:

(31)

16 CHAPTER 3. SYSTEM SPECIFICATIONS AND REQUIREMENTS

3.2 Network Specifications

There are two categories of requirements the protocol should meet: Application– and network–specific. They are as follows:

Application-Specific

The network should be able to allow for three tasks, which are required by the application. The protocol has to assure that all three jobs are fulfilled at all times. While the functional requirements for the tasks are given below, their exact functionality is undisclosed.

• C : There must be an active C vehicle at all times. This task has to be fulfilled by the leading node.

• L2 : There must be an active L2 vehicle at all times. C can not be L2. Theoretically, any other vehicle in the network can become L2. However, the power needed for this task might differ between nodes and the network should be able to find the cheapest node available to do this task.

• A0 : There must be an active A0 vehicle at all times. This task repre-sents sending a warning message to nearby vehicles. To ensure that the message is received correctly, it is bound to a certain frequency. How-ever, it only requires audio signals so that RDS data can be embedded. Only C or L2 vehicles can become A0.

• V : Any node that is not responsible for one of the above tasks should remain silent and only send if necessary in order to conserve energy.

Network-specific

• It should be possible to start and stop the network on-the-fly when forming, joining and leaving a platoon, respectively.

• The network should be able to adapt to any change in topology within less than 10 s.

(32)

CHAPTER 3. SYSTEM SPECIFICATIONS AND REQUIREMENTS 17

(33)

(34)

Chapter 4 Network Layer

The first step in developing a protocol that fits all the demands made by the application, is to find the best network layer. This includes the topology of the network as well as messages that are to be sent between nodes. This chapter gives a summary over the design choices made in this regard.

4.1 Network Topology

In order to find the best suited network topology for the project, there are three points that are of importance. The first being the extremely low data throughput of RDS. Fulfilling the application’s networking demands with a reasonable reaction time is nearly impossible when using only a single chan-nel at 106 bits of payload per second. The second point is that RDS was designed for broadcasting. Sending one package at a time to a specific re-ceiver is therefore quite hard to achieve with available hardware. And finally, the application requires knowledge of the leading vehicle at all times.

As a result, a mix between topology based and broadcast routing over mul-tiple channels was deemed to be the best fit for the application.

(35)

20 CHAPTER 4. NETWORK LAYER

vehicles in the platoon follow this change at the same time, a special mes-sage is used: The Administration Mesmes-sage (ADM). It is broadcasted for a few seconds whenever a change in network topology is needed and contains one field for each task and a time stamp. A task field holds the ID of the node that should start the task at the time given by the time stamp. By using the time reported by every node’s GPS device, global synchronization of all nodes can be achieved.

Apart from the ADM, the master should also send Platoon State Mes-sages (PSMs) and Task State MesMes-sages (TSMs). While a PSM holds in-formation about the location, speed and direction of the platoon, a TSM informs about which frequencies to use for which channel and also how much power the L2 node currently consumes for fulfilling its task. This allows other nodes to send L2 Update (LUP) requests to the master, should they need less than a certain percentage of that power. PSM and TSM messages should be sent as frequently as possible to ensure fast reaction times of the network.

Should a node realize that it is in front of the current master (by compar-ing its own location, speed and direction to those transmitted in a PSM), it sends a Master Update (MUP) request. LUP and MUP are sent on their own channel, Channel 3, to which the master node should always be listening. Upon receiving a channel 3 message, the master will verify its validity and, once the request is approved, answer by issuing an ADM with the necessary changes.

In case of the L2 node, this works a little differently. Since this node is required by the application, the master should be able to notice its absence as fast as possible. To achieve that, the L2 node has to constantly send messages to the master node on Channel 2. Apart from letting the master know that a L2 vehicle is still in the platoon, these messages also hold infor-mation about this node’s location, speed, direction and power needed for the L2 task. This allows the master to immediately update a change of required power in its TSMs, or react to being overtaken by L2. Should the master not receive any messages from L2 for a certain amount of time, it will set the power field in its TSMs to 255 and, in case L2 was also A0, take over this task to reduce A0 dead time as much as possible. Setting the L2 power in a TSM to 255 causes all receiving nodes to immediately send a LUP as the maximum power L2 could theoretically require is less than that.

(36)

CHAPTER 4. NETWORK LAYER 21

is at most other void nodes around of which no information is known. The nodes therefore enter a state called orphaned (O) and have no other choice than to start a process that randomly selects one of them to be the new leader. As soon as this new master sends PSMs, all nodes will be able to calculate their new relative location in the platoon and send MUP messages if needed.

Since there is only one node sending on channel 1 and 2 at any given time, a media access control layer is not necessary. However, there are scenarios in which it is required to have multiple nodes try to send on channel 3 simul-taneously (e.g. when no L2 vehicle is around). To cope with that, having a MAC layer for this channel is critical. RDS is a pretty simple standard so available transmitters and receivers are usually not very powerful and the intended use case of RDS does not include sending single messages but rather having a set of frames that are broadcasted in a round robin fashion. Therefore, a simple MAC protocol might actually yield better results than an elaborate one like CSMA/CA, that requires sending lots of small messages in order to determine whether or not a node is allowed to transmit. Non-persistent CSMA was chosen to be the most appropriate protocol for this use case for its simplicity while still performing well in comparison to ALOHA. Not requiring globally synchronized time slots is another advantage.

A property of non-persistent CSMA is that when several nodes want to trans-mit a frame at the same time, it is completely random which of them gets to send first (due to a random back-off time, see the flowchart in Figure 4.1). This characteristic is also used as a means to randomize master selection in case void vehicles experience a channel 1 timeout. In essence, all nodes try to send a MUP and the first one to finish the transmission before receiving a Channel 1 message becomes the new master.

The graph in Figure 4.2 shows a simplified version of the state machine representing this behaviour.

4.2 Messages

(37)

22 CHAPTER 4. NETWORK LAYER Back Off start Check Medium Transmit Free Busy

Figure 4.1: Non-persistent CSMA Flowchart

messages per channel, this is enough.

The following subsections provide an overview of the messages used for munication between nodes and explain how certain fields have to be com-pressed in order to fit into the 5 byte messages.

Channel 1 Messages

Platoon State Message (PSM):

f l o a t L o n g i t u d e ; //! < Master GPS L o n g i t u d e f l o a t L a t i t u d e ; //! < Master GPS L a t i t u d e u i n t 8 _ t D i r e c t i o n ; //! < Master GPS D i r e c t i o n u i n t 8 _ t Speed ; //! < Master GPS Speed u i n t 8 _ t Time ; //! < Master GPS Timestamp

The Platoon State Message message is meant to inform nodes in the net-work about the current location, speed and direction of the platoon. As speed is given in km

h , a conversion should not be necessary for this field. Since a

negative speed is not possible, the highest value this field can express is 255

km

h , which is faster than most vehicles can go anyway. Converting time is

(38)

CHAPTER 4. NETWORK LAYER 23 void start O C L2 end CH1 Timeout ADM (C.ID) ADM (L.ID) MUP Sent CH1 Rx ADM (None) ADM (L.ID) CH2 Timeout ADM (C.ID) CH1 Timeout ADM (None)

Figure 4.2: The simplified simulation state machine. ADM (X) represents receiving a ADM where the node’s ID equals to X.

(39)

of about 100 to 200 m. Shifting by 5 bits is therefore required, allowing to represent distances of 2.5 m to 323.4 m for latitude and 3.5 m to 455.8 m for longitude between the sending and receiving vehicle.

An example of the encoding and decoding process is given in Table 4.1.

(40)

CHAPTER 4. NETWORK LAYER 25 Table 4.1: A GPS En-/Decoding Example

Encode: From GPS: 5919.6036 In Degrees: 59.326726 Milli-Degrees: 326726 BitMask: 0xff Shift 5: (0xff « 5) = 0x1fe0

Apply mask: (326726 & 0x1fe0) = 7232

Shift back: (7232 » 5) = 226 Send: 226 Decode: Own Location: 5919.8477 In Degree: 59.330795 Milli-Degrees: 330795 Encode own: 97 Receive: 226 Diff: (97-226) mod 256 = 127 Shift: (127 « 5) = 4064 Remote Milli-Degrees: 330795 - 4064 = 326731 Remote Location: 59.326731 Error: In Degree: 0.000005 ◦ In Meters: <1 m

Task State Message (TSM):

u i n t 8 _ t L2_Power ; //! < L2 Power

u i n t 1 6 _ t CHA_Freq ; //! < Channel A Frequency u i n t 1 6 _ t CH1_Freq ; //! < Channel 1 Frequency u i n t 1 6 _ t CH2_Freq ; //! < Channel 2 Frequency u i n t 1 6 _ t CH3_Freq ; //! < Channel 3 Frequency

(41)

which fits quite well into an 8 bit number. Administration Message (ADM):

u i n t 8 _ t Time ; //! < Time o f e f f e c t ( t 0 ) u i n t 8 _ t Master_ID ; //! < Master ID a f t e r t 0 u i n t 8 _ t L2_ID ; //! < L2 ID a f t e r t 0

u i n t 8 _ t A0_ID ; //! < Announcer ID a f t e r t 0 u i n t 8 _ t Checksum ;

The Administration Message is sent to inform nodes in the platoon about changes in the networks topology. Similar to the timestamp of PSMs, the ADM time is simply the time reported by the GPS modulo 256. IDs in the network are 8 bit so there is nothing to be done there. The checksum is used to verify the integrity of a received message. This is necessary because of the extreme importance of ADMs for the network. However, since there are already checksums provided by the RDS standard, a simple Fletcher checksum has proven to be sufficient. The algorithm is shown in Algorithm 1.

Algorithm 1 Fletcher Checksum Require: msg

let sum1 = 0 let sum2 = 0 for byte in msg do

sum1 = (sum1 + byte) mod 256 sum2 = sum2 + sum1

end for

return (sum1 + sum2) mod 256

Channel 2 Messages

L2 State Message (LSM):

u i n t 8 _ t ID ; //! < L2 ID

u i n t 8 _ t Power ; //! < L2 Announcer Power

u i n t 8 _ t Time ; //! < L2 GPS Timestamp

(42)

CHAPTER 4. NETWORK LAYER 27

The L2 State Message is meant to inform the master node about the current L2 node’s state. All of these values have already been covered in previous messages.

Channel 3 Messages

L2 Update (LUP): u i n t 8 _ t ID ; //! < ID o f S e n d e r u i n t 8 _ t Power ; //! < L2 Power o f S e n d e r u i n t 8 _ t Checksum ;

The L2 Update message is meant to inform the master about a more efficient L2 node. All of these values have already been covered in previous messages. Master Update (MUP):

u i n t 8 _ t ID ; //! < ID o f t h e new m a s t e r f l o a t L o n g i t u d e ; //! < L o n g i t u d e o f new m a s t e r f l o a t L a t i t u d e ; //! < L a t i t u d e o f new m a s t e r u i n t 8 _ t Time ; //! < Timestamp o f l o c a t i o n u i n t 8 _ t Checksum ;

(43)

(44)

Chapter 5 Application Layer

This chapter explains the steps that were taken to simulate and implement the protocol.

5.1 Simulation

In order to visualize and verify the functionality of the protocol during the design phase, to simplify the actual implementation and to test even com-plicated scenarios with many nodes, a network simulation tool was created using the scripting language Python. It featured a graphical representation of the platoon and all messages that were sent on different channels. All com-ponents were modelled with the actual system in mind on which the software had to be deployed later to ensure best possible compatibility. The goal of this was to find the state machines that would enable the system to fulfil all requirements.

While this could have been done directly on the Linux system, creating the simulation environment had the advantages of eliminating additional sources of error (hardware, other processes, etc.) and having superior debug possi-bilities.

In Figure 5.1 the graphical visualization of the simulated platoon can be seen. The number in the top left corner (1/100) is the simulation speed and display update rate (delay in ms between steps / simulation steps between display updates). As the simulation resolution is 1 ms, this is also the minimal delay between steps. Redrawing the interface requires quite a bit of resources so a value above 1 is recommended. In the top right corner the simulation time is displayed in ms.

(45)

30 CHAPTER 5. APPLICATION LAYER

give information about the current states of the different channel controllers with states being either ’listening’ or ’idle’ for ’CH12Rx’ controller, ’sending’ or ’idle’ for ’CH12Tx’ and ’listening’, ’backoff’, ’sending’ or ’idle’ for ’CH3’. Frequencies are either ’1’,’2’,’3’ or ’A’.

The red brackets below a node show its current state. Each of the application-specific tasks was turned into a state.

Figure 5.1: The graphical simulation interface

Once the simultation showed satisfying results for all relevant scenarios including up to five vehicles, the application state machines and conttrollers were rewritten in C and deployed to the actual system.

5.2 Implementation

(46)

CHAPTER 5. APPLICATION LAYER 31

means its code lies in the kernel region and gets executes with higher priority and more privileges than code in user space [13]. As a trade-off, a failure in a user space program is far less destructive than a failure in a kernel space program. While the former will in the worst case cause the process to crash, the latter might easily cause a kernel panic, resulting in a complete system shutdown.

Hardware interrupts are also only available in kernel space. Therefore, a system architecture as depicted in Figure 5.2 was chosen. Separate drivers for channel 1, 2 and 3, which all rely on hardware timers and interrupts re-side in kernel space. However, a node will never need to listen to channel 1 and 2 at the same time which is why a joined driver is sufficient here. The CH12Tx controller is used for sending on Channel 1 and 2. As this is a simple broadcast, a kernel module is not needed.

Network CH12 Tx User Space Kernel In terface CH12 Rx CH3 Ctrl PPS Ctrl Kernel Space Receiver 1 Transmitter 1 Receiver 2 GPS Transmitter 2 Hardware I2_C IRQ I2_C IRQ I2C PPS I2_C Serial

Figure 5.2: Overall Software Architecture

Loadable Kernel Modules

(47)

file, there are different predefined operations possible on a character device, such as open, close, write and read. All of these functions have to be im-plemented manually and can greatly differ from the functionality one would expect from a file. A KObject device on the other hand appears in the sys-tem as a directory in Linux’ /sys/ folder. An arbitrary amount of subfolders and files can be added by the developer. Each file can be equipped with a read and a write function which triggers a function call within the module. KObject devices have become very popular in recent years due to their ver-satility.

The KObject structure is also ideal for the channel drivers for the follow-ing reasons: All drivers can be put as subfolders into /sys/network_drivers and can be easily controlled from userspace. For example, Channel 1 needs to be able to change frequency. To allow that, a read/write parameter frequency can be added to the KObject by adding a frequency_store and a frequency_show function. While frequency_show simply returns an integer, frequency_store can interact with the receiver via I2C and tune it as desired. Table 5.1 lists all available driver parameters.

The drivers were designed as a single Loadable Kernel Module (LKM). Such a module can be loaded and unloaded during runtime using the insmod and rmmod command, respectively. Upon loading, static parameters can be passed to the module. This is useful for example to tell the drivers at which port a transmitter is plugged in.

5.3 Integration

One of the biggest challenges between running the network as standalone in a test environment versus running it in the final system, was that it needed to be able to recognize nearby nodes and start the network on its own. To achieve that, two properties of the system’s application were used:

a) The system is broadcasting an audio warning message

b) The system is constantly scanning the network and reporting Pro-gramme Identifications (PIs) of nearby stations

(48)

broad-CHAPTER 5. APPLICATION LAYER 33 Table 5.1: A complete list of all kernel driver parameters and their access rights (Read Only, Write Only or Read Write).

casted audio signal and using a fixed unique PI that isn’t used by any station1_,

the system was given the ability to detect other nodes nearby. In order to start the network however, both systems have to be aware of the other one. This can be assured by a simple handshake mechanism: Together with the systems Programme Identification, an eight bit number is transmitted. If a node is not in a network configuration this number should be zero. How-ever, as soon as one can receive another system’s messages, it should change that number to a random value between 1 and 255. As soon as both nodes transmit messages with a value not equal to zero, a network can be started with the master being the node that chose a higher number. See Figure 5.3

1_{This requires knowing all PIs in the area of deployment. However, as PIs are used to}

(49)

for an illustration: In the beginning, there is only one node A which, since it is transmitting a value of 0, is not in a network configuration. Next, Node B appears in transmission range, also sending a value of 0, indicating that it is not in a network. As soon as node A received node B’s messages, it starts transmitting a value of 127 (randomly chosen) instead of 0, indicating its willingness to start a network. Likewise, node B starts sending a value of 68 (also randomly chosen). Once A received this message, it knows that B is aware of A’s presence and also willing to start a network. Since A has chosen a higher number than B, A becomes the networks master node and starts sending PSMs and TSMs. This, in turn, tells B that a network has been started. A B 0 0 127 PSM TSM 0 68 68 NETWORK

(50)

Chapter 6 Verification and Tests

There were two major testing stage to ensure product integrity: in-lab and field testing. Both stages are explained in this section in detail.

6.1 Lab Tests

In-lab testing was a continuous process during development and implementa-tion of the protocol. By bypassing some funcimplementa-tions and inserting fake data, it was possible to simulate the network without physically moving the devices. Location was the most crucial data to be overwritten. In order to start the network in a controlled manner, detecting another device on a certain fre-quency could be simulated as well. Finally, one could change the L2 power for all devices individually. In order to conveniently do so, a GUI running on Python was created that was capable of fetching data from and writing data to files on the devices which were in turn read by the application. A picture of the interface is given in Figure 6.1.

6.2 Field Tests

(51)

36 CHAPTER 6. VERIFICATION AND TESTS

Figure 6.1: Graphical interface to simulate changes in the network.

Test 1: Changing Master

The aim of the first test was to see the network’s response to a following vehicle overtaking the leading node. See Figure 6.3 for a summary.

Node 1 was started ahead and out of range of node 0. The following vehicle then came closer until a network was established. In Figure 6.3b it can be seen that node 1 detected node 0 first and started the handshake (stage 2). Once node 0 also received messages, it did its part of the handshake, got a higher number and immediately started the master task (stage 3). After a short time, the nodes realized that node 1 should be master and switched roles. A stable network configuration was established (stage 4). Node 0 then proceeded to overtake node 1, which was detected almost immediately, causing another role reversal (stage 5). Finally, the distance between the vehicles was further increased to a point where the connection failed (around 20 m, stage 6). As soon as the nodes detected the absence of others, they first took over the master position (stage 7, Node 1: Switched from L2 to M aster + A0, asking for L2 vehicles; Node 0: Detected missing L2 and asked for new L2) and after not receiving any new messages, stopped the networking process entirely (stage 8).

Test 2: Changing L2

The aim of this test was to see the networks response to a vehicle changing required L2 power. See Figure 6.3 for a summary.

(52)

CHAPTER 6. VERIFICATION AND TESTS 37

Figure 6.2: Fieldtest Vehicles

(53)

38 CHAPTER 6. VERIFICATION AND TESTS

(a) Manoeuvre

Stage Description

1 Start devices out of range 2 Come closer until they connect 3 Wait for network to be stable 4 Following vehicle take over master 5 Wait for network to be stable

6 Let master pull away until connection breaks

7 Both nodes should become master

8 Wait for nodes to timeout and exit

1 2 3 4 5 6 7 8 inactive wait void orphanl2 l2+a0 master m.+a0 Stage 0 1

(b) States of both nodes

(54)

CHAPTER 6. VERIFICATION AND TESTS 39

(a) Manoeuvre

Stage Description

1 Start devices out of range 2 Come closer until they connect 3 Wait for network to be stable

4 Change power of node 1 to be lower than node 0’s 5 Wait for network to be stable

6 Let master pull away until connection breaks

7 Both nodes should become master

8 Wait for nodes to timeout and exit

1 2 3 45 6 7 8 inactive wait void orphanl2 l2+a0 master m.+a0 Stage 0 1 (b) Network response

(55)

(56)

Chapter 7 Discussion

As this document shows, it is possible to realize networking capabilities by using only RDS packages. However, this is probably only a feasible solution for a very small range of applications as there are some severe implications, which are discussed in the following subsection. Finally, Section 7.2 provides some insights into future development.

7.1 Problems and Possible Solutions

One of the biggest downside of the developed protocol is its high level of specificity and thus low expandability. Due to the low throughput of just above one hundred bits per second of payload, finding a way of allowing all nodes to communicate with one another is extremely difficult. Even networks that build on the 802.11p standard, which operates at 5.9 GHz with up to 27 Mbps1_{, seem to have a problem with throughput which is why geographic}

routing is generally preferred [6].

For that reason, RDS VANETs are only feasible for a very limited set of ap-plications with only few nodes that already use FM broadcasts. For all other applications, it might be recommendable to invest in a different technology.

Another problem is the high latency and hardware support. The RDS standard was designed with broadcasting radio stations in mind which

1_{That’s 270,000 times the throughput of RDS. It would take over an hour to send the}

(57)

42 CHAPTER 7. DISCUSSION

does not require transmitters to turn on, send one message and then turn off again. This type of functionality is therefore not supported by common RDS transmitters. To work around this, the best results could be achieved by sending a message for a certain amount of time and basically hope that at least one full package had been transmitted. One second of sending time has shown to result in a good reception rate. However, this technique in-creases the transmission time and thus latency by a factor of 10 compared to theoretical values. A custom transmitter, extended with a single message transaction feature could therefore achieve much better results.

Finally, regulatory restrictions should be mentioned. FM radio, and thus RDS, does not reside within the Industrial, Scientific and Medical (ISM) band and is therefore subject to strict regulations concerning transmission power, channels and more.

7.2 Future Work

The current state of the project is merely a prototype which hasn’t even been fully verified yet due to missing hardware. While tested in simulations and in lab with simulated inputs, the integrity of the protocol in a three and more node configuration remains to be proven in real life tests.

(58)

Bibliography

[1] Marie-Ange Lèbre, Frédéric Le Mouël, Eric Menard, Julien Dillschneider, and Richard Denis. Vanet applications: Hot use cases. Centre of Innovation in Telecommunications and Integration of services, 2014.

[2] Saleh Yousefi, Mahmoud Mousavi, and Mahmood Fathy. Vehicular ad hoc networks (VANETs): Challenges and perspectives. In 2006 6th International Conference on ITS Telecommunications. IEEE, jun 2006.

[3] Sabih ur Rehman, M. Arif Khan, Tanveer A. Zia, and Lihong Zheng. Vehicular ad-hoc networks (vanets) - an overview and challenges. Journal of Wireless Networking and Communications, 3, 2013.

[4] Xue Yang, Jie Liu, Feng Zhao, and N.H. Vaidya. A vehicle-to-vehicle com-munication protocol for cooperative collision warning. In The First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services, 2004. MOBIQUITOUS 2004. IEEE.

[5] Bijan Paul, Md. Ibrahim, and Md. Abu Naser Bikas. VANET routing proto-cols: Pros and cons. CoRR, abs/1204.1201, 2012.

[6] Harinder Kaur and Meenakshi. Analysis of VANET geographic routing proto-cols on real city map. In 2017 2nd IEEE International Conference on Recent Trends in Electronics, Information & Communication Technology (RTEICT). IEEE, may 2017.

[7] Why radio data system (rds)? https://www.beoworld.org/article_view.asp, April 2007.

[8] RDS Forum the association of RDS users. The new rds iec62106:1999 standard. IEC 62106, 1999.

[9] Das autofahrer-rundfunk-informationssystem wird abgeschaltet (in german). http://www.shortnews.de/start.cfm?id=562110, February 2005.

(59)

[11] Chen S. Elec3030 (el336) computer networks. University of Southampton. [12] Buildroot. The Buildroot User Manual, May 2018.

[13] A brief explanation of kernel space and user space.

https://www.fir3net.com/UNIX/Linux/what-and-when-is-kernel-space-and-user-space-used.html, May 2018.

[14] Writing a linux kernel module — part 2: A character device.

http://derekmolloy.ie/writing-a-linux-kernel-module-part-2-a-character-device, May 2018.

[15] Writing a linux loadable kernel module (lkm) - interfacing to gpios.

http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/, May

2018.

(60)

List of Abbreviations

ADM Administration Message . . . 20

ARI Autofahrer-Rundfunk-Informationssystem (german: Carradio Information System) . . . 9

BSP Board Support Package . . . 13

CSMA Carrier Sense Mutliple Access . . . 12

DTN Delay Tolerant Network . . . 7

EPU European Broadcasting Union . . . 8

GUI Graphical User Interface . . . 13

IEEE Institute of Electrical and Electronics Engineers . . . 3

ISM Industrial, Scientific and Medical . . . 42

LKM Loadable Kernel Module . . . 32

LSM L2 State Message . . . 26

LUP L2 Update . . . 20

MAC Media Access Control . . . 11

MANET Mobile Ad Hoc Network . . . 3

MUP Master Update . . . 20

ODA Open Data Application . . . 21

OS Operating System . . . 13

PI Programme Identification . . . 32

PSM Platoon State Message . . . 20

PTY Programme Type . . . 21

QoS Quality of Service . . . 3

RDS Radio Data System . . . 1

(61)

SDK Software Development Kit . . . 14

TSM Task State Message . . . 20

V2I Vehicle to Infrastructure . . . 4

V2V Vehicle to Vehicle . . . 4

V2X Vehicle to X. . . .4

VANET Vehicular Ad Hoc Network . . . 1

ZOR Zone Of Relevance . . . 8

(62)

TRITA-EECS-EX-2018:448

RDS-Based Intersystem Communication for Ultra-Low Data Platoon VANETs

RDS-Based Intersystem

Communication for Ultra-Low

Data Platoon VANETs

JONAS WALLMEIER

KTH Royal Institute of Technology

Information and Communication Technology

RDS-Based Intersystem Communication

for Ultra-Low Data Platoon VANETs

Jonas Wallmeier

Affidavit

Abstract

Abstract

Contents

List of Figures

List of Tables

Chapter 1

Scope and Motivation

Chapter 2

State of the Art

2.1

Vehicular Ad Hoc Networks

2.1.1

Types of VANETs

2.1.2

Routing

2.2

Radio Data System

2.2.1

Physical Layer

2.2.2

Transport Layer

2.3

Media Access Control

2.3.1

ALOHA

2.3.2

CSMA

2.4

Embedded Linux and Buildroot

Chapter 3

System specifications and

requirements

3.1

Available Hardware

3.2

Network Specifications

Application-Specific

Network-specific

Chapter 4

Network Layer

4.1

Network Topology

4.2

Messages

Channel 1 Messages

Channel 2 Messages

Channel 3 Messages

Chapter 5

Application Layer

5.1

Simulation

5.2

Implementation

Loadable Kernel Modules

5.3

Integration

Chapter 6

Verification and Tests

6.1

Lab Tests

6.2

Field Tests

Test 1: Changing Master

Test 2: Changing L2

Chapter 7

Discussion

7.1

Problems and Possible Solutions

7.2