Vous êtes sur la page 1sur 119
Master’s degree in Telecommunication Engineering 2015-2016 Master´s Thesis “ A System for Vehicle Sensor Data

Master’s degree in Telecommunication Engineering

2015-2016

Master´s Thesis

A System for Vehicle Sensor Data Acquisition based on CoAP

Author: Marcos Soutullo Rodríguez Supervisor: Iván Vidal Fernández

Leganés, on 30 th of September 2016

Abstract

The continuous evolution of the Internet is currently enabling an ever-rowing availability of novel and appealing on-line services and applications. In this respect, with the simplification of wireless and wired communication electronics, being coupled to new and different on-line capable devices, we are witnessing a wide availability of connected nodes, which require the exchange of information with other devices and equipment, a concept that is currently being referred to as Machine-To-Machine. In this way, the Constraint Application Protocol (CoAP) is introduced as a Machine-to-Machine communication protocol recently standardised by the IETF and intended to be used as a simpler alternative to the Hypertext Transfer Protocol (HTTP) for connecting limited devices over constraint networks. Nevertheless, CoAP is not just a compressed version of HTTP with some extensions, CoAP is transported over UDP to simplify the network stack and provide a request/response interaction model between application endpoints, so far optimized to be small, light-weight and fast for these cutting-edge M2M and Internet of Things (IoT) applications

In this master’s thesis, we analyse the limitations and desired improvements of a current M2M deployment of an UK based company to track their fleet of vehicles. So that, we propose and design an autonomous M2M system based on CoAP to track a single vehicle and also identify its likely drivers. Finally, the real proof of concept is implemented using Python as main programming language and also validated.

Keywords: M2M, CoAP, GPS, NMEA, GPRS, vehicle, RESTful, data management, Python

“Believe you can and you are halfway there”, Theodore Roosevelt

Acknowledgments

Most of the time, there are not enough grateful words for all those people who were able to support and specially withstand me along this never-ending way. Nevertheless, I would like to particularly express my sincerest gratitude to those, who time to time, have been by my side;

- To my whole family, for their splendid and magnificent aid at making me feel stronger every

time I needed, specially to Nati, who always will be remembered from the deepest of my heart.

- To Nuria, for her continuous spreading of love, positivity and power of will with me.

- To Amaia, for her always constructive criticism and strong dedication.

- To my flat mates, Carlos and Alex, and Raul for their understanding and wonderful dinners.

-To my supervisors Ivan Vidal and Neil French for their expert advice and encouragement throughout the difficulties of this thesis.

CHAPTER 1

INTRODUCTION

1

1.1 MOTIVATION

1

1.2 OBJECTIVES

2

1.3 STRUCTURE

2

CHAPTER 2

STATE OF THE ART

4

2.1 THE ESSENCE OF M2M

4

2.2 M2M STANDARDISATION

6

2.2.1

ETSI M2M Technical Committee and Specification

7

2.2.1.1

M2M High-level architecture

7

2.2.1.1.1 Device and Gateway Domain

9

2.2.1.1.2 Network and Application Domain

9

2.2.1.1.3 Management

functions

10

2.2.1.2 M2M

Service Capability

10

2.2.1.3 M2M

Resource management

11

2.2.1.3.1 What is REST and why for M2M?

11

2.2.1.3.2 Resource structure

12

2.2.2 IETF M2M/IoT Working Groups

13

2.2.2.1 Constrained RESTful Environments. CoRE

14

2.2.2.2 Constraint Application Protocol. CoAP

15

2.2.2.2.1 Message format and transmission

16

2.2.2.2.2 Requests/Responses sublayer and semantics

18

2.2.2.3 CoAP suitability and other standard tracks

23

2.2.2.4 Open-source CoAP implementations

23

2.2.2.4.1

CoAPthon

24

2.2.2.5

Others M2M communication protocols

25

2.2.2.5.1 MQTT

25

2.2.2.5.2 XMPP

26

2.3

DATA MANAGEMENT

27

2.3.1 Data generation

27

2.3.2 Data acquisition, validation and storage

27

2.3.3 Data transmission, processing and remanence

27

2.4

M2M SMART VEHICLES AND GLOBAL POSITIONING SYSTEM

28

2.4.1

National Marine Electronics Association. NMEA Standard 0183

28

2.4.1.1 Electrical interface. Serial communication

29

2.4.1.2 Data protocol. NMEA 0183 Sentences

30

2.4.1.2.1 NMEA

GP-RMC

31

2.4.1.2.2 NMEA

GP-GGA

31

2.4.1.2.3 NMEA

GP-GSA

32

2.4.1.2.4 NMEA

GP-GSV

33

CHAPTER 3

SYSTEM ANALYSIS, REQUIREMENTS AND DESIGN

34

3.1

ANALYSIS OF AN EXISTING M2M SOLUTION

34

3.1.1 Current limitations

34

3.1.2 Desired improvements

35

3.2

NEW USE CASE SCENARIO

35

3.2.1

Stakeholders

36

3.3

SYSTEM REQUIREMENTS, SPECIFICATIONS AND DESIGN

37

3.3.1 General and functional requirements

37

3.3.2 M2M gateway and device specification

37

3.3.2.1 Authentication and identification scheme

38

3.3.3 M2M server and application specification

38

3.3.4 Assumptions and constraints

38

3.3.4.1 Communication network design

38

3.3.4.2 Energy

system management

38

3.3.4.3 System installation on the vehicle

38

 

3.3.5

Architecture, topology and information flow

39

CHAPTER 4

IMPLEMENTATION

40

4.1

HARDWARE IMPLEMENTATION

40

4.1.1 M2M gateway and GPS device

40

4.1.2 Communication access network

41

4.2 PYTHON AS MAIN PROGRAMMING LANGUAGE

42

4.3 M2M GATEWAY AND DEVICE IMPLEMENTATION

43

 

4.3.1 Initialise GPS device Application

45

4.3.2 Acquisition and validation of data

45

4.3.2.1 RMC data

Validation

46

4.3.2.2 GGA data Validation

47

4.3.2.3 GSA data Validation

48

4.3.2.4 GSV data Validation

48

4.3.3 Store data

49

4.3.4 Initialise CoAP server and resources

50

4.3.4.1 Instructions

resource

51

4.3.4.2 GPS data, specifications and satellite information resources

52

4.3.5 Initialise WAN

52

4.3.5.1

Initialize

SIM800L

53

4.3.5.1.1

Hard reset SIM800L

55

4.3.5.2 Check and Attach to GPRS

56

4.3.5.3 Check and Set UDP Extended Mode

58

4.3.6 Read input serial buffer

59

4.3.7 Send UDP datagram

61

4.3.7.1 Send UDP packet to serial port

61

4.3.8 Read UDP datagram

62

4.3.9 M2M Authentication and Driver Identification

63

4.3.10 Listen and process CoAP requests

65

4.3.11 Stop server and close GPS device application

66

4.4

M2M SERVER IMPLEMENTATION

67

4.4.1

Initialise CoAP client engine

69

4.4.1.1 Process CoAP messages

69

4.4.1.2 CoAP Requests. GET, POST and DELETE

70

4.4.2

Perform M2M security mechanism

70

 

4.4.3 Start automatic GPS data request

72

4.4.4 Initialise HTTP Web Server. CherryPy and Mako template

73

4.4.5 M2M Web RESTful application

74

CHAPTER 5

VALIDATION

76

5.1

GENERAL CONFIGURATION AND VALIDATIONS

76

5.1.1

Data management

78

5.1.1.1 Acquisition

5.1.1.2 Validation and Storage

GPS data

GPS data

5.1.2 WAN initialisation

79

79

80

5.1.2.1 Check and Attach to GPRS

82

5.1.2.2 Check and Set UDP Extended Mode

82

5.1.3 M2M Authentication and Driver Identification

83

5.1.3.1 Valid M2M server response

84

5.1.3.2 Forbidden M2M server response

85

5.1.4 Automatic data exchange

 

85

5.1.5 Keep-Alive message

87

5.1.6 M2M Web server application

88

5.2

TESTS ON A REAL VEHICLE

 

90

CHAPTER 6

CONCLUSIONS

AND FUTURE LINES

94

6.1 CONCLUSIONS

94

6.2 FUTURE LINES

95

6.2.1 Addition of other vehicle sensors to the system

95

6.2.2 Observing CoAP Resources

 

95

6.2.3 Enabling secure CoAP communications

95

6.2.4 Other improvements

 

95

APPENDIX A M2M GATEWAY AND DEVICE TECHNICAL SPECIFICATIONS

97

APPENDIX B COAP SERVER PYTHON CLASS DIAGRAM

101

APPENDIX C BUDGET

 

102

REFERENCES

104

LIST OF FIGURES

FIGURE 1: INFONETICS FORECAST [3] GLOBAL M2M SERVICE REVENUE TO 2017

1

FIGURE 2: INFONETICS FORECAST [4] FOR THE CONNECTED-CAR IN TERMS OF WORLDWIDE REVENUE

1

FIGURE 3 BASIC ARCHITECTURE OF A M2M COMMUNICATION

4

FIGURE 4: ADVANCE ARCHITECTURE OF A M2M COMMUNICATION. NUMBERS REPRESENT THE PROCESS OF DATA MANAGEMENT EXPLAINED

5

FIGURE 5: M2M - ETSI - HIGH LEVEL ARCHITECTURE

8

FIGURE 6: REFERENCE POINTS MAPPING TO KEY M2M ENTITIES

10

FIGURE 7: ADDRESSING A REST RESOURCE FROM A M2M SERVER TO A SENSOR IN A VEHICLE

12

FIGURE 8: EXAMPLE OF USE FOR SCL AND REST ARCHITECTURES WITHIN ETSI M2M ARCHITECTURE

12

FIGURE 9: TREE RESOURCE EXAMPLE OF ETSI TC M2M BY [13]

13

FIGURE 10: M2M IETF WORKING GROUPS AND SPECIFICATION SCOPE

14

FIGURE 11: CLIENT/SERVER PARADIGM IN A COAP COMMUNICATION

15

FIGURE 12: ABSTRACT LAYERING IN COAP BY [22]

16

FIGURE 13: COAP HEADER

17

FIGURE 14: OPTION FORMAT WITHIN A COAP MESSAGE [22]

18

FIGURE 15: COAP PROTOCOL PARAMETERS (LEFT) AND DERIVED (RIGHT) [22]

18

FIGURE 16: COAP METHOD CODES

19

FIGURE 17: COAP MEDIA TYPES DEFINED BY RFC-7252 [22]

19

FIGURE 18: COAP RESPONSE CODES [22] FIGURE 19: COMMON CASE OF A RETRANSMISSION FOR A CONFIRMABLE REQUEST WHICH IS PIGGYBACKED IN RESPONSE

20

(ACK) BY [22]

21

FIGURE 20: NON-CONFIRMABLE REQUEST FOLLOW BY A NON-CONFIRMABLE RESPONSE [22]

21

FIGURE 21: COAP OPTIONS AND NUMBER ASSIGNATION

22

FIGURE 22: COAPTHON IMPLEMENTATION ARCHITECTURE

25

FIGURE 23: MQTT MODEL AND PROTOCOL STACK FOR ITS SESSION DETAILS

26

FIGURE 24: MAIN XMPP ARCHITECTURE

27

FIGURE 25: HIGH LEVEL REPRESENTATION OF AN RS-422 CONNECTION NMEA GPS TALKER/LISTENER WITH ITS DIFFERENTIAL OUTPUTS OVER INTEGRATED ELECTRONIC CIRCUITS

29

FIGURE 26: SERIAL ASYNCHRONOUS COMMUNICATION BY [42]

30

FIGURE 27: RMC NMEA SENTENCE [41]

31

FIGURE 28: GGA SENTENCE [41]

32

FIGURE 29: GSA NMEA SENTENCE [41]

32

FIGURE 30: GSV NMEA SENTENCE [41]

33

FIGURE 31: CONCEPTUAL DEPLOYMENT DIAGRAM AND SCENARIO

36

FIGURE 32: PROPOSAL OF ARCHITECTURE, TOPOLOGY AND INFORMATION FLOW

39

FIGURE 33: RASPBERRY PI AND A GPS DONGLE ND-105C

40

FIGURE 34: SIM800L EVALUATION BOARD V2

41

FIGURE 35: SIM800L EVB CONNECTED TO THE RASPBERRY PI VIA PROTO-BOARD AND GPIO EXTENSOR

41

FIGURE 36: GATEWAY AND DEVICE APPLICATION ACTIVITY DIAGRAM

44

FIGURE 37: INITIALISE GPS DEVICE APPLICATION ACTIVITY DIAGRAM AND IMPLEMENTATION

45

FIGURE 38: ACQUIRE AND VALIDATE GPS DATA ACTIVITY DIAGRAM

46

FIGURE 39: RMC SENTENCE DATA VALIDATION AND ACQUISITION ACTIVITY DIAGRAM

47

FIGURE 40: GGA SENTENCE DATA VALIDATION AND ACQUISITION ACTIVITY DIAGRAM

47

FIGURE 41: GSA SENTENCE DATA VALIDATION AND ACQUISITION ACTIVITY DIAGRAM

48

FIGURE 42: GSV SENTENCE/S VALIDATION AND ACQUISITION ACTIVITY DIAGRAM

48

FIGURE 43: STORE GPS DATA ACTIVITY DIAGRAM

49

FIGURE 44: BACKGROUND INDEPENDENT PROCESS FOR DATA MANAGEMENT

50

FIGURE 45: TREE RESOURCE STRUCTURE

50

51

FIGURE 47: DEFINITION OF THE INSTRUCTIONS RESOURCE

51

FIGURE 48: DEFINITION OF THE GPS LOCATION RESOURCE AS AN EXAMPLE

52

FIGURE 49: WAN INITIALISATION ACTIVITY DIAGRAM

53

FIGURE 50: SIM800 SERIAL IMPLEMENTATION

53

FIGURE 51: INITIALISE SIM800 SERIAL PORT ACTIVITY DIAGRAM

54

FIGURE 52: SEND COMMAND AND CHECK RESPONSE SIM800 IMPLEMENTATION

54

FIGURE 53: SIM800 INITIALISATION PROCESS ACTIVITY DIAGRAM

55

FIGURE 54. RESET PIN TIME AND VOLTAGE AMPLITUDE VIL

56

FIGURE 55: HARD RESET SIM800L IMPLEMENTATION

56

FIGURE 56: GPRS CHECK ACTIVITY DIAGRAM

57

FIGURE 57: GPRS ATTACH ACTIVITY DIAGRAM

57

FIGURE 58: CHECK UDP EXTENDED MODE ACTIVITY DIAGRAM

58

FIGURE 59: SET UDP EXTENDED MODE ACTIVITY DIAGRAM

59

FIGURE 60: CHECKING INPUT SERIAL BUFFER IMPLEMENTATION

59

FIGURE 61: READ INPUT SERIAL PORT AFTER INITIALISING ACTIVITY DIAGRAM

60

FIGURE 62: SEND DATAGRAM DIAGRAM ACTIVITY DIAGRAM

61

FIGURE 63: SEND BIT STREAM PACKET VIA SERIAL PORT ACTIVITY DIAGRAM

61

FIGURE 64: READ UDP BUFFER ACTIVITY DIAGRAM

62

FIGURE 65: M2M AUTHENTICATION AND DRIVER IDENTIFICATION ACTIVITY DIAGRAM

63

FIGURE 66: DRIVER IDENTIFICATION IMPLEMENTATION

64

FIGURE 67: PAD FUNCTION IMPLEMENTATION

64

FIGURE 68: SHARED ENCRYPTION KEY BETWEEN M2M GATEWAY AND SERVER

64

FIGURE 69: ENCRYPT METHOD IMPLEMENTATION

64

FIGURE 70: UNPAD AND DECRYPT FUNCTIONS IMPLEMENTATION

65

FIGURE 71: LISTEN AND PROCESS COAP MESSAGES

65

FIGURE 72: LISTEN TO UDP PACKETS AND KEEP ALIVE DIAGRAM ACTIVITY

66

FIGURE 73: STOP SERVER AND CLOSE GPS DEVICE APPLICATION ACTIVITY DIAGRAM AND IMPLEMENTATION

66

FIGURE 74: M2M SERVER ACTIVITY DIAGRAM

68

FIGURE 75: PROCESS COAP MESSAGES ACTIVITY DIAGRAM

69

FIGURE 76: COAP GET REQUEST IMPLEMENTATION

70

FIGURE 77: SOCKET BIND ON THE M2M SERVER IP IMPLEMENTATION AND RECVFROM METHOD

71

FIGURE 78: M2M SECURITY MECHANISM ACTIVITY DIAGRAM

71

FIGURE 79: START AUTOMATIC GPS DATA REQUEST ACTIVITY DIAGRAM

72

FIGURE 80: GPS DATASET AND HEADERS INITIALISATION

73

FIGURE 81: FINAL GPS DATA REPORT IMPLEMENTATION

73

FIGURE 82: IMPLEMENTATION TO RUN THE HTTP WEB SERVER

74

FIGURE 83: JAVASCRIPT IMPLEMENTATION TO SHOW CURRENT POSITION AND SPEED OF A VEHICLE

74

FIGURE 84: FRONTEND IMPLEMENTATION FOR A M2M WEB APPLICATION SERVER

75

FIGURE 85: 7" TACTILE SCREEN APPEARANCE WITH ON-SCREEN KEYBOARD

76

FIGURE 86: RASPBERRY PI AND GPS USB

77

FIGURE 87: SIM800L MODEM CONNECTED TO THE RASPBERRY PI

77

FIGURE 88: RAW GPS DATA GENERATION

79

FIGURE 89: DEBUGGING RMC NMEA SENTENCE VALIDATION

79

FIGURE 90: DEBUGGING GGA AND GSA NMEA SENTENCES

80

FIGURE 91: LOCATION STORAGE IN JSON FORMAT

80

FIGURE 92: DEBUGGING SIM800L SERIAL INITIALISATION WITH ECHO ACTIVATED

81

FIGURE 93: DEBUGGING SIM800 SERIES AFTER HARD RESET

81

FIGURE 94: DEBUGGING A SUCCESSFUL GPRS BEARER SETTING

82

FIGURE 95: DEBUGGING SETTING UDP EXTENDED MODE

83

FIGURE 96: DEBUGGING FIRST CONFIRMABLE COAP MESSAGE

83

FIGURE 97: VERIFYING FIRST CONFIRMABLE COAP MESSAGE VIA WIRESHARK

84

FIGURE 98: VERIFYING ACK IN RESPONSE FOR THE FIRST COAP MESSAGE SENT BY THE M2M SERVER (CLIENT COAP)

84

FIGURE 99: DEBUGGING THE FIRST COAP MESSAGE FROM THE SERVER IN THE RASPBERRY PI

85

FIGURE 100: VERIFYING FORBIDDEN RESPONSE COAP FROM THE M2M SERVER

85

FIGURE 101: SPREADSHEET WITH GPS LOCATION DATA STORED IN THE M2M SERVER. EACH LINE CORRESPONDS TO ONE COAP RESPONSE PAYLOAD

86

FIGURE 102: EXAMPLE OF A SPREADSHEET WITH SATELLITE INFORMATION. SNR (DB-HZ), AZIMUTH AND ELEVATION DEGREES. EACH LINE CORRESPONDS TO THE INFORMATION OF ONE SATELLITE COMING FROM A COAP RESPONSE PAYLOAD

86

FIGURE 103:AUTO DATA REQUEST MODEL VERIFICATION FOR THE GPS/LOCATION RESOURCE

87

FIGURE 104: AUTO DATA RESPONSE MODEL VERIFICATION FOR THE GPS/LOCATION RESOURCE

87

FIGURE 105: VERIFYING KEEP-ALIVE MESSAGES

88

FIGURE 106: RETRIEVE CURRENT VEHICLE LOCATION VALIDATION. VEHICLE LOCATION AND SPEED

88

FIGURE 107: UPDATING THE INSTRUCTIONS RESOURCE

89

FIGURE 108: RETRIEVING THE INSTRUCTIONS RESOURCE

89

FIGURE 109: VALIDATION OF A CONFIRMABLE GET REQUEST

90

FIGURE 110: VALIDATION OF A DELETE REQUEST

90

FIGURE 111: M2M GATEWAY ON THE VEHICLE BEFORE STARTING TO DRIVE

91

FIGURE 112: PLANNED ROUTE FOR THE REAL VALIDATION

91

FIGURE 113: REAL GPS DATA OBTAINED FROM THE VEHICLE IN REAL TIME

92

92

93

FIGURE 116: DEAD POINT

93

FIGURE 117: RASPBERRY PI MODEL 3 [43]

97

FIGURE 118: RASPBERRY PI MODEL 3 GPIO LAYOUT

97

99

99

FIGURE 121: FUNCTIONAL DIAGRAM OF A SIM800L

100

LIST OF TABLES

TABLE 1: OPEN-SOURCE COAP IMPLEMENTATIONS

24

TABLE 2: COMPARISON BETWEEN COAP AND MQTT

26

TABLE 3: NMEA SENTENCE AND MEANING

30

TABLE 4: NAME AND DESCRIPTION FOR MAIN SENTENCES OF GLOBAL POSITION SYSTEM

30

TABLE 5: MAIN PYTHON LIBRARIES

42

TABLE 6: GPS DATA STORED IN JSON FORMAT

49

TABLE 7: USB GPS TECHNICAL SPECS

98

TABLE 8: DOWNLINK AND UPLINK THROUGHPUTS FOR THE CODING SCHEMES

99

TABLE 9: SIM800L MAIN FEATURES

100

TABLE 10: HARDWARE COSTS

102

TABLE 11: COAP MESSAGE TOTAL SIZE EXCHANGED VIA GPRS MOBILE NETWORK ON THE M2M GATEWAY

102

TABLE 12: SOFTWARE COSTS

103

TABLE 13: LABOUR COSTS

103

A System for vehicle sensor data acquisition based on CoAP

Chapter 1 Introduction

1.1 MOTIVATION

Machine-to-Machine (M-to-M or M2M) is a wide-term that refers to direct communication among devices via a communication network that do not necessarily require human interaction and generally is built of information and communications technologies able to measure, deliver and react upon some asset of interest [1]. In the last few years, M2M has attracted attention in many communities either as research groups or business companies, for which the number of connected devices is expected to be increased from almost 5 billion in 2016 until a forecast of more than 15 billion in 2020 [2]. Moreover, as per the Figure 1 depicts, M2M has been one of the fastest-growing and major new segments for service providers as well as the global revenue in 2017 will be duplicated since 2012 in terms of billions dollars.

will be duplicated since 2012 in terms of billions dollars. Figure 1: Infonetics forecast [3] global

Figure 1: Infonetics forecast [3] global M2M service revenue to 2017

Furthermore, many vehicle companies like insurance or fleet management have already installed and tested successfully M2M system on their own vehicles in order to reduce costs, enhance customer services, improve productivity and also analyse driver profiles. In fact, the connected- car is the second highest service to be boosted from 2015 until 2018 again in terms of revenue as the figure 2 shows:

until 2018 again in terms of revenue as the figure 2 shows: Figure 2: Infonetics forecast

Figure 2: Infonetics forecast [4] for the connected-car in terms of worldwide revenue

The motivation of this work started as a simple idea when I was working for a Driving Testing company in the United Kingdom and its vehicle fleet lacked of a proper system to be managed by other company employees, which aimed to collect driver records and the route followed per each vehicle in almost real-time.

Introduction

Hence, this idea become reality in terms of an actual master’s thesis that faces to explore existing M2M technologies and implementations to be applied into a specific case of retrieving relevant sensing data from a vehicle.

1.2 OBJECTIVES

The principal objective of this master’s thesis is to provide a feasible and reliable proof of concept for a communication system based on M2M technologies for a real company, which aims at improving its current old-style of M2M communication, retrieving relevant and real-time information from a GPS sensor located in the interior of a vehicle and also identifying its drivers.

Moreover, during the elaboration of this master´s thesis, other secondary objectives have been defined as follows:

Explore the state of the art in terms of existing M2M standards in communication from the most relevant Standards Development Organization (SDOs).

Review different and alternative implementations existing nowadays for retrieving sensing information.

Analyse how specially, the GPS data is generated and transmitted via GPS receivers as well as its peculiar data management procedures for acquisition, validation, storage, transmission and processing.

Develop two ways of communication defined by the final user; upon user-demand and gather data automatically.

Validate the entire implementation and data management process using proper verification tools and doing a small driving test on a real vehicle.

1.3 STRUCTURE

This master´s thesis is split into six different chapters including this one as are introduced below:

Chapter I. Introduction

It is the present chapter and aims at introducing the motivation, objectives and structure of the current master’s thesis targeted to conduct this final project.

Chapter II. State of the art

This chapter stipulates the most fundamental concepts about standardization bodies and technologies in the M2M field so far trying to explain those relevant concepts like the Constraint Application Protocol, principles of data management with a special focus on GPS data generation and acquisition as well as introducing M2M into the automotive industry.

Chapter III. System analysis, requirements and solution design

This chapter performs a system analysis of an early M2M deployment besides the main requirements and specifications of a M2M solution which considers a proof of concept for a continuous and real time communication between a gateway (vehicle) and a server.

A System for Vehicle Sensor Data Acquisition Based on CoAP

Chapter IV. Implementation

This chapter briefly describes what elements contain the M2M Gateway and device domain in order to deploy a real proof of concept that follows the solution and system requirements explained in the previous chapter. Moreover, it is described how both M2M gateway and server are implemented via Behaviour UML activity diagrams. In addition, small portions of code are included in order to endorse the implementation itself.

Chapter VI Validation

This chapter performs a sequence of different tests and validations to compare and verify the prior implementation in two different stages; general tests and a validation within the context of a real vehicle. Moreover, it checks possible gaps and confirms that the requirements exposed in the Chapter III were successfully achieved.

Chapter VII Future improvements and conclusions

This chapter includes a final overall assessment about this master’s thesis in terms of conclusions with the aim at summarising the most substantial achievements and the most significant improvements to be conducted after the detailed implementation

Moreover, other appendixes have been added to provide additional information to the reader.

Appendix A Technical specifications for GPS device, Raspberry PI and GPRS modem

This appendix includes some extra-technical information about the devices employed to implement the M2M gateway/device on the vehicle.

Appendix B Python class diagram for the CoAP server

This appendix shows a class diagram with its most important methods for the Python CoAP server developed over the M2M Gateway

Appendix C Implementation Budget

This appendix aims at providing an illustrative budget to implement this solution in a real vehicle

State of the art

Chapter 2 State of the art

This chapter summarizes the most fundamental concepts, standardization and technologies in the M2M field so far trying to explain those relevant concepts like the Constraint Application Protocol, principles of data management with a special focus on GPS data generation and acquisition as well as introducing M2M into the automotive industry

All the technologies described are used in this

2.1 THE ESSENCE OF M2M

The essence of M2M [5] is described such a simple bi-directional exchange of information between two entities via a communication network. So, it refers to those solutions that allow

communication between devices of the same type over a specific application, all via wired or
communication between devices of the same type over a specific application, all via wired or
wireless communication networks as a key role in the process. In this way, the device and the
application may be interconnected according to the basic architecture shown below in the Figure
3
Application
Communication
Network
Device/s

Figure 3 Basic architecture of a M2M communication 1

Unequivocally, the communication network has an important role in itself. For more complex systems, M2M configurations may involve a single or group of similar devices interacting with a unique or several applications and servers through a gateway if needed, as depicted in Figure 2. For instance, the M2M system solution is used to remotely monitor and control different enterprise assets in order to integrate them into an extra and useful management tool.

This way, there are several key components that must be clearly defined and included into any M2M solution or system. Hence, the following items should be considered in the explained for the above designed [6]:

M2M Device/s. These are the s responsible and standalone equipment attached to the asset of interest, which provide measurements and sometimes actuation capabilities. They have embedded electronic computing, sometimes communication capability against a Gateway and ranging from low-end sensor nodes to high-end complex devices.

1 Adapted and inspired version of [5]

A System for Vehicle Sensor Data Acquisition Based on CoAP

Gateway. It is the equipment with electronic computing and communication capability aimed at translating, sharing and transferring information between two types of entities, or aimed to perform some routing and multiplexing function between the two communicating entities.

Communication network. Its purpose is to provide remote connectivity between the M2M device or Gateway and the application-side servers. Many different network types can be used, and include both Wide Area Networks (WAN), Local Area Networks (LAN) or even capillary networks sometimes called as M2M Area Networks. A WAN example could be a public cellular mobile network or a satellite link.

Enterprise Process

(1) (1) (2) (4) M2M (1) Application M2M Device/s (3) M2M Service Communication Establishment Gateway
(1)
(1)
(2)
(4)
M2M
(1)
Application
M2M Device/s
(3)
M2M Service
Communication
Establishment
Gateway
(2)
Network
and Capabilities

Figure 4: Advance architecture of a M2M communication 2 . Numbers represent the process of data management explained below.

Service establishment and capabilities. Functions shared by different applications that expose several functionalities, which main goal is to reduce the cost for implementation, allow optimise applications of development and deployment and also, to hide network specificities. In addition, they could be generic or specific like the data storage and aggregation or the type of message delivery (Unicast/Multicast).

M2M Application and Enterprise processes. It encompasses all those developments or applications that perform a specific logic of service and usually use the Service Capabilities via open interfaces to gather data from the M2M devices and treat it afterwards.

In essence, there are four basic and common steps [7] performed by a communication of this type indicated with a number within a parenthesis; (1) Data generation and validation (2) transmission through the communication network, (3) assessment of the received data and (4) response to the available information either to the M2M devices or towards an enterprise process.

2 Adapted and inspired by [67]

State of the art

Despite, these M2M devices aimed to be represented in the above architecture are not a revolution in the world of Information and Communication Technologies (aka ICT). They share some specific characteristics when they are employed as part of a M2M solution:

Multitude and Variety. Huge amount of devices plus a yet undefined number of possible uses and cases where M2M solutions are suitable. It creates and increases the pressure over application architectures as well as over the network loading that in consequence generates scalability issues in systems that had been designed to accommodate greater levels and types of traffic [8].

Limited in functionality and low-powered. Its main reason must be driven by the cost of the device. Thus, M2M devices have less computational capabilities than other actual devices. Also, low power is required to ensure long operational life of the device, especially for those which size is limited, which have to be installed outdoors or with difficult access for manipulation and replacement. Low power is normally associated with devices limited in size. As a consequence, the embedded computational resources are restricted, limiting their capabilities and mostly M2M are not usually allowed for the broad sharing of data or connection to the Internet rather than offer a very specific service within the communication between the M2M Server and the M2M Gateway or devices

In addition to the above four main features, it is very important to consider the impact of other specificities of these devices that put additional constraints on the way they communicate in the network.

Invisibility and Criticality. Two critical capabilities, as many M2M devices have to routinely deliver their services with almost no human interaction, the device management result in a critical concept which must deal with the features and constraints explained above. For instance, they must act as life-savers such as in eHealth fields or as reliable vehicle intercommunication in order to avoid accidents acting and reading sensors [8].

Embedded and “here to stay” [5] A lot of devices are and most probably deployed in systems with operating conditions that make them difficult to change without a significant impact on the system itself. A good example is a system embedded (soldered) into a car engine that is hard or impossible to replace.

Also, general security and privacy are important aspects which needs to be treated very carefully per every end-point of the system. It means, authentication, authorization, data encryption and privacy are terms that must concern in the use of these solutions as well as they are being pushed at the top of the priority action list for M2M configurations

Nevertheless, apart from these features, a M2M communication could achieve many other distinctions, characteristics and requirements with the only premise that an exchange, analysis and validation of data is performed via a communication network from a device (or gateway) to a server.

The next chapter will introduce the standardization for M2M from a basic vertical architectural point of view and described by two recognized institutions, ETSI and IETF where a formal network topology is presented in order to establish a common way for development and deployment

2.2 M2M STANDARDISATION

Few years ago, there was common agreement that the M2M sector was lacked of standards, however the situation evolved since 2012 and although the level of maturity still differs depending on the standard segments. Standardization bodies such as ETSI (European Telecommunications Standards Institute), ITU (International Telecommunication Union),

A System for Vehicle Sensor Data Acquisition Based on CoAP

3GPP (3rd Generation Partnership Project) or IETF (Internet Engineering Task Force) are working toward unified architectures and protocols [9].

In the upcoming lines, there will be two clear aspects to consider in relation to the M2M standardization from a vertical perspective:

A standard based on physical and communication architecture introduced via the most common and accepted regulation body, ETSI

An innovated way and recommended specification issued by the IETF about how information should be carried across novel M2M implementations which follow an ETSI structural design

Therefore, the specifications of the two main and mentioned organizations; ETSI and IETF are going to be analysed in more detail in order to obtain a clear reference and simple starting point for this project

2.2.1 ETSI M2M TECHNICAL COMMITTEE AND SPECIFICATION

ETSI stands for European Telecommunications Standards Institute and is an officially recognized institution by the European Union which produces globally-applicable standards for Information and Communications Technologies (ICT), including fixed, mobile, radio, converged, broadcast and Internet technologies.

As per the definition of standard [10], every organization establishes specifications and procedures designed to maximize the reliability of the materials, products, methods, and/or services people use every day. Therefore, the business benefits become clear, reducing complexity and time of M2M deployments as well as lately reducing CAPEX and OPEX indicators. Concretely, the ETSI created a Technical Committee (TC) on M2M topics aimed at producing [11] a set of standards for communication among machines from an end-to-end viewpoint in 2009.

The specifications collected in the Release 1 published in 2012 are built upon proven and mature standards based on other specifications from such as the IETF, IEEE, 3GPP, the Open Mobile Alliance and the Broadband Forum. Therefore, it enables integration of different M2M technologies into a managed, unique and generic platform.

Like the first approach in the previous section, the first ETSI Technical specification highlights architectural components [11] including M2M devices, gateways with associated interfaces, applications and access technologies as well as M2M Service Capabilities Layers. They also offer security, traffic scheduling, device discovery and lifecycle management features. Accordingly, there are three publications that are going to be summarized and applied, in such a basic way, for the implementation of a proof of concept.

ETSI M2M - Requirements in ETSI TS 102 689 [12]

ETSI M2M - Functional architecture in ETSI TS 102 690 [13]

ETSI M2M - Interface descriptions in ETSI TS 102 921 [14]

2.2.1.1 M2M High-level architecture

The Figure 5 shows a high-level ETSI architecture very similar at previous figures, which combines both functional and topological views, showing well-differentiated groups and clearly associated with pieces of physical infrastructure (e.g. M2M Devices, Gateways) in addition to other functional groups (like M2M Service Capabilities) with lack of specific topological placement.

 
 

Network

and

Application

Domain

(NAD)

(NAD)
  Network and Application Domain (NAD) Device and Gateway Domain (DGD)  

Device and

Gateway

Domain

(DGD)

 
 

State of the art

User interface to application, Data bases, usage monitoring M2M Application Transport Network M2M M2M Core
User interface to application, Data
bases, usage monitoring
M2M Application
Transport Network
M2M
M2M Core
Management
functions
M2M Service capability
Core Network (CN)
Network
management
functions
Access Network (AN)
M2M
Application
M2M Service
capability
M2M Gateway
M2M
M2M Area
Application
Network
M2M Service
capability
M2M Device/s +
M2M
Gateway

DEVICE/S

Figure 5: M2M - ETSI - High level architecture 3

Principally, there are two differentiated main domains:

Network and Application Domain (NAD) and Device and Gateway Domain (DGD).

The boundary limit between them is the topological border between the physical devices, gateways and the physical communication infrastructure (Access Network). Then, a proper definition of each element must be provided with some extra detail regarding to the Technical Specification, i.e. (M2M Service Capability layers)

3 Inspired and adapted from [13]

A System for Vehicle Sensor Data Acquisition Based on CoAP

2.2.1.1.1 Device and Gateway Domain

Its main entities are defined as follow [13]:

M2M Device, as already defined, it is the device that runs a M2M application and contains a M2M Service capability, i.e. a device with a GPS sensor with some abilities to establish an autonomous connection towards a Network Domain via an Access Network either directly or through a Gateway. As per the Figure 5, two scenarios are distinguished:

o

Scenario 1 Direct Connectivity”. The entity (right bottom of DGD) performs registration, authentication, authorization, management and provisioning to the Network domain in a single pack without any M2M network. Therefore, it´s equipped with a Wired Area Network (WAN) communication module.

o

Scenario 2 “Gateway as a Network Proxy” 4 . The entity (left bottom of DGD) does not have the appropriate physical level in order to connect to the WAN, thus another kind of network comes up in order to provide the connectivity (layers 1 and 2 of OSI Model) between the M2M devices and a Gateway. It is called a M2M Area Network, being typically considered as a Local or Personal Area Network (PAN/LAN) wired or wireless and including technologies like IEEE 802.15.x (Bluetooth, ZigBee, …) or PLC, etc.

M2M Gateway, apart from its mentioned function as network proxy (direct connectivity between devices) and ensuring inter-working and connection between the M2M devices and the Network domain, a M2M Gateway may also run standalone applications, implement local intelligence for process activation and automation resulting from the collection and treatment of other source of information, such sensors (i.e. GPS sentences coming from a wired microcontroller and/or On Board Diagnostic interpreter)

2.2.1.1.2 Network and Application Domain

Its main entities are defined as follows [13]:

Access Network (AN), it is principally defined such a network that allows interconnectivity between the M2M device Gateway domain and the M2M Core. Some examples of technologies used here may go from wired and fixed (xDSL, optical fibres, …) towards most common wireless and wider solutions (UTRAN, GPRS, E-UTRAN, WLAN…)

Core Network (CN), out of this project scope, some core interconnections are 3GPP Core Network and ETSI TISPAN Core network. This network provides IP connectivity, Service and Network Control, Interconnectivity with other core networks and also, roaming.

M2M Service capability (SC), as per as the introduction to a M2M communication in previous paragraphs (see Service establishment), this layer expose functions to different M2M Applications through a set of open interfaces (mIa, mId and dIa), underlying the Core Network and performing an abstraction process in behalf of simpler applications. There will be a deeper explanation for this layer in the next paragraphs, called Capability Layer (CL) and made up other three layers; GS (Gateway Service)-CL, NS (Network Service)-CL and DS (Device Service)-CL.

M2M Applications, they run the service logic and use M2M Service capabilities functions including the back-end infrastructure responsible for collecting, analysing and storing any information received.

4 This model is the most extended due to its ability to interconnect low cost devices

2.2.1.1.3 Management functions

State of the art

In the high level architecture is easily to conduct a quick differentiation between the management functions (MF) of the Network and the MF of the M2M due to the first ones perform the provisioning (managing Access, Transport and core networks), supervision and fault management of the whole network, while the M2M management functions include two well-known roles as follows [15]:

M2M Service Bootstrap Function (MSFB). It facilitates the security credentials of a permanent bootstrapping or self-starting process that is supposed to proceed without an external input in the M2M device or Gateway and the M2M Service capability. Hence, it performs, among others, the provisioning of a M2M Root key (secret) to the M2M application or M2M device through the M2M Authentication Server.

M2M Authentication Server (MAS). It is the safe execution environment or trusted platform where permanent security credentials are stored.

2.2.1.2 M2M Service Capability

ETSI defines a M2M framework as a structured toolbox with a set of design patterns according to its proposed architecture [16]. The framework looks like a skeleton instantiated with a set of specific Service Capabilities (SC), whereby the reference points constitute initial placeholders for the protocols used to interact between the entities of the M2M system.

The following framework has been created with extensibility, adaptability and future-proof standardization in mind since not all capabilities are mandatory for an operational deployment. Straightaway, the application logic can be split into a Device Application (DA), Gateway Application (GA) or Network Application (NA). Also, the open interfaces or reference points are named as mIa, dIa and mId leading to the three and mentioned SCL. Hence, it is graphically shown in the Figure 6

Device and Gateway Domain (DGD) Network Domain (ND) Case 1 mIa Device Network Application (DA)
Device and Gateway Domain (DGD)
Network Domain (ND)
Case 1
mIa
Device
Network
Application (DA)
Application
(NA)
dIa
M2M Service
Bootstrap
mId
mIa
Function (MSBF)
DSCL
M2M Device (D
NSCL
Case 2
mIa
mId
Network M2M
Gateway
node
Application (GA)
M2M
Authentication
Device M2M node
dIa
Server (MAS)
Device
dIa
GSCL
Application (DA)
M2M Gateway (G)

Figure 6: Reference points mapping to key M2M entities 5

5 Inspired from [13]

A System for Vehicle Sensor Data Acquisition Based on CoAP

Briefly, the M2M interfaces (dIa, mId and mIa) can be defined as follows:

dIa It is the interface between either a DA and the D/G-SCL or a GA and the GSCL. Some basic supported functions are registration of either a Device/Gateway Application to the GSCL or a DA to the DSCL, request to read/write information to any (D/G/N)-SCL or perform the subscription and notification of specific events.

mId It is the interface between the NSCL and the GSCL or the DSCL. Some basic supported functions are registration of a Device/Gateway SCL to the NSCL, request to read/write information to any (D/G/N)-SCL or perform the subscription and notification of specific events.

mIa It is the interface between a NA, MSFB or MAS and the NSCL. Some basic supported functions are registration of a Network Application to the NSCL, request to read/write information to any (D/G/N)-SCL or request for device management actions, like software upgrades.

The next section will introduce the resource management process within an ETSI topology.

2.2.1.3 M2M Resource management

In this architecture, it is assumed that both reference interfaces (mId, mIa and dIa) will need to implement a Representational State Transfer (REST) communication paradigm through their respective applications (DA, GA and NA) and following the denominated Create, Retrieve, Update and Delete (CRUD) operations.

2.2.1.3.1 What is REST and why for M2M?

The Representational State Transfer (REST) is an architectural style defined by Roy T. Fielding in his PhD dissertation [17], which its main concept is that an indistinct number of distributed applications, made up of resources, (technically defined as stateful pieces of information residing on one or more servers [17]) are able to manipulate their content through a uniform and four basic operations: CREATE, READ, UPDATE and DELETE. Thus, each operation can be a request or response message. Also, the result of each operation is unchanged regardless of how many times the operation itself is repeated (in exception of CREATE).

Moreover, since the same set of operations (CRUD) can manipulate the most diverse kind of resources, there is no need for developing dedicated clients or infrastructures whenever the application domain changes. Therefore, the same underlying architecture can be reused for multiple applications.

Indeed, M2M is more about tangibles states and then, the technology needs to be more than a usual approach used when dealing with real states [18]. In other words, REST is the ideal method for Machine-To-Machine modelling, because every physical or logical entity is considered a resource that has a particular state and can be manipulated by another similar entity within the system.

M2M application Server State of the art M2M Application Resource Read (GET) request. Location? Resource

M2M application Server

M2M application Server State of the art M2M Application Resource Read (GET) request. Location? Resource state

State of the art

M2M Application Resource

Read (GET) request. Location?

Read (GET) request. Location?
Resource state response: GPS=xx.aaa,yy.bbb

Resource state response:

GPS=xx.aaa,yy.bbb

Figure 7: Addressing a REST Resource from a M2M Server to a sensor in a vehicle

Below is exposed the same paradigm within the ETSI architecture, but conducting the updating operation instead of a GET

Network Application (NA) Step 3 Read directly either from NSCL mIa Gateway or GSCL Databases
Network
Application
(NA)
Step 3
Read directly
either from NSCL
mIa
Gateway
or GSCL Databases
Application (GA)
mId
Device M2M node
NSCL
dIa
Step 2
dIa
Device
Notify or wait until
GSCL
Application (DA)
read
Step 1
Create or Update
Resource
Data Base at
M2M Gateway (G)

Figure 8: Example of use for SCL and REST architectures within ETSI M2M architecture 6

2.2.1.3.2 Resource structure

M2M service capabilities aim to provide data through different programmed functions, this standard defines the resource structure with a tree representation and tries to [13]:

Provide a powerful way for addressing resources and share them between M2M applications, using M2M SCs for data-mediation functions

Describe how the different types of resources are related to each other.

Improve the whole performance via the use of slightly structured data.

6 Considered that also the NSCL can perform other REST tasks like gather, publish or delete information in the DSCL/GSCL

A System for Vehicle Sensor Data Acquisition Based on CoAP

Therefore, the root of the hierarchical resource tree has a unique identifier and is defined as a generic name of the <sclBase> resource, moreover it contains all the other resources hosted by the SCL or M2M application.

In case of a RESTful implementation, the <sclBase> has an absolute URI (Universal Resource Identifier). Let´s say protocol://m2m.com/~sensors/Base” and refer to Figure 9: Tree resource example of ETSI TC M2M

The top level structure (<sclBase>) is represented within a rectangle and “<”, “>”

The different fonts used in the figure denote additional information in terms of properties.

Thus in this specific example, the unique and absolute resource <sclBase>. contains nattributes, just one scs resource which specifies the resource name and one property of each application, container, group, accessRight, subscription and discovery.

container, group, accessRight, subscription and discovery. Figure 9: Tree resource example of ETSI TC M2M by

Figure 9: Tree resource example of ETSI TC M2M by [13]

For more detailed and extended information about the complete ETSI M2M specification in terms of its Service Capability Layers, Interfaces and Resource Structure, please refer to the specification which was referenced many times above [13]

In the next paragraphs it is going to be summarized the responsible entity which standardizes Internet protocols for the management of resources stored in either Network, Device or Gateway applications or Service Capabilities Layers of a system which fulfils the already exhibited ETSI architecture.

2.2.2 IETF M2M/IOT WORKING GROUPS

The Internet Engineering Task Force [19] is an organized activity of the Internet Society which tries to produce high quality, relevant technical and engineering documents that influence the way people design, use and manage the Internet in such a way to make the Internet work better.

Powering the world of M2M, the first IETF IoT working group [20], IPv6 over Low-power WPAN (6LoWPAN), was founded by March 2005 and it started to define some methods for adapting IPv6 to IEEE 802.15.4 (WPAN) networks that use very small packet sizes by means of header compression and optimizations for neighbour discovery. Although, this working group settled in

State of the art

2014, and there was born the 6Lo WG that actually applies similar adaption mechanisms to a wider range of radio technologies like Bluetooth Low Energy, Digital Enhanced Cordless Telecommunications (DECT) or Ultra Low Energy (ULE) among others.

From another way, The Routing Over Low-power and Lossy networks (ROLL) is another and actively working group of the IETF focused on produce specifications for both the RPL protocol “IPv6 Routing Protocol for Low-Power and Lossy Networks” (RFC 6550) and a set of related extensions for various routing metrics, objective functions, and multicast.

Application

Application support CoAP Transport UDP ROLL Network IPv6 Adaptation 6LoWPAN Phy/Data link 802.15.x BLE DECT
Application support
CoAP
Transport
UDP
ROLL
Network
IPv6
Adaptation
6LoWPAN
Phy/Data link
802.15.x
BLE
DECT LE
Reference/modified
6LoWPAN
CoRE
ROLL
Specification
Specification
Specification
OSI levels

Figure 10: M2M IETF Working Groups and Specification Scope 7

As per its high number of contributions [21] [22] in the world of constraint device, the most active IoT/M2M working group nowadays, it is considered the Constrained RESTful Environments (CoRE) which its main output concentrate around the “Constrained Application Protocol” (CoAP, RFC 7252), a radically simplified UDP-based analogue to HTTP.

2.2.2.1 Constrained RESTful Environments. CoRE

The Constraint Restful Environments working group is currently defining a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks, i.e. applications to monitor simple sensors (e.g. temperature sensors, light switches, GPS devices, etc.…), to control actuators (e.g. light switches, heating or On-Board- Diagnostics controllers), and to manage devices.

Having a look at [23], a constrained IP network is defined as a network where some of the characteristics pretty much taken for granted with link layers in common use in the Internet at the time of writing are not attainable. Hinted in other words, all those networks that are not as feasible, reachable or practical as those used for common networking protocols. Therefore, they match at least one of the following characteristics:

Low bitrate/throughput (including limits on duty cycle)

High packet loss and/or high variability of packet loss (delivery rate)

Highly asymmetric link characteristics.

Severe penalties for using larger packets (e.g., high packet loss due to link-layer fragmentation)

7 Inspired and motivated by [68]

A System for Vehicle Sensor Data Acquisition Based on CoAP

Moreover, apart from the communication network, there is a standard definition for constraint nodes, defined as nodes [23] where some of the characteristics that are otherwise pretty much taken for granted for Internet nodes at the time of writing are not attainable. Likewise, at least one out of following features should classify them:

Limits for the maximum code complexity (ROM/Flash memory).

Limited size of state and buffers (RAM).

Constraints on the amount of computation feasible per unit of time (Processing power)

Availability of power

Lack of user interface and accessibility in deployment

The general architecture is applied for the analysed above within the ETSI topology and it consists of nodes on the constrained network, called end-points (M2M devices and applications), that are responsible for one or more resources and may represent sensors, actuators, combinations of values, and/or other kind of information.

As part of the framework for building these applications, the working group has defined the Constrained Application Protocol (CoAP) for the manipulation of Resources between end-points which is going to be introduce and summarize below

2.2.2.2 Constraint Application Protocol. CoAP

CoAP [22] is a lightweight RESTful application protocol specifically designed for constrained devices as introduced few lines above. It inherits the same client/server paradigm achieved in HTTP, allowing message interactions in terms of simple request/response transactions (refer to Figure 11).

simple request/response transactions (refer to Figure 11). Figure 11: Client/server paradigm in a CoAP communication

Figure 11: Client/server paradigm in a CoAP communication

The resources are hosted by servers and identified by Uniform Resource Identifiers (URIs) which can be gathered or edited via the RESTful paradigm already explained.

The protocol has a two sublayer topology, as shown in the figure below, a request/response sublayer which handles requests and responses by means of tokens and invoking application methods to generate responses and a message sublayer which manages the message exchange between two CoAP endpoints, basically two entities or nodes participating in the exchange of information resource including reliable delivery if any.

State of the art

State of the art Figure 12: Abstract layering in CoAP by [22] Unlike HTTP, CoAP is

Figure 12: Abstract layering in CoAP by [22]

Unlike HTTP, CoAP is asynchronously transported via small UDP packets, to simplify the network stack and to avoid a further and continuous exchange of messages between client and server, allowing its implementation on constraint devices. Also, on machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles.

The size of each packet stands from a mandatory header of 4 bytes until the maximum allowed in a UDP packet. The RFC 7252 defines four different types of messages:

Confirmable (CON), which provides the message reliability via a second response message such as an Acknowledgement (ACK) through a piggybacking scheme or not (then, a response method 200OK must be send as message response).

Non-Confirmable (NON), a simple datagram is sent in behaviour of a client or server that does not require confirmation by its destination or endpoint.

Reset (RST), employed to handle all kind of errors in the communication, like a server than cannot process a request

Also, CoAP includes the definition of a proxy, which is a single CoAP endpoint that handles requests on behalf of clients and can forward responses via other clients acting as mere intermediary (Forward Proxy) or can be used to simplify the discovery procedure or to transparently implement another kind of custom processing (Reverse Proxy). A Forward Proxy does not expose any resource or whatever can compromise the CoAP server security, so it only can be issued on-demand for CoAP transactions.

2.2.2.2.1 Message format and transmission

The message format of each CoAP packet occupies the whole data section of one UDP datagram and are simply encoded in a binary format basis, where the format starts with a first mandatory fixed-size 4-byte header:

Version (Ver.): 2-bit unsigned integer. The RFC set it to 1 (01 binary) due to first version was recently released

Type (T): 2-bit unsigned integer. Indicates if this message is of type:

o

Confirmable (00 binary)

o

Non-confirmable (01 binary)

o

Acknowledgement (10 binary)

o

Reset (11 binary).

Token Length (TKL): 4-bit unsigned integer. Indicates the length of the next variable- length Token field (0-8 bytes) included just after the header. Note that, lengths 9-15 are still reserved for future upgrades

A System for Vehicle Sensor Data Acquisition Based on CoAP

Code: 8-bit unsigned integer, split into a 3-bit class - Most Significant Bits - and a 5-bit detail

- Least Significant Bits - documented as "c.dd" (class.detail) where "c" is a digit from 0 to 7

for the 3-bit subfield (000 to 111 binary) and "dd" are two digits from 00 to 31 for the 5-bit subfield (00000 to 11111 binary). So, the class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. Particularly, in case of

a request, the Code field indicates the Request Method; in case of a response, a Response

Code.

Message ID: 16-bit unsigned integer in Network Byte Order. It is used to detect message duplications and match messages of type; Acknowledgement/ Confirmable to messages of type Reset/Non confirmable Figure 13: CoAP header. This header may be followed by a well-known 0 to 8 bytes token value as given by the Token Length field (TKL) and used to correlate requests and responses.

field (TKL) and used to correlate requests and responses. Figure 13: CoAP header Moreover, header and

Figure 13: CoAP header

Moreover, header and token can be followed by zero or more options and, if any, the optional payload which comes predefined by a fixed, one-byte Payload Marker (0xFF or 11111111) in order to indicate the start of the payload. Thus, this payload extends after the cited marker to the end of the UDP datagram.

The format of a CoAP option which appears in a CoAP message brings its Option number, length and value:

The option numbers appear in order of their options numbers and a delta encoding is used between them, so a preceding option number zero is supposed. Moreover, multiple instances of the same options can be added.

The option length is an unsigned integer value of 4-bit (0 to 12 possible values). There are other three values reserved for special and advanced constructions.

The option value should be a sequence of exactly the option length and its own value depends on the respective option. However, it only can take one out of the following value formats:

o

Empty or opaque of byte sequences.

o

Unsigned represented in network byte order or string encoded in UTF-8 and represented in Net-Unicode

State of the art

State of the art Figure 14: Option format within a CoAP message [22] Hence, when the

Figure 14: Option format within a CoAP message [22]

Hence, when the header, token, options and payload are forming a CoAP message, it should fit within a single IP packet appropriately encapsulated in order to avoid undesired fragmentation across the network. Accordingly, some recommendations are noted for most of today´s IPv4 and IPv6 paths

An IP MTU of 1280 bytes must be assumed

The maximum message size should not be larger than 1152 bytes

The payload must be 1024 bytes or less

The above considerations leave a maximum of 128 bytes for headers of CoAP/UDP/IP/Ethernet and others used in this protocols

Finally, for the transmission of CoAP messages in terms of reliability, correlation, congestion control and duplication, the RFC 7252 establishes a default network parametrization which is below indicated in form of table:

parametrization which is below indicated in form of table: Figure 15: CoAP protocol parameters (left) and
parametrization which is below indicated in form of table: Figure 15: CoAP protocol parameters (left) and

Figure 15: CoAP protocol parameters (left) and derived (right) [22]

2.2.2.2.2 Requests/Responses sublayer and semantics

A CoAP request may be either Confirmable or NON-Confirmable as by any CoAP message, however, they are basically formed by:

A mandatory method to be applied to the resource in a specified server and easily mapped to HTTP:

A System for Vehicle Sensor Data Acquisition Based on CoAP

o

GET Safe and idempotent method which retrieves a representation for the data currently stored in an indicated resource.

o

POST Neither safe nor idempotent method which delimits to perform any action of create, update or delete a resource.

o

PUT Safe but not idempotent method which indicates that a specific resource must be updated or created.

o

DELETE Idempotent but not safe method which requests to delete the identified resource.

method which requests to delete the identified resource. Figure 16: CoAP method codes 8  A

Figure 16: CoAP method codes 8

A likely payload and Internet media type:

o

A payload can be either included into a PUT or POST request when a resource creation or update is asked to the server.

o

The interpretation of a payload via Internet media types is identified by a string such as “application/xml” [24], however CoAP defines a few sub-registries for a subnet of Internet media types in order to minimize the overhead of using these types to indicate the format of payloads.

of using these types to indicate the format of payloads. Figure 17: CoAP media types defined

Figure 17: CoAP media types defined by RFC-7252 [22]

The thinkable identifier of a resource where a CoAP server is identified via URI scheme stockpiled in the options attributes and other potential options that will be categorized in the upcoming lines

After receiving and interpreting a request, the server should respond with a CoAP response matched to the request via the token generated by the client. These matching rules are exactly defined as follows:

8 Note that an empty CoAP method indicates neither a request nor a response and only contains the 4-byte CoAP header being a CON or NON message, depending on the implementation

State of the art

1. The source endpoint of the response must be the same as the destination endpoint of the original request even if it has crossed several intermediaries.

2. Token matching, which is intended for differentiate among simultaneous requests and must be created randomly by the client.

3. Message ID must match pairs of Confirmable/Acknowledge and NON- Confirmable/Reset messages as already informed above.

Then, a response is identified by the Code field in the CoAP header. Similar to the HTTP Status Code, the CoAP Response Code indicates the result of the attempt to understand and satisfy the request. It is easy and straightway to comprehend its meaning after receiving a request due to its planed human understanding

receiving a request due to its planed human understanding Figure 18: CoAP response codes [22] As

Figure 18: CoAP response codes [22]

As per as the above figure, there are three classes of codes for responses:

2.xx --- Success: The request was successfully received, understood, and accepted.

4.xx --- Client Error: The request contains bad syntax or cannot be fulfilled.

5.xx --- Server Error: The server failed to fulfil an apparently valid request.

For example, any request with an unrecognized or unsupported Method Code must generate a 4.05 (Method Not Allowed).

The CoAP responses can be sent in two basic ways depending on the message nature:

For Confirmable messages (CON): the response is carried directly in the Acknowledgement (ACK) message that acknowledges the request (process known as "Piggybacked Response"). Thus, the ACK returns the response, independent of whether it indicates success or failure.

A System for Vehicle Sensor Data Acquisition Based on CoAP

A System for Vehicle Sensor Data Acquisition Based on CoAP Figure 19: Common case of a

Figure 19: Common case of a retransmission for a confirmable request which is piggybacked in response (ACK) by [22]

For NON-confirmable messages (NON): the response should be returned also in a Non- confirmable message too

should be returned also in a Non- confirmable message too Figure 20: Non-confirmable Request follow by

Figure 20: Non-confirmable Request follow by a Non-Confirmable Response [22]

For advance CoAP implementations, where a server might need longer time to obtain for example the representation of a resource, the response is sent via an Empty (class 0.00) ACK message in order to let the client know that the resource representation is not ready yet. Thus, when this resource is ready, the server must send a confirmable message with the resource content that needs to be acknowledged by the client

As the format of a CoAP option was already introduced, it is time to understand what it is their functions within this protocol. Thus, both requests and responses may include a list of one or more options (only some restrictions applied for resource options between requests and responses), which carry information about for example to specify the target resource of a request to a CoAP origin server

State of the art

State of the art Figure 21: CoAP options and number assignation Below is analysed the most

Figure 21: CoAP options and number assignation

Below is analysed the most relevant ones:

Those options that make reference to the resource locations both created or requested:

o

Uri-Host (only requests) Specifies the Internet host of the resource being requested

o

Uri-Port (only requests) Specifies the transport-layer UDP port number of the resource

o

Uri-Path (only requests) Specifies one segment of the absolute path to the resource

Location-Path (only responses)Same as Uri-path but included into a

 

2.01

Created

o

Uri-Query (only requests) Specifies one argument to aim at parameterizing the

resource.

/~sensors/car/engine/RPM)

They

can

be

multiple if the tree resource is big (i.e.

Location-Query (only responses)Same as Uri-query but included into a

2.01 Created

In the RFC, there is a well-explained method in order to compose and decompose URIs into and from CoAP options that matches the Uri-Host, Uri-Port, Uri-Path and Uri-Query descriptions. Its decomposed aspect and one example:

[standard] coap-URI = "coap:" "//" host [ ":" port] path-abempty [ "?" query]

[example] coap://coap.me:5386 9 /~GPS/location?

Content-Format option. In standard CoAP implementations, there is no need to indicate the format of the payload to gather information from a resource. However, any request message

9 It is the IANA registered port for unsecured CoAP communications

A System for Vehicle Sensor Data Acquisition Based on CoAP

may include this option in order to indicate the format of the payload (xml/json/plain-text…). Refer to Figure 17: CoAP media types defined by RFC-7252

2.2.2.3 CoAP suitability and other standard tracks

After introducing some key aspects of this protocol, easily, one could think that CoAP can be deployed at various locations from the less-constrained network to the most restricted one with just a TCP/IP stack implementation, due to its improvements and advantages against other well- known RESTful models like HTTP, already compared. Therefore, the protocol is specially designed and recommended for following usages:

Between devices on the same constrained network with IP connectivity.

Between devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet and therefore with availability of IP/UDP stack.

Through SMS on mobile communication networks [25] 10

Moreover, the CoRE working group is willing to maintain its first four standards-track specifications (including CoAP)

RFC 6690 Constrained RESTful Environments (CoRE) Link Format [26]

It defines a link format to be used by CoAP servers in order to describe hosted resources and specify possible link relationships with other resources. The language is an extension of the Link Header format defined in HTTP, which includes specific attributes typical of constrained environments.

RFC 7641 Observing Resources in the Constrained Application Protocol (CoAP) [27]

It is introduced as a non-RESTful mode of operation implementing a publish/subscribe mechanism (like a scheduled request/response model) where a client indicated its interest in the status of a resource, registering itself on the server to receive asynchronous updates when the status changes. In terms of CoAP, a client issues a GET request with the Observe option enabled and the server processes the message registering an observe relationship, whenever the resource representation changes, the server notifies all the observers sending a normal CoAP response.

RFC 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP) [21]

It enables the transmission of a big bunch of data without IP fragmentation over the application layer. Constrained networks usually have a limited maximum frame length that requires large data- gram to be fragmented at the IP layer, resulting in inconvenient communication overhead and additional processing for fragmentation and reassembly. Hence, this last RFC publish very recently in August 2016, allows big payloads to be fragmented directly by the application into a chain of messages and each one sent individually to avoid the fragmentation at the IP layer.

2.2.2.4 Open-source CoAP implementations

CoAP can be implemented straightaway from scratch for a simple application just defining the request and response message structure as well as stablishing the RFC principles for each transmission layer. However, there are many already developed which aim at implementing some RFC proposed by the CoRE as seen in the Table 1

10 Please note that this latest Internet-Draft expired on February 9 th in 2015 and there is no intention to carry on with its developing

Table 1: Open-source CoAP implementations

State of the art

 

Programming

 

Client/Server

Implemented

 

Name

Language

Target

CoAP features

License

Californium

[28]

Java

Backend

server/embedded

Client + Server

Observe, Block-

wise Transfers,

EPL+EDL

devices

DTLS

         

Apache

Canopus

[29]

Go

Constrained

devices

Client + Server

CoRE,

Observe/discovery

License

2.0

CoAPSharp

C#, .NET

Constrained

Client + Server

CoRE, Observe,

LGPL

[30]

devices

Block, RD

       

Observe,

 

Multicast server

CoAPthon

[31]

Python

Backend

server/embedded

devices

Client + Server Forward/Reverse Proxy

discovery, CoRE

Link Format

parsing, Block-

MIT

wise

 

JavaScript

   

Observe, Block-

wise Transfers

 

Copper

[32]

(Browser

Plugin)

Web applications

Client

3-clause

BSD

FreeCoAP

C

Embedded

Client + Server

HTTP/CoAP Proxy

Observe, Block-

BSD

[33]

devices

wise, DTLS/TLS

2.2.2.4.1

CoAPthon

CoAPthon [34] is the first CoAP implementation oriented by design to offer an easy-to-use programming interface and libraries to simplify application development for both embedded and backend systems.

In comparison to the above mentioned CoAP implementations, CoAPthon is aligned with the four RFCs introduced before and also implements the proxy functionality, in both reverse and forward modes. Moreover, CoAPthon is the first mature CoAP implementation developed in Python 2.7, which is widely supported by many embedded devices.

The CoAPthon framework architecture and layered architecture is depicted in Figure 22. The library is built on top of the Twisted framework, which is an event-driven networking engine for Python that implements several application protocols and can be easily extended to implement new protocols based on UDP transport layers.

A System for Vehicle Sensor Data Acquisition Based on CoAP

A System for Vehicle Sensor Data Acquisition Based on CoAP Figure 22: CoAPthon implementation architecture 

Figure 22: CoAPthon implementation architecture

The Message Layer implements the transmission sub-layer of the CoAP protocol. It is responsible of pairing messages based on the MID and token header field.

The Extension Layer is basically the container for all extra capabilities coming from other specifications, that are implemented in the system.

The Request Layer is the main layer and implements the Request/Response sublayer of the protocol, therefore it is responsible for handling CoAP requests to produce responses.

Additionally, a Resource Tree topology stores information related to resources exposed by a server, and pairs each resource with the corresponding handler function designated to produce CoAP responses. Thus, when a request is received, the Resource Tree is accessed to find the resource required by the client, then the associated handler is executed on the method specified by the CoAP request.

CoAPthon implements the whole resource oriented approach, where a resource must implement one handler for each of the CoAP methods (GET, PUT, POST and DELETE) that it wants to expose. Otherwise and for instance, if a client requests a method that is not implemented, a “Not Allowed” response is sent by default. In addition, dynamic creation of resources is allowed. An example could be the creation of a new resource as a result of a POST request

2.2.2.5 Others M2M communication protocols

Apart from the well-described CoAP protocol, there are other M2M communication protocols [35] which particularly focuses on aspects of Internet of things (loT), like MQTT (Message Queuing Telemetry Transport), designed by OASIS and is a publisher/subscriber messaging and XMPP (Extensible Messaging and Presence Protocol), a near real-time communication protocol that relies on Extensible Mark-Up language (XML).

2.2.2.5.1 MQTT

MQTT [36] is a publish/subscribe scheme, extremely simple and lightweight messaging protocol networks. Its design strategy is minimising network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery.

State of the art

State of the art Figure 23: MQTT model and protocol stack for its session details It

Figure 23: MQTT model and protocol stack for its session details

It is mainly used in devices that need to be located in the real world and have very high power constraints. In comparison with CoAP in the Table 2

Table 2: Comparison between CoAP and MQTT

Feature

CoAP

MQTT

Communication Model

Request-Response

Publish/subscriber

RESTful

Yes

No

Transport Layer protocol

UDP

TCP

Header size

4 bytes

2 bytes

Number of message types

4

16

Encoding

Binary

Binary

Dynamic discovery

Yes

No

2.2.2.5.2 XMPP

XMMP [37] enables the exchange of data between several network entities through a decentralized client-server model, where each node connects to the server that controls its own domain in the Figure 24

A System for Vehicle Sensor Data Acquisition Based on CoAP

A System for Vehicle Sensor Data Acquisition Based on CoAP Figure 24: Main XMPP Architecture A

Figure 24: Main XMPP Architecture

A XMPP session is established after creating a TCP connection and basically exchanges

input/output XML streams for opening the channel that is going to be used during all

communication process.

The next sections will summarize the technology fundamentals and the building blocks that were introduced above from the scope, design and implementation of this project. Hence, it will include hardware for devices and gateways, data management, mobile Wide Area Networks (WANs), M2M applications detail and

2.3 DATA MANAGEMENT

In M2M many devices interact each other and generate high amounts of data at an abnormal rate.

So that, how the data is managed is such a critical way of importance due to it establishes the

paradigm upon any other process can rely and properly operate. Therefore, dealing with M2M data may be decomposed into several stages [38] briefly highlight below.

2.3.1 DATA GENERATION

This is the first phase where the data is generated actively or passively by a simple device. Normally, the generation of data is delimited by a sample rate which indicates how much data can produce a device itself or by interaction with others, however not all generated data is usually valid or desired, so that it might require to be exposed next to other two stages.

2.3.2 DATA ACQUISITION, VALIDATION AND STORAGE

The data acquisition is related to the collection of the data previously generated over wired or wireless links and might vary in function of its nature, i.e. it can be continuous, upon event-based

or interval-poll. Thus, the validation of this data is very often mandatory in order to conform

application expectations and to avoid either corrupted or unneeded information that is usually stored before sending it straightaway because it can be lost in the network or need to be sent in

small chunks due to its size.

2.3.3 DATA TRANSMISSION, PROCESSING AND REMANENCE

Once the data is stored in either a M2M device or gateway, it should be sent via the communication network towards the second entity to enable the data processing in order to work

on usually big amounts of data (usually referred as datasets) and enhance them for future needs.

State of the art

Finally, the last set of data management stages is the remanence of data and makes reference to handle the end of data life in terms of for how long the data processed will be longer useful.

2.4 M2M SMART VEHICLES AND GLOBAL POSITIONING SYSTEM

Telematics and vehicle tracking are not a new-fancy topic in the world of M2M and there are many related work already in books, articles or even, out of the box on the roads. In fact, the literature involves the vehicular M2M applications mainly divided into one of the following categories: 1) safety and security, 2) information, entertainment and navigation and 3) tracking and diagnostics [39].

A good example of a safety and security service is Automatic Crash Notification. This service

utilizes various “crash sensors” on the vehicle to report the location and extent of damage to the

vehicle in the event of a crash. It also may initiate a voice call to facilitate reporting of the crash

to Emergency Services. Regarding to Information and navigation services, one could think

about providing access for the vehicle occupant/s to a variety of location sensitive information and content, similar to what is already deployed and nowadays is also knows as Google maps features Diagnostic and tracking services are the main topic for the project scope and its essence tries to enable the driver, vehicle occupants and other third person to maintain tracked all the time or when requests, and keep on aye at the Engine Central Unit in order to collect data from a multitude of sensors located throughout the vehicle.

This last category may be applied to offer other services such as fleet management, pay-as-you- drive or even car insurance. Hence, the key point relies on the capability of calculate and make the location of the tracked vehicle available to M2M application servers. In the most scenarios, the location information is reported by the M2M terminal to the M2M application server using a communication network bearer. In this particular case, there are two types of location that can be exchanged:

Network location is either provided based on the cell ID that is serving a particular terminal (but provides a less accurate location) or estimated based on the triangulation technique considering signal strengths measured from base station cells.

GPS location device provides a more accurate location but mandates the deployment of a GPS embedded device, which normally comply with the standard 0183 of the National Marine Electronics Association

The following lines are believed to provide a basic understanding of the NMEA 0183 standard in terms of its institution, the electrical interface and the general sentence format, which includes all the GPS data generated by a GPS receiver that are very useful to understand the upcoming chapter

of system implementation, where this data is acquired by the sensor, parsed, validated and stored

through a programming script in the M2M gateway.

2.4.1 NATIONAL

MARINE

STANDARD 0183

ELECTRONICS

ASSOCIATION.

NMEA

The National Marine Electronics Association (NMEA) was founded in 1957 by a group of electronics who got to discuss how to strengthen their relationships with electronic manufacturers [40]. Hence, they created the only uniform interface standard for digital data exchange between different marine electronic products back in 1980. One of those interfaces was the NMEA 0183

A System for Vehicle Sensor Data Acquisition Based on CoAP

Interface Standard which clearly defined electrical signal requirements, data transmission protocol, timing and format details of specific sentences for a serial data bus of 4800 bauds [41].

It is intended to support and perform one-way serial data communication from a single talker to

one or more listeners, where this data is exchanged as ASCII format and includes information such as position, speed, depth, frequency or height among others.

It is widely accepted by manufacturers and it is the main standard adopted as the basis for an

international scheme by the International Electro-Technical Commission along Europe. Currently, the development of the protocol as well as its future standards are continued by a small committee of NMEA volunteers [40].

The latest standard was published in 2012 and needs to be purchased on its website, hence we cannot make any official reference and/or use it in this report. However, the NMEA 0183 V3.01 published in 2002 plus the Manufacturer's Mnemonic Code is freely provided for academic purposes. So that material will be used for further explanations.

2.4.1.1 Electrical interface. Serial communication

NMEA 0183 designated two types of devices as either talkers or listeners performing an asynchronous serial communication of 8 data bits, 1 stop bit, 1 start bit and 4800 bauds of speed without parity. Also, they use 0/+5 Volt signalling, which is low and easy to interface to the computer equipment, hence from version 2 onwards, it meets the minimum requirements of the computer standard RS422 [42]. Technically, a differential system with two signal lines, “A Data +” and “B Data -” perform a unidirectional communication of 4800 bits per second from talker to listener as we can see in the Figure 25

from talker to listener as we can see in the Figure 25 GPS device unit Integrated
GPS device unit Integrated circuit NMEA talker GPS Integrated circuit
GPS device unit
Integrated circuit
NMEA talker
GPS Integrated
circuit
A (Data +) B (Data -) Shield
A (Data +)
B (Data -)
Shield
R S-422 to USB NMEA Integrated Listener circuit and PINs
R S-422 to USB
NMEA
Integrated
Listener
circuit and PINs
R S-422 to USB NMEA Integrated Listener circuit and PINs Figure 25: High level Representation of

Figure 25: High level Representation of an RS-422 connection NMEA GPS talker/listener with its differential outputs over integrated electronic circuits 11

As per the above picture, the differential drive signals perform the typical unipolar RS-422 operation and do not have any reference to ground, consequently being more protected against noise. For a quick understanding of how it works, the logical “1” or STOP bit state is defined by the lowest Transistor-to-Transistor Level (TTL) voltage (normally 0 V) on line “A” with respect to line “B” and the logical “0” or START bit is defined by the highest TTL voltage (normally 5V)

11 The integrated GPS circuit is supposed to include other several key components like the RF

input, Low Noise Amplifier (LNA), Surface Acoustic Wave (SAW) filter, Crystal Oscillator (like

a TXCO) and the GPS RF chip. Moreover, other analogic and digital components for further connections and purposes.

State of the art

on line “A” with respect to “B”. Despite, a NMEA listener must be interconnected directly to the differential outputs with opto-isolators and suitable protection circuitry.

A graphical serial asynchronous communication with these features is shown in the Figure 26

communication with these features is shown in the Figure 26 Figure 26: Serial asynchronous communication by

Figure 26: Serial asynchronous communication by [42]

2.4.1.2 Data protocol. NMEA 0183 Sentences

All this data is transmitted along the wires from the talker to the listener and defined logically as printable sentences of ASCII characters including Carriage Returns (CR) and Line Feeds (LF).

The standard defines fields as strings of valid or null characters, located between two appropriate delimiter characters [42], thus each sentence starts with either “$” or “!” and will end with this sequential of characters <CR><LF>. IT is collected in the Table 3

Table 3: NMEA sentence and meaning

NMEA Sentence

“$” <address_field> [“,” <data_field>] (*<Checksum>) <CR><LF>

ASCII value

Meaning

“$” or “!”

Start of sentence

<address field>

TALKER identifier and sentence formatter

[“,” <data field>]

Zero or more data fields

(“*” <checksum field>)

Checksum field

<CR><LF>

End of sentence

The minimum number of fields allowed is only one and it should be the Talker identifier. Also, the maximum sentence length is up to 82 characters and null data shall appear as consequent of unavailability of information

The Talker Identifier for the Global Positioning System (GPS) is GP and corresponds with the most common and following talker sentence depicted in the Table 4

Table 4: Name and description for main sentences of Global Position System

Sentence

Name

Description

GPGGA

Global Positioning System Fix Data

Provides time, position and fix related data for GPS receiver

GPGSA

GNSS 12 DOP and Active Satellites

Provides satellites in used and Dilution of Precision Values

12 GNSS stands for Global Navigation Satellite System

A System for Vehicle Sensor Data Acquisition Based on CoAP

GPRMC

Recommended minimum Specific GNSS Data

Provides time, data, position, course and speed data

GPGSV

GNSS Satellites in View

Number of satellites in view, satellite ID number, Elevation, Azimuth and SNR value. Four satellites max per transmission

With the baud rate at 4800 bits per second, only 480 characters can be sent in one second and since an NMEA sentence can be as long as 82 characters, the system present a limitation of 6 different sentences (max. size) per second. However, most of the sentence does not reach this limit (82 ASCII characters) and the amount of sentences is normally higher.

NMEA is specially designed to run as a process in the background spitting out sentences which are then captured as needed by the using program. Thus, the following sections are attempted to show how to interpret every single NMEA sentence above specified.

2.4.1.2.1 NMEA GP-RMC

single NMEA sentence above specified. 2.4.1.2.1 NMEA GP-RMC Figure 27: RMC NMEA Sentence [41] 1) Easterly

Figure 27: RMC NMEA Sentence [41]

1)

Easterly variation (E) and Westerly variation subtracts from True course

2)

Positioning system Mode Indicator (most common: AAutonomous D Differential)

3)

The status of the GPS receiver stats for V Invalid and A (Autonomous) or D (Differential)

2.4.1.2.2 NMEA GP-GGA

31

State of the art

State of the art Figure 28: GGA sentence [41] 1) GPS Quality indicator: a. 0 

Figure 28: GGA sentence [41]

1)

GPS Quality indicator:

a. 0 Not fixed or invalid data

b. 1 GPS, Standard Positioning Service (SPS) mode or fix valid

c. 2 Differential GPS SPS mode, fix mode

d. 3 GPS, Precise Positioning Service (PPS) mode, fix valid

e. 4 Real Time Kinematic. System used in RTK mode with fixed integers

2)

Time seconds since last SC104 [42] Type 1 or 9 update

3)

Geoidal Separation. The difference between the WGS-84 earth ellipsoid surface and mean-sea-level surface

2.4.1.2.3 NMEA GP-GSA

surface and mean-sea-level surface 2.4.1.2.3 NMEA GP-GSA 1) Figure 29: GSA NMEA sentence [41] GPS Satellites

1)

Figure 29: GSA NMEA sentence [41]

GPS Satellites ID are identified by their PRN numbers (from 1 to 32) and WAAS 13 satellites are reserved (from 33 to 64)

13 Wide Area Augmentation System (WAAS) is an air navigation aid developed by the Federal Aviation Administration to improve GPS, with the goal of increasing its accuracy, integrity, and availability [69].

32

2.4.1.2.4 NMEA GP-GSV

A System for Vehicle Sensor Data Acquisition Based on CoAP

A System for Vehicle Sensor Data Acquisition Based on CoAP Figure 30: GSV NMEA Sentence [41]

Figure 30: GSV NMEA Sentence [41]

2)

Satellite information may require the transmission of multiple sentences like this with identical format. The first field indicates the total sentences and the second the order of these sentences

3)

A set of “Sat ID-Elev-Azi-SNR” is allowed up to a maximum of 4 per sentence.

4)

GPS Satellites ID are identified by their PRN numbers (from 1 to 32) and WAAS satellites are reserved (from 33 to 64)

The next chapter will introduce the analysis of a current M2M system in terms of its limitation and possible improvements to be conducted over a new M2M communication design which is supposed to improve its major deficiencies.

System analysis, requirements and design

Chapter 3 System analysis, requirements and design

In this chapter, a system analysis of a current M2M deployment is performed beside the proposed of a use case and the main requirements of a M2M solution which considers a proof of concept for a continuous and real time M2M communication between a vehicle and a M2M server.

3.1 ANALYSIS OF AN EXISTING M2M SOLUTION

Recognised UK business group custodies a specific fleet of vehicles, larger than 30 units, which performs Drive Testing for most telecom operators along the nationwide British territory (Wales, Scotland and England).

Drive testing is usually referred to a method of measuring and assessing the coverage, capacity and Quality of Service of a mobile radio network. Basically, it consists on using a motor vehicle with mobile radio network instruments (handsets and/or scanners) that can detect, record and perform a wide variety of different tests for network parametrization and optimisation

This company has been gradually deploying a basic and single-purpose vehicle tracking solution in the majority of its vehicles since 2012 based on a third party technology solution, that conducts the vehicle installation and management as well as the maintenance of the entire system from raw data acquired on a vehicle towards useful information for the customer. So that, the solution is composed of a “black box” installed at some unknown and secret point of the vehicle, most probably soldered down and embedded next to the vehicle engine.

As far as it could be understood, the utilised technology is a simple and old-fashion M2M-GSM and GPS communication, performing a unidirectional communication from the embedded device to the server via SMS messages of latitude, longitude and timestamp just when the engine is switched on. Thus, the outcome of this implemented technology is very simple and every Monday, the company receives a weekly report in PDF which includes straightforward information like:

travelled distance, key locations and how long the vehicle engine was running in a daily and weekly basis.

3.1.1 CURRENT LIMITATIONS

The introduced system has some easily identifiable limitations and constraints, mainly in terms of costs, acquired data, future-proof and tracking accuracy:

The system installation cost in new vehicles exceeds more than £200 and it requires to leave useless the intended vehicle for a couple of days in order to conduct its installation. Moreover, the maintenance cost performed by the third party company surpassed other £50 monthly per tracked vehicle.

The acquired and generated data is very poor and insufficient nowadays as long as it only treats with three position indicators; latitude, longitude and timestamp merely when the vehicle engine is switched on.

The technology used on the embedded device is very limited and does not allow any future enhancement after its installation. As a consequence, the system is not-future-proof and limited to SMS data-exchange.

A System for Vehicle Sensor Data Acquisition Based on CoAP

In terms of hardware design, the embedded device is not transferable among vehicles and its operation is challenging due to the difficult access of its unknown location.

The system does not have any future-proof of relevance and improvements as the embedded device is just supposed to send SMS towards a specific telephone number within a third party company environment. Although having a life cycle for more than 10 years, there are many stakeholders involved in this system and nobody could predict what is going to occur after few years of substantial technology changes.

The system implementation does not provide an accurate location system due to the lack of information like dilution of precision, satellite quality and an exhaustive process of getting