ANALYSIS OF COMMUNICATION ARCHITECTURE OF GCDC 2011

MOHAMMADREZA KHAKSARI

This thesis is presented as part of Degree of Master of Science in Electrical Engineering

Bleknige Institute of Technology August 2011

Blekinge Institute of Technology School of Engineering Department of Telecommunication and Signal Processing Supervisors: Dennis Sundman, Royal Institute of Technology Dr. Henrik Pettersson, SCANIA CV AB Examiner: Dr. Jörgen Nordberg, Blekinge Institute of Technology

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

2 Abstract

This thesis report presents a method to analyze the communication architecture for the Intelligent Transportation Systems (ITS). The report also includes a case study on ASN.1 notation and analysis of its encoding rules. Included in the report is also: (i) accompanying instruction on how to use ASN.1 compilers to produce the C/C++ message encoder/decoder, and (ii) analysis of Non-IP communications of Communication Access for Land Mobiles (CALM-FAST) protocol stack in ITS. The thesis is a part of the research project entitled “SCOOP”, a joint project between SCANIA CV AB and KTH. Interested readers are referred to see scoop web site.1 The purpose of this thesis is to contribute to the ultimate goal, which is to equip a vehicle with necessary hardware and software technology to provide a platooning behavior in the GCDC 2011 competition. This goal is achieved by the means of wireless communication system for both vehicle to vehicle and vehicle to road side units communications in the platoon, [1]. Overall, this thesis introduces the important usage of ASN.1 in implementation of cut- edge telecommunication systems especially in V2V and V2I communication; and clarifies the CALM-FAST protocol stack in mobile nodes.

1 http://scoop.md.kth.se

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

4 Acknowledgments

I would like to express my gratitude to Prof. Magnus Jansson and Prof. Mats Bengtsson from KTH for giving me the opportunity to work on communication architecture of GCDC 2011. Specially, I would like to thank Dennis Sundman for his support, encouragement, discussions and comments on my thesis.

I would like to express my gratitude to Dr. Henrik Pettersson, SCANIA senior engineer, for sponsoring my thesis. I want to thank Dr. Jörgen Nordberg for taking responsibility of examining my thesis. Finally, I am forever grateful to my wife, Shirin, for her patience, endless love and support for my work. She moved with me to Sweden, she always stands by me, and she has given our life together so much happiness. Table of contents

Abstract ...... 3

Acknowledgments ...... 5

Table of contents ...... 6

Glossary ...... 8

Outline ...... 12

1. Introduction ...... 13 1.1 Background ...... 13 1.2 Purpose and Objectives ...... 14 1.3 Master thesis project phases ...... 15

2. Analysis of Encoded and Decoded GCDC Messages using ASN.1 Packed Encoding Rules ...... 16 2.1 Introduction ...... 16 2.2 Benefits of ASN.1 ...... 17 2.3 ASN.1 Encoding Rules ...... 19 2.3.1 Basic Encoding Rules ...... 19 2.3.2 XML Encoding Rules ...... 21 2.3.3 Packed Encoding Rules ...... 21 2.3.4 Encoding Rules Comparison ...... 23 2.4 The OSI Approach of ASN.1 ...... 24 2.5 ASN.1 Primary Type Definition ...... 24 2.5.1 ASN.1 Type Diagram ...... 24 2.5.2 The Constructor SEQUENCE ...... 26 2.5.3 The Type ENUMERATED ...... 26 2.5.4 The Constructor CHOICE ...... 27 2.5.5 The Type INTEGER ...... 28 2.6 Using the ASN.1 Compiler (ASN1C) ...... 29 2.6.1 Introduction to the ASN.1C ...... 29 2.6.2 Use of the ASN1C to compile GCDC.ASN1 ...... 31 2.6.3 A sample GCDC Message...... 32 2.6.4 PER Binary view ...... 33

3. Analysis of GCDC Communication Protocol Stack in Intelligent Transport Systems ...... 37 3.1 Introduction ...... 37 3.2 Introduction to Protocols ...... 38 3.3 CALM Communication Protocol Stack ...... 38 3.3.1 Application Block (Facilities layer) ...... 39 3.3.2 Network Block (Network and Transport layer) ...... 39 3.3.3 Physical / Link Block (Access Layer) ...... 39 3.3.4 CALM Management Block ...... 39 3.4 CALM Architecture ...... 40 3.4.1 CALM Service Access Point ...... 40 3.4.2 CALM Management ...... 41 3.5 CALM-FAST Frame Structure ...... 42 3.5.1 CALM-FAST Network Protocol Data Unit (NPDU) ...... 42 3.5.2 Network Header ...... 44 3.5.3 Transport Protocol Data Unit (TPDU) ...... 44 3.5.4 Service Table Advertisement (STA) ...... 45 3.5.5 Service Table context (STC) ...... 46 3.5.6 Data Exchange ...... 47 3.6 CALM-FAST Frame Flow ...... 48 3.7 GCDC Communication Protocol Stack ...... 49 3.7.1 Physical and Medium Access Control Layers ...... 50 3.7.2 LLC Layer ...... 50 3.7.3 Network Layer ...... 50 3.7.4 Transport Layer ...... 51 3.7.5 Session Layer ...... 51 3.8 GCDC Frame Structure ...... 51

4. Summary and Conclusion ...... 53

5. Future recommendation ...... 54

6. References ...... 55

7. Appendices ...... 57 7.1 Appendix 1- Generated Files from GCDC.ASN1 by using ASN1C .... 57 7.2 Appendix 2- Generated encoders/decoders for BER, XER and PER . 57 7.3 Appendix 3- Produced binary files by the test program ...... 57 7.4 Appendix 4- The TPDU of GCDC message ...... 58

Glossary

Access Layer – It is a block in CALM stack that specifies physical interfaces for different type of CALM protocol such as CALM-IR, CALM-M5, CALM-MM and CALM-FAST.

ACK – Acknowledgment. An acknowledgment in telecommunication is a signal passed between communicating processes to indicate acknowledgment.

ACTP – Assisted Communication Transactions Parameter

ADAS – Advanced Driver Assistant Systems

API – Application program Interface

A-SAP – Application Service Access Point

ASN.1 – Abstract Syntax Notation One. In telecommunications ASN.1 is used to present structure of data for representing, encoding, transmitting, and decoding.

ASN1C– ASN.1 Compiler

ASN1VE – ASN1 viewer /editor. It is a tool for viewing and editing ASN.1 notation.

BC-VCI – Broadcast Virtual Communication Interface

BER – Basic Encoding Rule

CALM - Communications Access for Land Mobiles

CALM-FAST – Non-IP communications of CALM

CALM-IR – Infra Red communications of CALM

CALM-M5 – 5 GHz frequency communications of CALM

CALM-MM – Millimeter waves communications of CALM Master of Science Thesis

CCH – Control Channel

CI – Communication Interface

CMIP – Common Management Information Protocol

C–SAP – Communication Service Access Point

CTS – Clear to Send

CVIS – Cooperative Vehicle Infrastructure Systems. It is an EU project.

DSAP – Destination Service Access Point

DSRC – Dedicated Short Range Communication

Facilities layer – It is a block in CALM stack that provides the services of the layers 5, 6 and 7 in the OSI model.

FCS – Frame Check Sequence

FWS – Fixed Wireless System

GCDC – Grand Cooperative Driving Challenge

GCDC.ASN1– An ASN.1 source file that specifies GCDC modules specifications.

HTAS – High Tech Automotive System. It is an automotive innovation European project.

HTTP – Hyper Text Transport Protocol

ICMP – Internet Control Message Protocol

ITS – Intelligent Transportation Systems

IWS – Infrared Wireless System

Lidar – Light Detection and Ranging

LLC – Logical Link Control

MAC – Media Access Control

MAP – Mobile Application Part

M-SAP – Media Service Access Point

MTP – Media Transfer Part

MWB – Mobile Wireless Broadband

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

9 Master of Science Thesis

NAV – Network Allocation Vector

Network and Transport layer – It is a block in CALM stack that provides data transmission and creates connection between application and physical media

NPDU – Network Protocol Data Unit

N-SAP – Network Service Access point

OBU – On-Board Unit

PDU – Protocol Data Unit

PER – Packed Encoding Rule

PLV – optional Preamble, optional Length and optional Value

PWS – Portable Wireless System

RAS – Remote Access Services

RSA – Rivest, Shamir and Adleman. It is a Public–Key Cryptography Standards.

RTS – Request to Send

RX-VCI – Receive Virtual Communication Interface

SAF – Service Advertisement Frame

SAFESPOT – It is an integrated research project co-funded by the European Commission Information Society Technologies to enhance driver perception of the vehicle surrounding.

SAP – Service Access Point

SCF – Service Context Frame

SCH – Service Channels

SNMP – Simple Network Management Protocol

SS7 – Signaling System 7

SSAP – Source Service Access Point

SSH – Secure Shell

STA – Service Table Advertisements

STC – Service Table contexts

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

10 Master of Science Thesis

TCAP – Transaction Capabilities Application Part

TCP – Transmission Control Protocol

TCP/IP – Transmission Control Protocol and the Internet Protocol

TLV – Type, Length and Value

TMN – Telecommunications Management Network

TNO – Nederlands Instituut voor Toegepaste Geowetenschappen. TNO is an independent research organization.

TPDU – Transmission Protocol Data Unit

T-SAP – Transport Service Access Point

TX-VCI – Transmit Virtual Communication Interface

UC-VCI – Unicast Virtual Communication Interface

UDP – User Datagram Protocol

UPER – Unaligned Packed Encoding Rules

V2I – Vehicle to Infrastructure

V2V – Vehicle to Vehicle

VCI – Virtual Communication Interface

XER – XML Encoding Rule

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

11 Outline

Chapter 1 presents the thesis background and connects it to the GCDC project2. It provides the purpose of the thesis and specifies objectives of the research. Moreover it gives an overview of work carried out during the project. In chapter 2 the encoding and decoding of GCDC messages are analyzed. The analysis has been done by introducing Abstract Syntax Notation one (ASN.1). Furthermore, the ASN1 compiler is introduced and an ASN1 viewer /editor (ASN1VE 2.1.3)3 is employed to study a sample GCDC message and to present binary view of a sample message. In chapter 3 the analysis of the GCDC communication protocol stack is done through study of the CALM communication protocol stack and CALM-FAST architecture. Moreover chapter 3 demonstrates GCDC 2011 communication protocol stack. Chapter 4 comprises a short summary and conclusion to the thesis. Finally, chapter 5 states essential future work to provide security of GCDC messages and to meet the bandwidth restriction of V2V and V2I communication in the platoon.

2 http://www.gcdc.net 3 http://www.obj-sys.com 1. Introduction

1.1 Background

The history of the grand cooperative driving challenge in GCDC organization goes back to 2008, when Netherlands Organization for Applied Scientific Research (TNO)4 suggested a series of technical competition for car producers and academic and research institutes to design an open cooperative autonomous driving system. The objectives of this idea were: (i) to accelerate the design of cooperative deriving, and (ii) to improve safety, productivity and comfort throughout driving. Then, in 2009, TNO and High Tech Automotive System (HTAS)5 initiated a challenge to take place in May 2011. They named the challenge grand cooperative driving challenge (GCDC), [1].

Cooperative driving provides technology for reducing traffic jams, limiting CO2 emission and preventing traffic accident. Furthermore cooperative systems provide the drivers, road authorities and the traffic infrastructure precise information about the vehicles, i.e. their location, intention, and traffic condition in urban and suburban areas.

Up to know the vehicles equipped with Advanced Driver Assistant Systems (ADAS) has helped driver by gathering information from in-car sensors that scan the vehicle‟s environment (i.e. radar and lidar). This information is based on autonomous and non-cooperative systems.

Nowadays, the rapid increase of vehicles and slow growing of roads has led to big traffic problems. To cope these problems, vehicles not only require to sense each other in the better way, but also they need to communicate intelligently with each other and road side units to exchange collected information and to report their reactions. The conveyed information in this way assists drivers and vehicle control systems to make better judgment in smoother and safer driving. The vehicles‟ smoother and safer behavior reduces congestion problems, resulting in: lower traffic jams, lower fuel consumption and lower emission. This level of smoothness and safety necessitates a data communication system based on: (i) short and fast on- demand control messages, and (ii) au Courant periodic messages, to provide dynamic information i.e. position, speed and direction of the vehicle. These messages make the foundation of data communication in Intelligent Transportation Systems (ITS), [2].

4 http://www.tno.nl 5 http://www.htas.nl Master of Science Thesis

Obviously, high transfer rates and low average delays are beneficial for this kind of real-time communications system in ITS. This is also the main reason for GCDC to choose CALM-FAST communication protocol for the 1st Challenge (GCDC), to be held in 2011, [1].

In GCDC, international teams will compete to do their most efficient cooperation in a Platoon. In GCDC, all vehicles have to communicate intelligently with other vehicles and road side infrastructures in order of forming this platoon.

In this thesis the communication architecture of GCDC messages in two phases is analyzed. In the first phase, encoding/decoding of messages in GCDC using ASN.1 Unaligned Packed Encoding Rules (UPER) is discussed. The second phase attempts to identify Non-IP CALM-FAST protocol stack in communication technology of GCDC. ASN.1 syntax is employed for this identification. Moreover, this part tries to elaborate what really happens to the data packet through transmission in CALM-FAST format, and how packets look like while they are sent out or received.

1.2 Purpose and Objectives

In this chapter the overall purpose and the specific objectives of this thesis are outlined.

The overall purpose of this thesis is to analyze communication architecture used in GCDC. Specifically, the encoding of messages in ASN.1 to generate a compact string of bits is described. Moreover, transferred bit strings over CALM-FAST communication stack for V2V and V2I communication are analyzed.

The aim of this thesis can be stated as two analyses covering two coherent objectives:

1) Encoding and decoding messages in GCDC

In a test the conveyed messages are studied to analyze how ASN.1‟s encoding rules encodes/decodes messages, how OSI approaches to ASN.1, how ASN.1 compiler works on ASN.1 specification of GCDC, and how messages are coded as raw data in terms of octet string and binary view.

2) Communication protocol in GCDC

In order to analyze the communication stack, the CALM-FAST protocol is broken down into parts then its architecture and frame structure is studied. Moreover GCDC 2011 communication protocol stack is surveyed to fix the GCDC frame to Transmission Protocol Data Unit (TPDU) of CALM-FAST protocol stack.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

14 Master of Science Thesis 1.3 Master thesis project phases

This chapter outlines the phases of the master thesis projects. It gives reader an overview of the analysis process. Table 3.1 summarizes phases and activities comprised in master thesis project without going into details.

Table 3.1 Master Thesis Project Phases Master Thesis Project Phase Activity -Literature Study -Inspection SCANIA‟s Test Track Initiation -WSU API Overview -GCDC Rules and Technology Overview -WSU Application Build Environment -UDP Socket Programming In C Practical Work -Workshop on 15 October 2010 -Immigration to ELDK Building Tools -UDP Over IEEE 802.11p Communication -Distinguish Wireless Task Content -Communication Logic Data Collection -Acceptable Max Delivery Latency -GCDC Forum -Encoded and decoded messages in GCDC Analysis -Communication protocol stack of GCDC Finalization -Presentation in SCANIA

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

15 2. Analysis of Encoded and Decoded GCDC Messages using ASN.1 Packed Encoding Rules

2.1 Introduction

Language originates from when early humankind started to communicate and to share their knowledge and experiences through social interactions. The social interactions obliged humans to acquire a common language. The common languages were used based on people‟s geography location and environmental situations. Similarly, different kinds of machine languages are used to exchange data among computers. It is necessary to decide upon common language for communication between peer computers or peer embedded computer systems such as vehicles. For computers a common language is referred to as a protocol. The protocol should be implemented in a platform-independent manner. The idea of having a protocol with platform- independent specification makes it straight forward to implement the protocol in different hardware/software systems.

Abstract Syntax Notation One (ASN.1) is an example of a platform- independent protocol. In the ASN.1, the notifications that define the structure of transmission are called Abstract syntax. Moreover, ASN.1 encodes/decodes messages before and after transmission under specific Encoding Rules. Finally, the transmitted data will be represented by a stream of octets under the Transfer Syntax6. Encoding Rules provide a relation between Abstract Syntax and Transfer Syntax. Abstract Syntax represents the data structure and Transfer Syntax describes the actual data presenting. The interaction between the abstract syntax and the transfer syntax is shown in Figure 2.1. Generally, this approach categorizes ASN.1 to three parts: Abstract Syntax, Transfer Syntax and Encoding Rules, [3].

6 The term OCTET is used as a standard by IETF and ISO to represent 8 bits Master of Science Thesis

APPLICATION_1 ABSTRACT SYNTAX APPLICATION_2

G G

N

N S S

I

I E E

D

D L L

O

O U U

C

C R R

N N

E E

TRANSPORT DATA TRANSFER SYNTAX TRANSPORT DATA

Figure 2.1: ASN.1 Interaction

With concern to Encoding Rules, Packed Encoding Rule (PER), as it was stated in [1] in particular is considered in analysis. Analyzing encoded message in ASN.1 is the main reason to focus on the encoding rules, in which compact strings of bits is derived from a clear message.

Although the focus of this chapter is attended to the PER, it also gives a technical comparison to two other encoding rules, the Basic Encoding Rule (BER) and the XML Encoding Rule (XER). This comparison is done in section 2.3.4.

2.2 Benefits of ASN.1 The most important benefit of the ASN.1 that motivated TNO to use it in GCDC is its platform-independent specification. ASN.1 is applicable in many devices around us such as cellular phones. It is used in a phone call, sending a message and changing cell zone from one cell to another one. ASN.1, with one of its predefined encoding rules, is introduced in establishing calls, managing messages, transferring control of calls between cells and verifies international calling cards.

Some advantages of ASN.1 are listed as follows:

 The communication architect can focus on exchangeable information to design protocol stack

 Messages can be exchange with more precise description

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

17 Master of Science Thesis

 The programmer can focus on substances of application instead of message‟s structure

 Freedom to chose suitable programming language for Application program Interface (API)

 Easy developing

 Proven technology

 Some international standards following ASN.1, are listed below, [3]:

- Signaling System 7 (SS7) Protocols suits (part of the GSM network) that are Media Transfer Part (MTP), Transaction Capabilities Application Part (TCAP) and Mobile Application Part (MAP)

- The H.323 family (VoIP Related Protocols) ,Remote Access Services (RAS), Q.931, H.245 and H.235

- Molecular Biology Standards

- Telecommunications Management Network (TMN) , Simple Network Management Protocol (SNMP) and Common Management Information Protocol (CMIP)

- T.120 Series Standards ( Data protocols for multimedia conferencing)

- Public-Key Cryptography Standards that is RSA (Rivest, Shamir and Adleman).

In addition to the current usage of ASN.1 some ongoing intelligent cooperative systems projects, Cooperative Vehicle Infrastructure Systems (CVIS7) and SAFESPOT8make benefit of it for their communications. They support both vehicle to vehicle and vehicle to roadside infrastructure communications. The CVIS project accumulates complete and up-to-date information about traffic hazards and congestion. This information enables traffic management system to provide personalized routing guidance, safety alerts and speed recommendation to the vehicles or group of vehicles in a certain area [4]. The SAFESPOT project collects dynamic information of vehicles and shares that information to enhance the drivers‟ conciseness of the vehicle surroundings, [5].

7 http://www.cvisproject.org 8 http://www.safespot-eu.org Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

18 Master of Science Thesis

In the GCDC project, messages are encoded in one of the compressed format of ASN.1, called Unaligned Packed Encoding Rules (UPER) that further will discussed in section 2.3.

2.3 ASN.1 Encoding Rules

ASN.1 encoding rules transform designated messages in the ASN.1 language to a special encoded format. Encoding Rules define how messages should be encoded when they are being sent and how they should be decoded when they are being received. As it has been discussed in section 2.1, ASN.1 convey messages between peers independent of (i) Hardware; machine architecture and (ii) Software; implementation language of Application Programming Interface (API). Initially, Encoding Rules of ASN.1 had a unit standard but then they became separated due to different BW and security requirements. Protocol designer take decision to choose one of the ASN.1 encoding rules based on their situation.

2.3.1 Basic Encoding Rules

The first and simplest encoding rule is the Basic Encoding Rules (BER) which specifies how data should be encoded through transmission according to prefixing tag of Type, Length and Value (TLV). Figure 2.2 shows the encoding/decoding processes of a particular message in BER.

Message Message Message Message BER (Encoded (Encoded BER (ASN.1 (ASN.1 Octets) Octets) Format) Encoder Decoder Format)

Figure 2.2 Basic Encoding Rules

Figure 2.3 shows a GCDC messages in ASN.1 format that is encoded to the octet string in BER.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

19 Master of Science Thesis

GCDCMessage ::= { header: GCDCHeader ::= { messageType: 2 (staticVehicleInfo) messageSequenceNumber: 6 messageTimestamp: Timestamp ::= { 0x30, 0x25, 0x30, 0x17, seconds: 6 0x0a, 0x01, 0x02, 0x02, milliseconds: 66 0x01, 0x06, 0x30, 0x06, } BER 0x02, 0x01, 0x06, 0x02, messagePriority: 4 (medium) Encoder 0x01, 0x42, 0x0a, 0x01, nodeID: 6 0x04, 0x02, 0x01, 0x06, nodeType: 1 (vehicle) 0x0a, 0x01, 0x01, 0xa2, } 0x0a, 0x30, 0x08, 0x30, payload: StaticVehicleInfoPayload ::= { 0x06, 0x02, 0x01, 0x42, vehicleSize: VehicleSize ::= { 0x02, 0x01, 0x42 width: 66 length: 66 } Encoded message in BER } } A sample GCDC message in ASN.1

Figure 2.3 a sample GCDC message in ASN.1 and BER

As it is shown, in which there are 39 transferred octets for a sample message in BER. Table 2.1 describes TLV concept and shows the octet string for this particular message.

The concept of TLV with the transferred octets is shown in Figure 2.2 and Table 2.1. In the first row of the Table and in first column, “0x30” specifies the type of the message, in second column “0x25” shows the number of octet as the length of message in hexadecimal of this particular example (0x25H is equal to 37), and third column shows the value in a string of octets.

Table 2.1 TLV representations

T L V (Type) (Length) (Value) 0x30 0x25 0x30, 0x17, 0x0a, 0x01, 0x02, 0x02, 0x01, 0x06, 0x30, 0x06, 0x02, 0x01, 0x06, 0x02, 0x01, 0x42, 0x0a, 0x01, 0x04, 0x02, 0x01, 0x06, 0x0a, 0x01, 0x01, 0xa2, 0x0a, 0x30, 0x08, 0x30, 0x06, 0x02, 0x01, 0x42, 0x02, 0x01, 0x42 0x30 0x17 0x0a, 0x01, 0x02, 0x02, 0x01, 0x06, 0x30, 0x06, 0x02, 0x01, 0x06, 0x02, 0x01, 0x42, 0x0a, 0x01, 0x04, 0x02, 0x01, 0x06, 0x0a, 0x01, 0x01, 0xa2, 0x0a, 0x30, 0x08, 0x30, 0x06, 0x02, 0x01, 0x42, 0x02, 0x01, 0x42 0x0a 0x01 0x02 0x02 0x01 0x06 0x30 0x06 0x02, 0x01, 0x06, 0x02, 0x01, 0x42 0x02 0x01 0x06

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

20 Master of Science Thesis

T L V (Type) (Length) (Value) 0x02 0x01 0x42 0x0a 0x01 0x04 0x02 0x01 0x06 0x0a 0x01 0x01 0xa2 0x0a 0x30, 0x08, 0x30, 0x06, 0x02, 0x01, 0x42, 0x02, 0x01, 0x42 0x30 0x08 0x30, 0x06, 0x02, 0x01, 0x42, 0x02, 0x01, 0x42 0x30 0x06 0x02, 0x01, 0x42, 0x02, 0x01, 0x42 0x02 0x01 0x42 0x02 0x01 0x42

2.3.2 XML Encoding Rules

XML Encoding Rules (XER) with human readable XML format of the sample message is shown in Figure 2.4. There are 644 octets that are used to transfer the sample message. See Figure 2.5.

Message Message Message Message XER (Encoded (Encoded XER (ASN.1 (ASN.1 Octets) Octets) Format) Encoder Decoder Format)

Figure 2.4: XML Encoding Rules

GCDCMessage ::= { header: GCDCHeader ::= { messageType: 2 (staticVehicleInfo)

messageSequenceNumber: 6 seconds: 6 6 } XER 6 messagePriority: 4 (medium) Encoder 66 nodeID: 6 nodeType: 1 (vehicle) } 6 payload: StaticVehicleInfoPayload ::= { vehicleSize: VehicleSize ::= {

width: 66 length: 66 } 66 } 66 } A sample GCDC message in ASN.1

Encoded message in XER

Figure 2.5: XML Encoding Rules

2.3.3 Packed Encoding Rules Fig 2.6 presents Packed Encoding Rules (PER). In PER, unlike BER, tags, length and values are not transmitted, since they are part of the protocol, and known by both peers. Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

21 Master of Science Thesis

Message Message Message Message PER (Encoded (Encoded PER (ASN.1 (ASN.1 Octets) Octets) Format) Encoder Decoder Format)

Figure 2.6: Packed Encoding Rules Instead of TLV format of the BER, PLV (optional Preamble, Length and Value) format is used in the PER, where the fields of P, L and V are series of bits. An example is shown in Figure 2.2 through Figure 2.4. In Figure 2.7 there are just 14 octets that transfer a sample message in Basic Unaligned PER.

GCDCMessage ::= { header: GCDCHeader ::= { messageType: 2 (staticVehicleInfo) messageSequenceNumber: 6 messageTimestamp: Timestamp ::= { seconds: 6 milliseconds: 66 0x20, 0x00, } PER 0x60, 0x00, messagePriority: 4 (medium) Encoder 0x00, 0x00, nodeID: 6 0x61, 0x0a, nodeType: 1 (vehicle) 0x00, 0x83, } 0x24, 0x21, payload: StaticVehicleInfoPayload ::= { 0x00, 0x84 vehicleSize: VehicleSize ::= { width: 66 Encoded message in PER length: 66 } } } A sample GCDC message in ASN.1

Figure 2.7: Packed Encoding Rules

PER is divided to two categories, Basic PER and Canonical PER. The Basic form encoder runs faster than Canonical form encoder. The Basic PER is divided to Aligned and Unaligned variants separately. In the Aligned variant, padding bits are inserted as the octet alignment, whereas the unaligned variant has not padding bits. Thus, the Unaligned variant is more compact than the Aligned variant, but encoding/decoding processes in unaligned is more time consuming. Similar to the Basic PER, Canonical PER is also divided to Aligned and Unaligned sub-methods. The Aligned and Unaligned cannot interwork and they are not able to decode each other‟s bit stream. The most compact form in PER is the Basic Unaligned and by decreasing size there are the Canonical Unaligned, Basic Aligned and finally Canonical Aligned variants.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

22 Master of Science Thesis

2.3.4 Encoding Rules Comparison The Encoding Rules (BER, XER and PER) play two roles in ASN.1. Firstly, they describe how to encode output messages of sender's proprietary Application Program Interface (API) by following their specific encoding rules. Secondly, they decode the transferred encoded messages and represent it to the receiver's API. These rules are completely independent of representation of the peer API.

In the Scoop project the BW is a major concern. A comparison of different encoding rules to contrast their capabilities is done as follow:

The size of encoded messages in BER is 50 percent in average higher than the message without encoding. On the other hand, PER shows average gain of 40 to 60 percents compression, [6].

With BW concerns the ideal transmission is one that is BW efficient. The PER conserves BW compares to XER and BER. It is used for audio and video over internet, air-ground communication, radio paging and wherever BW is at the premium. Relevant to section 2.3, PER uses 14 octets, BER uses 39 octets and XER uses 644 octets for sending a sample GCDC message.

The comparison between XER, BER, PER and actual data in term of size of the transferred sample message in octet, is shown in the graph 2.1.

700 644

600

500

Octets 400

300 200 100 19,5 39 14 0 Actual Data XML Encoding Basic Encoding Packed Encoding Rules (XER) Rules (BER) Rules (PER)

Graph: 2.1 Transferred sample GCDC message‟s size comparison Number of used octets to transfer the sample GCDC message PER is dedicated for protocols which transfer data in low BW communication. It obtains the most compact encoding.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

23 Master of Science Thesis

2.4 The OSI Approach of ASN.1 The Open System Interconnection model or OSI model is a well-known architecture in computer networking. The Figure 2.8 shows the status of Encoding Rules in OSI model.

APPLICATION APPLICATION

PRESENTATION ABSTRACT SYNTAX PRESENTATION

ENCODING RULES SESSION SESSION XER,BER and PER

TRANSPORT TRANSFER SYNTAX TRANSPORT

NETWORK NETWORK

DATA LINK DATA LINK

PHYSICAL 00000000 01100001 00001010 PHYSICAL

Figure 2.8: The OSI Approach of ASN.1 As Figure 2.8 has shown, Abstract Syntax has to provide a set of messages to predefine the structure of transferred data independent of user presentation. The independency in presentation means that each user (e.g. vehicle), uses its own applications to handle its local control system and local storage techniques of data. In contrast, peers use similar Transfer Syntax in their Transport layer. The Transport layer is responsible for delivering data to the appropriate application routine on the peer computers. It is easier for the appropriate application to work with data in a sequence of octets than unstructured data. Transfer Syntax specifies order and format of the data to be delivered over a physical transmission channel. Encoding Rules describes how Abstract Syntax collaborates with the transport layer to provide data objects which are the main part of the data structure, [3].

2.5 ASN.1 Primary Type Definition

2.5.1 ASN.1 Type Diagram Figure 2.9 presents primary types of ASN.1, [6].

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

24 Master of Science Thesis

TeletexString

NULL UTF8String

UTC Time

... IA5String

INTEGER

Character String VisibleString Miscellaneos BOLEAN

PrintableString (0- 9),(a-z),(A-Z) ENUMERATED

Basic NumericString (0- ASN.1 Types 9), REAL

SEQUENCE OF

Constractor OBJECT BIT STRING IDENTIFIER SEQUENCE

Object OCTETSTRING SET OF

OBJECT DESSCRIPTOR CHOICE

SET

Figure 2.9: ASN.1 Primary Types Figure 2.9 reveals that ASN.1 with its types is flexible enough to be regarded as a complex language in telecommunication. In the coming sections some types in ASN.1 are initialized to illustrate how they present their basic items. ASN.1 builds up its more complex types and structures by using the simple type and constructor definition. A message in ASN.1 format consists of (i) value reference; the name for that value which must begin with a lower case letter, (ii) value type; defines the type of the value and it is followed by “::=”, and (iii) value notation; assigns a valid value to each arguments of the value reference between curly bracket “{}”. A simple GCDC message in ASN.1 format is given in the following: vehicleSize VehicleSize ::= { Width 2 length 3 }

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

25 Master of Science Thesis

Above GCDC message defines “vehicleSize” as a value of type “VehicleSize” and assigns “2” to Width and “3” to “Length”.

This section introduces the simplest constructors and types in ASN.1.

2.5.2 The Constructor SEQUENCE The keyword “SEQUENCE” provides an ordered series of elements or components of different types. Those elements or components which follow SEQUENCE are called Identifier. An identifier begins with lower case letter.

The syntax is:

: : = SEQUENCE {

,

}

The corresponding constructor in GCDC is shown in Example 2.1.

GCDCMessage : : = SEQUENCE {

header GCDCHeader,

payload GCDCPayload

}

Example 2.1: The Constructor SEQUENCE

Example 2.1 comprises a value name (GCDCMessage), two identifiers (header and payload), and related types (GCDCHeader and GCDCPayload).

2.5.3 The Type ENUMERATED The type “ENUMERATED” declares the type of enumerations. The identifiers that come in curly bracket after ENUMERATED are separated by comma. ASN.1 provides an automatic numbering for the identifiers. The manual numbering of the state (numbers in arc bracket), are only provided for illustrational purposes.

The syntax is:

: : = ENUMERATED {

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

26 Master of Science Thesis

(0), (1), . . . . (n) }

The corresponding enumeration in GCDC is shown in Example 2.2.

NodeType : : = ENUMERATED {

Reserved (0), vehicle (1), rsu (2), trafficLight (3) }

Example 2.2

For instance using 1 for nodeType in the GCDC message of the sample GCDC message specifies type of the node as a vehicle.

2.5.4 The Constructor CHOICE The keyword “CHOICE” gives the choice between several alternatives. Identifiers begin with a lower case letter, while a value (number in the square bracket) is associated with each alternative identifier.

The syntax is:

: : = CHOICE {

[] , [] , . . . . [] }

The corresponding constructor in GCDC is shown in Example 2.3. [1]

GCDCPayload : : = CHOICE { dummy [0] DummyPayload, -- Not used dynamicVehicleInfoPayload [1] DynamicVehicleInfoPayload, staticVehicleInfoPayload [2] StaticVehicleInfoPayload, staticRSUInfoPayload [3] StaticRSUInfoPayload, Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

27 Master of Science Thesis rsuWorldModelPayload [4] RSUWorldModelPayload, rsuRelayPayload [5] RSURelayPayload, rsuRelayRequestPayload [6] RSURelayRequestPayload, rsuRelayReplyPayload [7] RSURelayReplyPayload, rsuRelayEndPayload [8] RSURelayEndPayload, vehicleSpeedIntentPayload [9] VehicleSpeedIntentPayload, platoonActionPayload [10] PlatoonActionPayload, trafficLightPayload [11] TrafficLightPayload, maxSpeedIndicationPayload [12] MaxSpeedIndicationPayload, mandatorySpeedProfilePayload [13] MandatorySpeedProfilePayload, challengeStatePayload [14] ChallengeStatePayload

} Example 2.3

2.5.5 The Type INTEGER The keyword “INTEGER” is used to show any positive or negative integer. The integer in ASN.1 language is similar to the number in Natural domain of mathematics.

The syntax is:

: : = INTEGER

The corresponding GCDC example is:

NodeID : : = INTEGER

It is possible to define intervals for the numbers by using maximum and minimum margin. Then the encoder/decoder knows beforehand the size of the data to be sent or received and can allocate necessary memory for sorting it.

In this case the syntax is:

: : = ()

And corresponding GCDC example (Example 2.4) is:

PositionAccuracy : : = INTEGER (-32768..32768)

Example 2.4

Although the type here is dedicated to INTEGER, it equally will be OCTET STRING, BIT STRING, BOOLEAN, REAL and ENUMERATED.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

28 Master of Science Thesis 2.6 Using the ASN.1 Compiler (ASN1C) ASN1C produced by Lev Walkin, that it was stated in [7], is employed to compile ASN.1 specification to C data structures during development and Run-Time processing (see section 2.6.1). The ASN.1 specification includes a collection of modules defined by the GCDC organization. Each module in ASN.1 consists of a type definitions and a constructor. Type definitions form a special tree corresponding to structure of GCDC messages. In this tree a GCDC message is located in the stem, while the type definition lists and defines all specification of that message. GCDC header and GCDC payload are two main branches of the message. These two parts are divided separately to some sub-divisions. The ASN1C provides functionality to encode/decode messages in Run-Time process.

2.6.1 Introduction to the ASN.1C The first purpose of ASN1C is converting the specification of ASN.1 notation to the programming language. The ASN1C reads the specification of ASN.1 and then extracts C corresponding structures and data types.

Example 2.5 shows a sub module of GCDC.ASN1 main module.

VehicleSizeTest DEFINITIONS ::=

BEGIN

VehicleSize ::= SEQUENCE {

width VehicleWidth,

length VehicleLength

}

VehicleLength ::= INTEGER(0..16383)

-- LSB units of 0.01 m

-- The length of the vehicle expressed in centimeters, unsigned

VehicleWidth ::= INTEGER(0..1023)

-- LSB units of 0.01 m

-- The width of the vehicle expressed in centimeters, unsigned

END

Example 2.5

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

29 Master of Science Thesis

The ASN1C compiles the ASN.1 sub module of GCDC (Example 2.5) to the C structure of Example 2.6.

/* VehicleSize */ typedef struct VehicleSize {

VehicleWidth_t width;

VehicleLength_t length;

/* Context for parsing across buffer boundaries */

asn_struct_ctx_t _asn_ctx;

} VehicleSize_t;

Example 2.6

The ASN1C also creates source files for encoding/decoding BER, XER and PER that will be used in run time to encode/decode messages to/from encoded octet.

The Figure 2.10 and Figure 2.11 show the process of ASN1C through Development and Run-Time processes.

Development process

ASN1 compiler

Figure 2.10: Development Process (reproduced from [3])

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

30 Master of Science Thesis

Runtime process

ASN1C Runtime Lib

Figure 2.11: Runtime Process (reproduced from [3])

2.6.2 Use of the ASN1C to compile GCDC.ASN1 Development phase

The development phase is made up of three parts: (i) Invoking the ASNC1 Compiler; by downloading ASN1C version 0.9.23 from the http://www.lionet.com and install it, (ii) Invoking ASN.1 source file (GCDC.ASN1); by downloading GCDC.ASN1 from the http://www.GCDC.net, (iii) Compiling; by using proper ASN1C command to compile the GCDC.ASN1 module.

The proper command that compiles GCDC.ASN1 module is shown as follow:

$ asn1c –fcompound–name –gen-per –pdu=all GCDC.ASN1

The -fcompound-names option disambiguates C's structure NAME's inside top-level types and the -gen-PER option generates PER support code. Finally the -pdu=all option generates Protocol Data Unit table.

Output Files

After compilation a number of .c and .h files are generated. These generated files are named corresponding to each message types that are defined in the GCDC.ASN1 specification which can be found in Appendix 1. The first group of generated files contains all the GCDC modules (structures of Header and Payload for each kind of GCDC messages).

The second group of generated files includes the set of Run-Time Libraries are listed as follows:  The .c files( the source files that provides the implementation for the classes declared in the generated headers)

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

31 Master of Science Thesis

 The .h files (the header files containing class definition and prototypes that will be included into the application program)  The encoders/decoders for BER, XER and PER, and other routines, see Appendix 2.

 Finally a Makefile that is useful for automake suit or plain make utility. Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards, [8].

Run-Time Phase

Invoking the ASN.1 helper code

A client code consist of the main routine to encode and decode messages is necessary. This client code includes vital header and helper files from the generated files of development phase. The header files predefine the structure of C program corresponding to GCDC.ASN1 definition of GCDC messages. Correspondingly, the helper files are used to encode/decode GCDC messages to/from series of binary files that are encoded in one of encoding format such as BER, XER and PER.

Output Files

For reference, a test program was created to produce binary files of coded messages. These messages were sent to other GCDC teams for comparison (see Appendix 3).

2.6.3 A sample GCDC Message

In this section, a survey of the generated binary files is provided for analysis of encoded GCDC messages. In particular, the per_StaticVehicleInfo message of GCDC that presents the width and the length of the vehicle in PER format, are survived. StaticVehicleInfo message sends the general GCDC message information as the header and specific vehicle size as the payload. The corresponding GCDC message format is shown in Figure 2.12.

Header Payload

Message Message MessageM esMsaegsesaTgi e Message StaticVehicleInfo Node ID Node Type Type Sequence NuTmimbeerstampmTesimtaemstpamp Priority Width Length

2 6 6 66 4 6 1 66 66

Figure 2.12: StaticVehicleinfo format

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

32 Master of Science Thesis

The value notation of the above message in ASN.1 is presented in Example 2.7.

GCDCMessage ::= { header: GCDCHeader ::= { messageType: 2 (staticVehicleInfo) messageSequenceNumber: 6 messageTimestamp: Timestamp ::= { seconds: 6 milliseconds: 66 } messagePriority: 4 (medium) nodeID: 6 nodeType: 1 (vehicle) } payload: StaticVehicleInfoPayload ::= { vehicleSize: VehicleSize ::= { width: 66 length: 66 } } } Example 2.7 a sample of StaticVehicleInfo message

The encoded message in PER UNALIGNED is 14 bytes. The xxd command in UNIX terminal shows the octet strings of encoded StaticVehicleInfo binary file as below:

0x20, 0x00, 0x60, 0x00, 0x00, 0x00, 0x61, 0x0a, 0x00, 0x83, 0x24, 0x21, 0x00, 0x84

2.6.4 PER Binary view

The binary view for the message in Example 2.8 is presented in Table 2.2. The GCDC header and payload for StaticVehicleInfo are analyzed furthermore.

Table 2.2 binary view for Example 2.8

StaticVehicleInfo Header Payload 0010000100001 00100000 00000000 01100000 00000000 00000000 00000000 00000000 01100001 00001010 00000000 10000011 001 10000100

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

33 Master of Science Thesis

The analyzing of the bit strings for GCDC Header and Payload is done in order in Table 2.3 and Table 2.5.

GCDC Message

The binary view of StaticVehicleInfo message, as a sample message in Example 2.7 with the simulation value, looks like Figure 2.13.

Header Payload

Message Message MessageM essMageesTsaimge Message StaticVehicleInfo Node ID Node Type Type Sequence NumTibmeerstamp eTstimamesptamp Priority Width Length

0000 00000000 0000000 0001 0 00100001 0000000 0010 0000 00000000 0110 00000000 10 0 10000011 01 000010 0 1000010 00000000 0 0110

4 bits 16 bits 32 bits 10 bits 3 bits 16 bits 2 bits 10 bits 14 bits

Figure 2.13: Analyzed Binary view for Example 2.7 GCDC Header

Table 2.3 exhibits the analyzing of header for corresponding GCDC message to Example 2.7. The assigned numbers to the type column are in decimal and the bit offset indicates the place of the first bit for the specific type in header.

Table 2.3: Analyzing of GCDC Header Header Type Binary Comments messageType:2 0010 Bit Offset : 0 (staticVehicleInfo) Number of Bits : 4 ASN.1 Type: ENUMERATED { reserved(0), dynamicVehicleInfo(1), staticVehicleInfo(2), staticRSUInfo(3), rsuWorldModel(4), rsuRelay(5), rsuRelayRequest(6), rsuRelayReply(7), rsuRelayEnd(8), vehicleSpeedIntent(9), platoonAction(10), trafficLight(11), maxSpeedIndication(12), mandatorySpeedProfile(13), challengeState(14) } Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

34 Master of Science Thesis

Header Type Binary Comments MessageSequenceNumber: 6 0000 Bit Offset : 4 00000000 Number of Bits : 16 0110 ASN.1 Type: INTEGER (0..65535) MessageTimestamp 0000 Bit Offset : 20 seconds: 6 00000000 Number of Bits : 32 00000000 ASN.1 Type: 00000000 INTEGER (0..4294967295) 0110 MessageTimestamp 0001 Bit Offset : 52 milliseconds: 66 000010 Number of Bits : 10 ASN.1 Type: INTEGER (0..999) messagePriority: 4 (medium) 10 0 Bit Offset : 62 Number of Bits : 3 ASN.1 Type: ENUMERATED { reserved(0), gcdc(1), emergency(2), high(3), medium(4), low(5) } NodeID: 6 0000000 Bit Offset : 65 10000011 Number of Bits : 16 0 ASN.1 Type: INTEGER nodeType: 1 (vehicle) 01 Bit Offset : 81 Number of Bits : 2 ASN.1 Type: ENUMERATED { reserved(0), vehicle(1), rsu(2), trafficLight(3) } GCDC Payload

Table 2.4 exhibits the analyzing of payload for corresponding GCDC message to Example 2.10.

Table 2.4 Analyzing of staticVehiclePayload Payload Type Binary Comments staticVehicleInfoPayload [2] 10 Bit Offset : 85 Number of Bits : 2 [2] StaticVehicleInfoPayload VehicleSize (width: 66) 0 00100001 Bit Offset : 87 0 Number of Bits : 10

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

35 Master of Science Thesis

ASN.1 Type: INTEGER (0..1023) VehicleSize (length: 66) 0000000 Bit Offset : 97 1000010 Number of Bits : 14 ASN.1 Type: INTEGER (0..16383)

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

36 3. Analysis of GCDC Communication Protocol Stack in Intelligent Transport Systems

3.1 Introduction Wireless communication refers to the communication technologies with radio waves, infrared and microwave. It is used to exchange data between portable devices. Mobile phones, portable computers, wireless computer networks, wireless routers, position detectors, satellite systems and wireless sensors are examples of the wireless communication.

Wireless technology enables devices such as vehicles to communicate while they are moving. Many business areas, including medical care, social and security services need to use wireless equipment as well. The wireless technology is expanding in order to reduce the communication costs. In comparison with wired networks, maintenance costs of wireless networks are low.

Wireless systems can be divided into three main categories: Fixed Wireless System (FWS), Portable Wireless System (PWS) and Infrared Wireless System (IWS).The FWS uses radio waves or a direct line of sight communication. These systems with their fixed antennas can be suitable substitutes for cable networks. The FWS is used for high-speed Internet connections and television broadcasting. The PWS is used for communication outside of building or between vehicles. Mobile phones, notebooks and navigators are some examples of this system. Finally, the IWS transmits data via infrared signals. This communication is usually used in remote control devices, motion detectors and personal computers. The reason to separate IWS from portable and fixed wireless system comes from the fact that IWS interacts between fixed and portable wireless systems. In IWS one communicator device is fixed and another can move.

An example of the PWS system is Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I) communication for Intelligent Transport Systems (ITS). The ITS uses a broad scope of wired and wireless communication technology to control and to exchange data within and between vehicles. The Communications Access for Land Mobiles (CALM-FAST) is one of the most important upcoming wireless technologies for intelligent vehicles that are discussed in this section. Master of Science Thesis

3.2 Introduction to Protocols Oxford, the world‟s most trusted dictionary, defines protocol term in the telecommunication field as “Computing a set of rules governing the exchange or transmission of data between devices”. The communication protocols define those rules and formats to exchange messages between units. For instance, in the computer‟s word vocabulary letter “P” in HTTP (Hyper Text Transport Protocol) stands for protocol. HTTP is an example of a protocol (language) for exchanging information between the server and the browser over the internet.

Nowadays, several protocols are used in the computer networks. TCP/IP (Transmission Control Protocol and the Internet Protocol ) is a well known protocol for exchanging data between IP based devices. It has been designed and implemented to transfer data and it consists of four layers, [9]. The concept of Layers in a communication system is a way to categorize communication tasks to smaller portions and then to obtain the task of each portion (Layer) in a detail. The higher layers receive services from lower Layers consecutively. Another example of a communication stack is the Open System Interconnection (OSI) communication stack model. Figure 3.1 shows OSI layers from the highest to the lowest layer. This model has 7 layers and most communication implementations can be generalized with this model, [9].

A P P L I C A T I O N

P R E S E N T A T I O N

S E S S I O N

T R A N S P O R T

N E T W O R K

D A T A L I N K

P H Y S I C A L

Figure 3.1: OSI Layers (reproduced from [1])

3.3 CALM Communication Protocol Stack The OSI model consists of 7 layers as shown in Figure 3.1. The layers from the highest to the lowest are: Application, Presentation, Session, Transport, Network, Data Link and Physical. In [1] it was stated that the OSI model has

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

38 Master of Science Thesis been considered as a reference to Communications Access for Land Mobiles (CALM).

The rules that provide interactions between communication layers are called Protocol Stack. Figure 3.2 presents four basic parts of CALM‟s protocol stack. These are: Application, Network, Physical / Link and CALM Management blocks. In the following these four major blocks are described.

Facilities Layer

Network & Transport Layer

Access Layer

Figure 3.2: CALM Protocol Stack (Reproduced from [11])

3.3.1 Application Block (Facilities layer) A single or a group of programs designed and compiled for the end user is called Application. The Application Block in CALM is responsible for interaction between the user application and the network layer. This block provides the services of the layers 5, 6 and 7 in the OSI model and it is called Facilities Layer.

3.3.2 Network Block (Network and Transport layer) The network block provides data transmission and creates connection between application and physical media. It plays the same roles of both layers 3 (Network) and 4 (Transport) of the OSI model. It is called Network and Transport Layer.

3.3.3 Physical / Link Block (Access Layer) The Physical/link block specifies physical interfaces for different type of CALM protocol such as CALM 3G and 4G (cellular network), CALM-IR (Infra Red), CALM-M5 (5 GHz spectrum), CALM-MM (Millimeter waves).

3.3.4 CALM Management Block The CALM Management Block provides functional management for the above three blocks (Layers). It receives the application‟s request, distinguishes possible routes and updates route table. Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

39 Master of Science Thesis 3.4 CALM Architecture The principle for the physical layer of the CALM standard, is to choose the “best” available communications media. The best communication media is defined by the physical media and its relative cost. It depends on what kind of media is available on the particular location and what kind of media support is fitted to the special object. This will vary from communication area and will change over time as a consequence of upcoming media technology. A few of well-known media are discussed in the following, [10]:

 Cellular wireless communication (3rd and 4th generation), which is expensive, compare to other medias, but its cellular network is available everywhere.  5.8 GHz Dedicated Short Range Communication (DSRC) more suitable technology for V2V and V2I communication. This technology is used in many countries nowadays and is called CALM-M5 (5 GHz).  Millimeter wave technology (63 GHz) gives communication opportunity in higher frequency. This technology with its high data rates and wide bandwidth can be combined with radar signal at the similar frequencies. It is called CALM-MM (Millimeter waves).  Infrared is used as a media in ITS for the high data rate and the lightweight communications. Briefly it is called CALM-IR (Infra-Red).  Mobile Wireless Broadband (MWB) exists wherever within urban area (such as WIMAX and WiBro).  Satellite communication. It is not a low cost media but it provides global communication. [10]

3.4.1 CALM Service Access Point The CALM architecture makes the application independent of the physical media that is used in communication. Figure 3.2 illustrates the CALM‟s layers corresponding to the OSI standard with the Service Access Point (SAP). The SAP distinguishes interaction between layers by identifying a label to the Protocol Data Unit (PDU) that specifies source and destination address for an interconnection between layers. The SAP is a concept to clarify the requested service between CALM layers. As it is shown in Figure 3.2 the SAP defines interaction between the four blocks in CALM architecture. Transport Service Access Point (T-SAP) connects the Application layer to the Network layer. The T-SAP provides an application for some services that realize communicating with a remote node. These services are outlined as follows:

 Socket creation and deletion  Transmission and reception of a data packet  Confirmation of transaction

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

40 Master of Science Thesis

A Communication-SAP (C-SAP) connects the Network layer to Physical/Link layer. The CALM Physical/Link layer comprises wireless or even wired communication interfaces.

3.4.2 CALM Management The CALM Management block uses a feature called Virtual Communication Interface (VCI) to manage CALM‟s layers. A VCI is a virtual substitute of a real Communication Interface (CI). A CI is the physical access media that was discussed in section 3.4. Each media has its specific communication properties. There are two types of VCIs:

 Transmit VCI (TX-VCI) that has its own set of physical/Link transmission parameters  Receive VCI (RX-VCI) with the common CI and share receive parameters

The CALM management can also define the mode of communication to a Broadcast (BC-VCI) to all or a Unicast (UC-VCI) to a single remote peer. This single remote peer is recognized by its Media Access Control (MAC) address. A MAC address is a unique address for each network interface (e.g. vehicle or mobile node). Figure 3.3 shows the unicast and the broadcast communication.

Unicast Broadcast

Figure 3.3: Unicast and Broadcast communication

The CALM management in order decides which media is the most suitable communication interface to provide necessary communication services. The decision depends on:

 Communication needs for the user application  Available communication interfaces  Properties and status of these communication interfaces  Requested policies

Firstly the CALM application requests certain communication functionality to the CALM management via Application SAP (A-SAP). The CALM Management forms “User application requirement list”. Then CALM communication interface sends selected routes to CALM management with

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

41 Master of Science Thesis respect to CI and VCI by way of Media SAP (M-SAP). Finally CALM management updates route table according to the selected route and in the network layer via Network SAP (N-SAP). [11] The CALM layer concept can be used by all type of CALM communication (i.e. CALM-Non-IP based and CALM-IP based). The CALM- FAST is the Non-IP solution with lower processing and lower latency. The CALM-FAST mode of operation enables very rapid transmission of short messages especially in V2V and V2I communications. In the next session the CALM-FAST structure is discussed. 3.5 CALM-FAST Frame Structure

3.5.1 CALM-FAST Network Protocol Data Unit (NPDU)

In the layered system of a protocol stack each layer assigns its specific protocol to the delivered data from higher layer and passes it to the lower layer. The descending data will be encapsulated through the layers. The encapsulation of data in each layer occurs by attaching a Header or Trailer, or both of them to the data of higher layer. The encapsulated data of each layer based on the specific protocol is called Protocol Data Unit (PDU). The layers of the protocol stack have their own individual PDU that is Network Protocol Data Unit (NPDU) and Transport Protocol Data Unit (TPDU). In the lower layers of the OSI model, physical and data link layer, the term of Frame is used analogously for PDU. The Figure 3.4 illustrates the position of NPDU in the physical frame of CALM-FAST protocol stack.

Physical Frame

Physical Header Physical Trailer

MAC Frame

MAC Header FCS

LLC PDU

DSAP SSAP Control address address NPDU

Figure 3.4: NPDU position in the physical frame

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

42 Master of Science Thesis

In addition, the Physical Frame (Figure 3.4) consists of a physical Header, a physical Trailer and a MAC frame. In the CALM-FAST protocol stack the physical Header and Trailer of the physical frame are specified in the IEEE 802.11p Draft 10.0 or newer specifications, [1]. The MAC Frame consists of a MAC header, a Logical Link Control (LLC) PDU and a Frame Check Sequence (FCS) for error detecting. Figure 3.4 shows the MAC frame and its substances. The LLC is the upper sub-layer of the data link layer in the OSI model. The LLC PDU consists of a Destination Service Access Point (DSAP) address field, a Source Service Access Point (SSAP) address field, a Control field and a Network Protocol Data Unit (NPDU). The SAP is introduced in section 3.6. It releases a label to a PDU to obtain the address of sender and receiver in CALM protocol stack. Then SSAP and DSAP stand for source and destination address for the LLC PDU. The Control comprises LLC header and must be compatible with IEEE 802.2 (IEEE 802 standard defining LLC), [12].

The NPDU is made up of Assisted Communication Transactions Parameter (ACTP), a Network Header and the Transport Layer Protocol Data Unit (TPDU) as it is shown in Figure 3.5. The ACTP is an optional header that assists the sender to set Physical, MAC and LLC parameters for transmission. In addition it reports those parameters to the receiver.

NPDU

ACTP Header Network Header

TPDU

Transport Header

PDU (STA, STC or Data Exchange) Figure 3.5: Data Position in NPDU

The Network Header comprises a sequence of optional and mandatory parameters. The TPDU contains a Transport Header and a specific PDU. They are described in the next paragraphs in order to provide a unified view of their content.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

43 Master of Science Thesis

3.5.2 Network Header

The mandatory part of the network header is made up of Protocol Identification and Net Header. The protocol identification enables several protocols work simultaneously together without interfering to each other. The Net Header consists of mandatory and conditionally optional elements (Header Extension) that are shown in Figure 3.6, [13].

Network Header

Net Header Header Extension s s e s D r s I

d e g l n r d o n o y i i d c t A t i d

d o a r r t n A n u a

o o i i c r t e w t e s c P r a r e S o n u i D F t o s S e D

Figure 3.6:Network Header (Reproduced from [11])

The mandatory part of the net header obtains source and destination addresses of the message. The header extension adds following optional parts to the network header, [11]: (i) Destination; provides routing destination to the network layer, (ii) Forwarding; provides forwarding message to the network layer, and (iii) Security is used to specify routing security to the network layer.

3.5.3 Transport Protocol Data Unit (TPDU) The TPDU in CALM-FAST is made up of a Transport Header and a PDU (see Figure 3.7). The contents of the transport header and the PDU change regarding to the broadcast communication, but every broadcast communication carry at least a single message type (messageType) in its transport header. Obviously the message type obtains the type of the message. There are three types of messages in CALM-FAST communication regarding to content of TPDU: (i) Service Table Advertisements (STA) advertise a table of available services of service provider, (ii) Service Table contexts (STC) show a table of required services of service user, and (iii) Data exchange that is incorporated in request and response pairs.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

44 Master of Science Thesis

TPDU

Transport Header PDU

STA e p y D I T e e

c STC i g v a r s s e s e

m DATA Exchange

Figure 3.7: TPDU Structure

The TPDU structure, mentioned above, is described in the next three paragraphs. The TPDU structure is shown in the Table 3.1, 3.2 and 3.3 using Abstract Syntax Notation One (ASN.1) syntax. The content of the TPDU in the coming tables is defined based on IEEE 1609, ETSI ITS and ISO TC204 WG16 standards, [13], [14], [15].

3.5.4 Service Table Advertisement (STA)

The Transport Header of TPDU in STA message consists of (i) a message type (messageType), and (ii) a service identifier (serviceID) that are described in Table 3.1.

Table 3.1: CALM-FAST TPDU Header for STA (Reproduced from [13]) Element Type Description messageType INTEGER(0-7) -- Service Table Advertisement: 0 serverID OCTETSTRING -- Indicates a unique identifier of a (SIZE (4)) service provider The PDU of STA message is described in Table 3.2

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

45 Master of Science Thesis

Table 3.2: CALM-FAST PDU for STA (Reproduced from [13]) Element Type Description srviceList serviceList ::= -- serviceID Indicates a unique SEQUENCE { identifier of a service provider serviceID INTEGER -- serviceData is depended on (0-127), service serviceData OCTETSTRING optional, serviceNWref -- serviceNWref is a pointer to INTEGER (0-255) location of local service optional, serviceChannel -- serviceChannel is used only if a INTEGER (0-255) channel is different to the optional advertisement } optional channelList channelList ::= -- serviceChannel is the same that is SEQUENCE { used in serviceList serviceChannel INTEGER (0-255), medium MedType, -- medium indicates type of schParams Communication Interface (CI) OCTETSTRING -- schParams is the medium specific } optional parameters of the reference serviceChannel including MAC address ipServList ipServList ::= SEQUENCE { serviceID INTEGER -- serviceID Indicates a unique (0-127), identifier of a service provider serviceData -- serviceData is depended on OCTETSTRING service optional, ipInfo SEQUENCE -- ipInfo is used for IPv6 protocol OF IpAddresInfo, serviceChannel -- serviceChannel is used only if a INTEGER (0-255) channel is different to the optional advertisement } optional ipPrefixInfo SEQUENCE OF -- Information on available IPv6 ipPrefixInfo optional prefix

3.5.5 Service Table context (STC)

The Transport Header in TPDU of STC message is similar to STA message but the integer “1” instead of “0”is used for the messageType in the STC (see Table 3.3).

The PDU of STC message is described in Table 3.3.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

46 Master of Science Thesis

Table 3.3: CALM-FAST PDU for STC (Reproduced from [13]) Element Type Description srviceContextList serviceContextList ::= SEQUENCE { serviceID INTEGER -- serviceID Indicates a unique (0-127), identifier of a service provider serviceContext -- serviceContext is depended on OCTETSTRING service and specify context of it optional, userNWref -- userNWref is a pointer to INTEGER (0-255) location of local service optional, } optional ipContext ipContext ::= -- Parameters IPv6 protocol of the SEQUENCE { service user during operation serviceID INTEGER phase (0-127), serviceContext OCTETSTRING optional, ipInfo SEQUENCE OF ipAddressInfo } optional ipPrefixInfo SEQUENCE OF -- Information on available IPv6 ipPrefix optional prefix

3.5.6 Data Exchange

The Transport Header of TPDU in Data Exchange message is similar to STA and STC message but the integer “5” is used for request without response, integer “6” is used for request with response and integer “7” is used for response in the messageType element (see Table 3.1).

The PDU of Data Exchange message is described in Table 3.4.

Table 3.4: CALM-FAST PDU for Data Exchange (Reproduced from [13]) Element Type Description data OCTETSTRING -- data dedicated to service

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

47 Master of Science Thesis

3.6 CALM-FAST Frame Flow

In CALM-FAST communication between two peers, one peer (person or software program) provides a service (Service Provider) and another uses that service (Service User) [11]. The process of providing a service in CALM- FAST takes two phase: service initialization phase and service operation phase. In the first phase, service provider advertises its available services through sending Service Advertisement Frame (SAF). The service user, based on its requirement, shows its interests to use the mentioned services and subscribe itself in to the list of available services by sending Service Context Frame (SCF). Then the operation phase starts. Figure 3.8 illustrates the service initialization phase. If a service user denies SAF and service provider is not acknowledged by a SCF, the service operation phase will start immediately after receiving SAF (see Figure 3.9).

Figure 3.8: Service provision using SAF and SCF (reproduced from [11]) With or without service user acknowledgment, service operation phase starts (The service operation phase is optional). Through the service operation phase communication happens in pairs of request and response messages. The direction of the requests and the responses in the service provision without acknowledgment is inverted of the service provision with acknowledgment. In the service provision without acknowledge while the service user became interested in a special service sends a request message to the service provider. Then service provider sends back the response in answer of requested service (see Figure 3.9).

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

48 Master of Science Thesis

Figure 3.9: Service provision without SCF (reproduced from [11]) In both of scenarios, the process of request/response is continued until all service transmissions are finished. [11]

3.7 GCDC Communication Protocol Stack There are some difficulties in order to apply CALM protocol and its additional CALM-specific module in GCDC communication. The CALM framework uses extra features i.e. TX-VCI, RX-VCI, B-VCI and U-VCI (see section 3.4.2) to communicate with a vehicle in ITS communication. Since a GCDC-specific message set appeared to be achievable, GCDC organization and SPITS designed a new framework for GCDC by adopting CALM-FAST framework architecture, resulting in GCDC interaction protocol, [1]. The implementation of GCDC communication protocol stack is based on the idea of the CALM communication protocol stack, in particular CALM-FAST in favor of IPv4. In this section, GCDC communication protocol stack based on CALM-FAST stack is discussed.

The GCDC stack with approach to ISO/OSI layers 1 through 5 (Physical layer through session layer), is summarized in Figure 3.10. The GCDC interaction protocol is used to define layer 6 (presentation layer) and each competitor in the GCDC 2011 competition is allowed to design his/her On-Board Unit (OBU) application based on cooperative driving logic, [1].

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

49 Master of Science Thesis

ISO/OSI GCDC

GCDC Application Application OBU, RSU

GCDC Interaction Presentation Protocol

CALM-FAST Session SAF, SCF

Transport CALM-FAST UDP TCP UDP TCP

Network CALM-FAST Ipv4 IPv6

Data Link 1 (LLC) IEEE 802.2

Data Link 2 (MAC) IEEE 80211.p D10

Physical IEEE 80211.p D10

Figure 3.10 GCDC communication stack(Reproduced from [1])

3.7.1 Physical and Medium Access Control Layers The Physical and Medium Access Control (MAC) Layers comply with the IEEE 802.11p Draft 10.0 or newer specifications. The (MAC-level) broadcast addressing is merely needed for GCDC; Since there is no Acknowledgment (ACK), Request to Send (RTS), and Clear to Send (CTS), so, there is no Network Allocation Vector (NAV) administration. MAC-level addressing is based upon the unique 48-bit permanent MAC addresses.

Each GCDC vehicle works in a ITS Control Channel (CCH) with 10 MHz bandwidth, and is equipped with a Service Channels (SCH) as an alternative for elusion to a different channel in case the traffic load is too high.

3.7.2 LLC Layer The LLC (Logical Link Control) Layer complies with IEEE 802.2.

3.7.3 Network Layer The Network Layer is divided into mandatory and optional parts. The mandatory network layer consists of the specification of CALM FAST and IPv6. In GCDC, IPv6 over IEEE 802.11p must be supported, but is not used during the actual challenge itself (It is needed for ICMP echo requests for connectivity tests and remote SSH access. Optionally, IPv4 is supported at

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

50 Master of Science Thesis the Network Layer. Network and transport addresses are fixed, and specified in [16].

3.7.4 Transport Layer The GCDC uses CALM-FAST, Internet Control Message Protocol (ICMP) support, User Datagram Protocol (UDP), and Transmission Control Protocol (TCP) over IPv6 as mandatory parts for the Transport Layer. Although, TCP and UDP over IPv4 are optionally used, All GCDC Transport addresses („ports‟) are fixed, and specified in [16].

3.7.5 Session Layer All GCDC nodes (vehicles and roadside unit) must support the periodic broadcast and/or exchange of CALM- FAST SAF and SCF frames (see section 3.6).

Table 3.5 shows GCDC messages with and without SCF service provision. Furthermore, it presents Frequency and reference of each GCDC message.

Table 3.5 GCDC Messages' properties

Frequency Reference

(Hz)

Sender Receiver

Message Name

SCF

1

10

RSU RSU

Vehicle Vehicle On demand On

DynamicVehicleInfo × × × × StaticVehicleInfo × × × × StaticRSUInfo × × × RSUWorldRepresentation × × × RSURelay × × × RSURelayRequest × × × × RSURelayReply × × × × RSURelayEnd × × × × VehicleSpeedIntent × × × × × PlatoonAction × × × × TrafficLight × × × MaxSpeedIndication × × × MandatorySpeedProfile × × ChallengeState × × × 3.8 GCDC Frame Structure There are 14 different types of GCDC messages which are named in Table 3.5 but 8 types of these messages will be used during GCDC 2011

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

51 Master of Science Thesis competition, [17]. The frame structure of these 14 messages has been also discussed in [17] and they set up the TPDU of GCDC stack based on CALM- FAST stack (see 3.5.3). Figure 3.11 illustrates TPDU of GCDC stack for the DynamicVehicleInfo message.

TPDU

GCDC Payload GCDC Header (DynamicVehicleInfo) p r y e m c b a a p n t r o m y m S e i u g y n t u t t a e t e i c n o i t a a r N i i c p c r m e t S e o d R y i i A i o e c p e a l l s D T r T n w n y I e e e o e n m P o a e e T i i c P V g o e H u Y t e d i c T i e e a e g q e t l l o d l e s l i s A e a c c c o n s s c o g e i i s i S i l o n e a s P h h e h h c s P e e i e g e e m e l s e a h v v v v l c m e s i e c s i v h m e h e m e v v Figure 3.11 DynamicVehicleInfo message The TPDU of GCDC message in ASN.1 syntax is detailed in Appendix 4.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

52 4. Summary and Conclusion

The analysis of encoded and decoded GCDC messages that was done in chapter 2 and comparison between our produced binary messages with the other Swedish communication teams (i.e. Chalmers and Halmstad universities) during workshop on 25-26 November 2010 in Gothenburg, shows that ASN.1 notation is flexible enough to be regarded as a complex language in the vehicular communications in the platoon. Moreover the analysis of GCDC communication protocol stack that was done in chapter 3, and evaluating of the exchanged GCDC messages with the Swedish communication teams during the integrated test, 22-24 of March 2011 in Gothenburg, suggests that up-coming GCDC protocol stack is suitable for communication between vehicles in the platoon to make a smoother and safe driving through the GCDC competition in May 2011. 5. Future recommendation

There are some challengeable perspectives for communication architecture of GCDC project in the future. On one hand, the necessity of robust communication systems to fulfill requirements of reliable mobile communication between vehicles (V2V), and vehicle and infrastructure (V2I) results in growth of GCDC messages and gives rise to more data collision based on allocated bandwidth of GCDC communication (10 MHz), [1]. Thus devising for alternative bandwidth seems necessary.

On the other hand, security of the message will affect the future of GCDC. Cooperative driving systems will exchange information which is relevant for automated decisions upon which the safety of human lives depends. Therefore, it is mandatory to ensure that no harmful intervention can threaten the health of road users and other traffic participants, [11]. Inevitably, the safeguard security adds extra load to the GCDC messages.

Accordingly, the GCDC and the other communication providers for vehicles are obliged to provide appropriate security and adequate bandwidth for their services. 6. References

[1] Jan D.J, “GCDC communications stack”, version 3, 16-01-2011.

[2] Katrin.B, Elisabeth.U, Erick.G “Medium Access Control in Vehicular Networks Based on the Upcomming IEEE 802.11p Standard”,2008.

[3] OSS Nokalva, Inc. ASN.1 Overview. [Online]. Viewed 2010 December 1. Available: http://www.oss.com/asn1/usage.html

[4] European Union DG INFSO. D.CVIS.3.2, High Level Architecture. [Online], Viewed 2011 January 10. Available: http://www.cvisproject.org.

[5] Abdel.K.M, Elena.B. (2010, May). D7.2.1 Core Architecture Requirements v 2.2. [Online]. Viewed 2010 November 10. Available: http://www.safespot-eu.org

[6] Olivier.D “ASN.1 - Communication between Heterogeneous Systems”, September 2000, Morgan Kaufmann Publishers, 588 p, ISBN: 0126333361-0.

[7] Lev.W, “Using the Open Source ASN.1 Compiler”, 2006 September 18.

[8] David.M, Tom.T, Alexandre.D.L, ”GNU Automake”, version 1.11.1, 8 December 2009.

[9] Forouzan, Behrouz.A. (2003).” TCP/IP Protocol Suite”, 2nd Ed, McGraw- Hill. ISBN 0-07-246060-1

[10] CALM Forum Ltd working in conjunction with ISO TC204 and ETSI ERM TG37. The CALM Handbook. version 3.(26-03-2006).[Online]. Viewed 2010 December 5. Available: http://www.tc204wg16.de.

[11] Information Society Technology. D31 European ITS Communication Architecture Overall Framework Proof of Concept Implementation, version 2.0.( 22-10-2008).[Online]. Viewed 2011 January 15. Available: http://www.comesafety.org.

[12] American National Standard Institute (ANSI). IEEE Standard 802.2. (1998 Edition (R2003)). [Online]. Viewed 2010 December 10. Available: http://ieeexplore.ieee.org. Master of Science Thesis

[13] Dr. Hans-Joachim Fischer. Basic Set of Communication Standards (CALM) on Common ITS Platform. (May 2010). [Online]. Viewed 2010 October 16. Available: http://isotc204wg16.org.

[14] IEEE. Family of Standards for Wireless Access in Vehicular Environments (WAVE). [Online]. Viewed 2010 December 10. Available: http://www.ieee.org.

[15] Elektrische Signalverarbeitung .The CALM protocol stack. [Online]. Viewed 2010 December 10. Available: http://www.etsi.org.

[16] Jan D.J, “GCDC Technology Workshop 2011/Q1”, Version 2.0, 29-10- 2010.

[17] Otto.B, Jan D.J, Arnoud V.N, Bart.N and Harry.W (TNO), “GCDC Interaction Protocol ”, Version 2.4, 08-05-2011.

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

56 7. Appendices

7.1 Appendix 1- Generated Files from GCDC.ASN1 by using ASN1C

DynamicVehicleInfoPayload.c, DynamicVehicleInfoPayload.h, GCDCHeader.c, GCDCHeader.h, GCDCMessage.c, GCDCMessage.h, GCDCPayload.c, GCDCPayload.h, MessageType.c, MessageType.h, PlatoonActionPayload.c, PlatoonActionPayload.h, PlatoonVehicleInfo.c, PlatoonVehicleInfo.h, RSURelayEndPayload.c, RSURelayEndPayload.h, RSURelayPayload.c, RSURelayPayload.h, RSURelayReplyPayload.c, RSURelayReplyPayload.h, RSURelayRequestPayload.c, RSURelayRequestPayload.h, RSUWorldModelPayload.c, RSUWorldModelPayload.h, StaticRSUInfoPayload.c, StaticRSUInfoPayload.h, StaticVehicleInfoPayload.c, StaticVehicleInfoPayload.h, TimeSpeedInfo.c, TimeSpeedInfo.h, TrafficLightPayload.c, TrafficLightPayload.h, VehicleSpeedIntentPayload.c, VehicleSpeedIntentPayload.h …

7.2 Appendix 2- Generated encoders/decoders for BER, XER and PER ber_decoder.c, ber_decoder.h, ber_tlv_length.c, ber_tlv_length.h, ber_tlv_tag.c, ber_tlv_tag.h, per_decoder.c, per_decoder.h, per_encoder.c, per_encoder.h, per_opentype.c, per_opentype.h, per_support.c, per_support.h, xer_decoder.c, xer_decoder.h, xer_encoder.c, xer_encoder.h, xer_support.c, xer_support.h

7.3 Appendix 3- Produced binary files by the test program xer_DynamicVehicleInfo, ber_MaxSpeedIndication, ber_PlatoonAction, ber_RSURelay, ber_RSURelayEnd, ber_RSURelayReply, ber_RSURelayRequest, ber_RSUWorldModel, ber_StaticRSUInfo, ber_StaticVehicleInfo, ber_TrafficLight, ber_VehicleSpeedIntent, Master of Science Thesis

per_MaxSpeedIndication, per_PlatoonAction, per_RSURelay, per_RSURelayEnd, per_RSURelayReply, per_RSURelayRequest, per_RSUWorldModel, per_StaticRSUInfo, per_StaticVehicleInfo, per_TrafficLight, per_VehicleSpeedIntent, xer_PlatoonAction, xer_RSURelay, xer_RSURelayEnd, xer_RSURelayReply, xer_RSURelayRequest, xer_RSUWorldModel, xer_StaticRSUInfo, xer_StaticVehicleInfo, xer_TrafficLight, xer_VehicleSpeedIntent, ber_ChallengeState, ber_DummyPayload, ber_DynamicVehicleInfo, ber_MandatorySpeedProfile, per_ChallengeState, per_DummyPayload, per_DynamicVehicleInfo, per_MandatorySpeedProfile, xer_ChallengeState, xer_DummyPayload, xer_MandatorySpeedProfile, xer_MaxSpeedIndication

7.4 Appendix 4- The TPDU of GCDC message

The PDU of GCDC message is detailed in Table as follows:

Element Type GCDCMessage GCDCMessage ::= SEQUENCE { header GCDCHeader, payload GCDCPayload } GCDCHeader GCDCHeader ::= SEQUENCE { messageType MessageType, messageSequenceNumber INTEGER(0..65535), messageTimestamp Timestamp, messagePriority MessagePriority, nodeID NodeID, nodeType NodeType } GCDCPayload GCDCPayload ::= CHOICE { dummy [0] DummyPayload, dynamicVehicleInfoPayload [1] DynamicVehicleInfoPayload, staticVehicleInfoPayload [2] StaticVehicleInfoPayload, staticRSUInfoPayload [3] StaticRSUInfoPayload, rsuWorldModelPayload [4] RSUWorldModelPayload, rsuRelayPayload [5] RSURelayPayload, rsuRelayRequestPayload [6]

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

58 Master of Science Thesis

RSURelayRequestPayload, rsuRelayReplyPayload [7] RSURelayReplyPayload, rsuRelayEndPayload [8] RSURelayEndPayload, vehicleSpeedIntentPayload [9] VehicleSpeedIntentPayload, platoonActionPayload [10] PlatoonActionPayload, trafficLightPayload [11] TrafficLightPayload, maxSpeedIndicationPayload [12] MaxSpeedIndicationPayload, mandatorySpeedProfilePayload [13] MandatorySpeedProfilePayload, challengeStatePayload [14] ChallengeStatePayload } DummyPayload DummyPayload ::= SEQUENCE { } DynamicVehicleInfoPayload DynamicVehicleInfoPayload ::= SEQUENCE { vehiclePosition Position, vehiclePositionTimestamp Timestamp, vehiclePositionAccuracy PositionAccuracy, vehicleVelocity Velocity, vehicleHeading Heading, vehicleAcceleration Acceleration, vehicleYawRate YawRate, platoonLeaderID NodeID, platoonState PlatoonState } StaticVehicleInfoPayload StaticVehicleInfoPayload ::= SEQUENCE { vehicleSize VehicleSize } StaticRSUInfoPayload StaticRSUInfoPayload ::= SEQUENCE { rsuPosition Position } RSUWorldModelPayload RSUWorldModelPayload ::= SEQUENCE { size INTEGER, entries SEQUENCE OF }

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

59 Master of Science Thesis

PlatoonVehicleInfo PlatoonVehicleInfo ::= SEQUENCE { vehicleID NodeID, platoonID NodeID, vehiclePosition Position, vehicleVelocity Velocity, vehicleHeading Heading } RSURelayPayload RSURelayPayload ::= GCDCMessage

RSURelayRequestPayload RSURelayRequestPayload ::= SEQUENCE { sourceVehicleID NodeID } RSURelayReplyPayload RSURelayReplyPayload ::= SEQUENCE { sourceVehicleID NodeID, willRelay BOOLEAN } RSURelayEndPayload RSURelayEndPayload ::= SEQUENCE { sourceVehicleID NodeID } VehicleSpeedIntentPayload VehicleSpeedIntentPayload ::= SEQUENCE { size INTEGER, entries SEQUENCE OF TimeSpeedInfo } TimeSpeedInfo TimeSpeedInfo ::= SEQUENCE { time Timestamp, velocity Velocity } PlatoonActionPayload PlatoonActionPayload ::= SEQUENCE { toNodeID NodeID, platoonLeaderID NodeID, platoonAction PlatoonAction } TrafficLightPayload TrafficLightPayload ::= SEQUENCE { trafficColour1 Colour, time1 Timestamp, trafficColour2 Colour, time2 Timestamp, trafficColour3 Colour, time3 Timestamp, trafficColour4 Colour, time4 Timestamp } MaxSpeedIndicationPayload MaxSpeedIndicationPayload ::= SEQUENCE { speedLocation1 Position, maxSpeed1 Velocity, heading1 Heading, speedLocation2 Position,

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

60 Master of Science Thesis

maxSpeed2 Velocity, heading2 Heading, speedLocation3 Position, maxSpeed3 Velocity, heading3 Heading } MandatorySpeedProfilePaylo MandatorySpeedProfilePayload ::= ad SEQUENCE { size INTEGER, entries SEQUENCE OF TimeSpeedInfo } ChallengeStatePayload ChallengeStatePayload ::= SEQUENCE { challengeID INTEGER, challengeState ENUMERATED { challengeStopped (0), challengePreparing (1), challengeActive (2), challengeActiveTest (3), challengeSuspended (4), challengeAborted (5) }

Mohammadreza Khaksari Telecommunication and Signal Processing, BTH

61