A System for a Vehicle Based on CoAP
119
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
-
Upload
marcos-soutullo -
Category
Technology
-
view
98 -
download
3
Transcript of A System for a Vehicle Based on CoAP
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 30th of September 2016
I
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
II
“Believe you can and you are halfway there”,
Theodore Roosevelt
III
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.
IV
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
V
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
VI
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 GPS data Acquisition ........................................................................................................................................ 79
5.1.1.2 GPS data Validation and Storage ............................................................................................................... 79
5.1.2 WAN initialisation .................................................................................................................................... 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
VII
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 BELOW. ................................................................................................................................. 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] .......................................................................................................................... 20
FIGURE 19: COMMON CASE OF A RETRANSMISSION FOR A CONFIRMABLE REQUEST WHICH IS PIGGYBACKED IN RESPONSE
(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
VIII
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
FIGURE 46: RESOURCE INITIALISATION .................................................................................................................................. 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
IX
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
FIGURE 114: LATITUDE AND LONGITUDE PROJECTION OVER GOOGLE MAPS SHOWING GROUND SPEED IN KM/H ........... 92
FIGURE 115: LATITUDE AND LONGITUDE PROJECTION OVER GOOGLE MAPS SHOWING HORIZONTAL DILUTION OF
PRECISION .................................................................................................................................................................... 93
FIGURE 116: DEAD POINT .................................................................................................................................................... 93
FIGURE 117: RASPBERRY PI MODEL 3 [43] .......................................................................................................................... 97
FIGURE 118: RASPBERRY PI MODEL 3 GPIO LAYOUT .......................................................................................................... 97
FIGURE 119: PIN ASSIGNMENT FOR SIM800 EVB V2 ...................................................................................................... 99
FIGURE 120: SIM800L FEATURED BY SIMCOM ................................................................................................................. 99
X
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
1
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.
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:
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
2
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
3
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
4
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
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
Communication Network
Device/s
Application
Figure 3 Basic architecture of a M2M communication1
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
5
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.
Communication Network
M2M Device/s
M2M Application
Enterprise Process
M2M Service Establishment
and CapabilitiesGateway
(1)
(3)
(4)
(2)
(2)
(1)
(1)
Figure 4: Advance architecture of a M2M communication2. 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
6
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
7
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.
State of the art
8
Network and
ApplicationDomain (NAD)
Device and Gateway Domain (DGD)
M2M Application
M2M Application
M2M Service capability
M2M Service capability
M2M Device/s + Gateway
M2M Application
M2M Service capability
M2M Gateway
M2M Area Network
M2M DEVICE/S
Core Network (CN)
Access Network (AN)
Network management
functions
M2M Management
functions
M2M Core
User interface to application, Data bases, usage monitoring...
Transport Network
Figure 5: M2M - ETSI - High level architecture3
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
9
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
State of the art
10
2.2.1.1.3 Management functions
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
Network M2M node
M2M Gateway (G)
M2M Device (D
Network Application
(NA)
NSCL
Device and Gateway Domain (DGD) Network Domain (ND)
Device Application (DA)
Case 1
DSCL
Gateway Application (GA)
Case 2
GSCL
dIa
Device Application (DA)
dIa
dIa
mIamId
mId
Device M2M node
M2M Authentication Server (MAS)
M2M Service Bootstrap
Function (MSBF)
mIa
mIa
Figure 6: Reference points mapping to key M2M entities5
5 Inspired from [13]
A System for Vehicle Sensor Data Acquisition Based on CoAP
11
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.
State of the art
12
M2M application Server M2M Application Resource
Read (GET) request. Location?
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
NSCLmId
Data Base atM2M Gateway (G)
Gateway Application (GA)
GSCLDevice
Application (DA)
dIa
dIa
Device M2M node
Step 1Create or Update
Resource
Network Application
(NA)
mIa
Step 2Notify or wait until
read
Step 3Read directly
either from NSCL or GSCL Databases
Figure 8: Example of use for SCL and REST architectures within ETSI M2M architecture6
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
13
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 “n” attributes,
just one scs resource which specifies the resource name and one property of each application,
container, group, accessRight, subscription and discovery.
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
14
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.
Phy/Data link
Adaptation
Network
Transport
Application support
Application
CoAP
6LoWPAN
802.15.x
IPv6
BLE DECT LE
UDP ROLL
Reference/modified OSI levels
6LoWPAN Specification
CoRE Specification
ROLL Specification
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
15
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).
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
16
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
17
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.
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
18
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:
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
19
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.
Figure 16: CoAP method codes8
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.
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
20
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
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
21
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
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
22
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. They can be multiple if the tree resource is big (i.e.
/~sensors/car/engine/RPM)
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:53869/~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
23
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 9th in 2015 and there is no
intention to carry on with its developing
State of the art
24
Table 1: Open-source CoAP implementations
Name Programming
Language Target Client/Server
Implemented CoAP features
License
Californium [28]
Java Backend
server/embedded devices
Client + Server Observe, Block-wise Transfers,
DTLS EPL+EDL
Canopus [29]
Go Constrained
devices Client + Server
CoRE, Observe/discovery
Apache License
2.0
CoAPSharp [30]
C#, .NET Constrained
devices Client + Server
CoRE, Observe, Block, RD
LGPL
CoAPthon [31]
Python Backend
server/embedded devices
Client + Server Forward/Reverse
Proxy
Observe, Multicast server discovery, CoRE
Link Format parsing, Block-
wise
MIT
Copper [32]
JavaScript (Browser Plugin)
Web applications Client Observe, Block-wise Transfers
3-clause BSD
FreeCoAP [33]
C Embedded
devices
Client + Server HTTP/CoAP
Proxy
Observe, Block-wise, DTLS/TLS
BSD
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
25
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
26
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
27
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
28
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 ELECTRONICS ASSOCIATION. NMEA
STANDARD 0183
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
29
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
GPS device unit Integrated circuit
GPS Integrated circuit
NMEA talker
A (Data +)
B (Data -)
Shield
NMEA Listener
RS-422 to USB Integrated
circuit and PINs
Figure 25: High level Representation of an RS-422 connection NMEA GPS talker/listener with its
differential outputs over integrated electronic circuits11
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
30
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
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 12DOP 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
31
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
Figure 27: RMC NMEA Sentence [41]
1) Easterly variation (E) and Westerly variation subtracts from True course
2) Positioning system Mode Indicator (most common: A Autonomous 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
State of the art
32
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
Figure 29: GSA NMEA sentence [41]
1) 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].
A System for Vehicle Sensor Data Acquisition Based on CoAP
33
2.4.1.2.4 NMEA GP-GSV
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
34
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
35
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
more GPS data samples
In addition to the above described constraints, there are many others like lack of productivity in
management tasks, no possibility for solution transfer between vehicles (portability) or
absence of driver records
3.1.2 DESIRED IMPROVEMENTS
The company would like to develop a new and entire model based on a “real time” M2M
communication system which focuses on:
Reducing the current costs of installation and maintenance with a non-revolutionary
technology that does not require field experts to be engaged, i.e. opting for a low-cost WAN
technology like GSM/GPRS.
Providing resilience of company vehicles due to the constant analysis of the vehicle status
in order to predict maintenance and being able to know who is driving each vehicle and for
how long.
Increasing the quality of service provided against the current system, i.e. grating near to real
time information of detailed GPS data.
Bringing high range of scalability and numerous upgrades in the short and medium-term,
i.e. developing an application to send and update the latest site list of a determined telco
operator for Drive Testing purposes.
Establishing the main first step for an actual M2M communication between vehicles and
servers and between vehicles in the near future.
Consequently, next paragraphs will start the discussion about the first proof of concept that will
satisfy these first desired improvements.
3.2 NEW USE CASE SCENARIO
Based on the previously described deployment, the following new use case of this application
considers a fleet of vehicles which moves geographically across a whole country and is widely
dispersed and is depicted in the Figure 31
This fleet is remotely monitored from a central site, where the system users can visualize in real-
time information related to the car location and the quality of this data either via a website
application or some GPS data reports.
System analysis, requirements and design
36
Website application
Telecom core and the Internet
Server
Telecom Access
Network
Datasets
GPS
Drivers
Figure 31: Conceptual deployment diagram and scenario
3.2.1 STAKEHOLDERS
From the above figure can be identified the following stakeholders:
Asset Owners: These are the individuals or corporate entities that are responsible for the
vehicles being tracked. So, they are identified as application users and drivers, where the
application users will be able to trigger a M2M communication session to exchange
information with the drivers, asset vehicle location and even receive detailed location reports
from vehicles while drivers are willing to maintain the M2M device and perform the
authentication/identification step against the M2M server.
High Value Assets: These are vehicles with embedded M2M Devices/Gateway that can
interface with location-determination technology and can communicate via a mobile
A System for Vehicle Sensor Data Acquisition Based on CoAP
37
telecommunications network towards a server. So, the M2M Device will interface with
location-determination technology such as a standalone GPS receiver
Tracking Server14: This is the M2M Server, an entity located in the customer premises and
owned or operated by the user applications to receive, process, and render information
provided by the deployed High Value Assets.
GPS Location Infrastructure: This consists of the elements, external to the M2M
architecture, that provide determination of the M2M device position.
Telecommunication Network and Operator: The M2M Device/s interface directly with a
gateway with a mobile telecommunications network capable of servicing the geographic area
where the vehicle is expected to be located.
3.3 SYSTEM REQUIREMENTS, SPECIFICATIONS AND
DESIGN
The output of this thesis is a proof of concept which delivers the identified improvements and the
use case scenario previously described. Hence, it will consist on the use of one M2M
communication protocol that allows an implementation to exchange GPS data between the M2M
server and the appliance installed on the car, which acts as both M2M gateway and device. This
section covers the requirements, specifications and design of the M2M components of the
proposed solution.
Below the specific requirements and specifications for this first proof of concept are described.
3.3.1 GENERAL AND FUNCTIONAL REQUIREMENTS
The general and functional requirements are collected and very briefly indicated below:
A low cost embedded M2M device, which includes a gateway connected to at least, one
sensor allocated in the car, like a GPS device.
A simple M2M server that can establish a simple asynchronous communication with the
M2M gateway either upon request or automatically gathering GPS data, for example.
The main output of the system shall be a simple file which collects all the GPS data
generated, acquired, validated, stored and gathered by the M2M device, gateway and server.
The proposed system architecture should comply in such an elemental way with the ETSI
M2M architecture, be scalable in terms of number of future connected devices and show a
clear abstraction and heterogeneity of technologies.
3.3.2 M2M GATEWAY AND DEVICE SPECIFICATION
The M2M gateway and device should comply with at least this specific requirements:
14 The Tracking Server can trigger a particular M2M Device to provide a location/velocity update,
or the deployed M2M Devices can be configured to autonomously provide updates on schedule
or upon an event-based trigger.
System analysis, requirements and design
38
Capability to run a RESTful environment very similar to the basis of HTTP, but using a
M2M communication protocol that shares information resources about for example, latest
GPS data, like timestamp, latitude, longitude, altitude and ground speed.
Store locally data before transmitting it to the M2M server
Keep a continuous connectivity with the server as long as possible via any kind of WAN
mobile access implementation that permits the M2M server verify that the M2M gateway is
listening to upcoming requests. Also, a simple failure robustness upon connection losses,
thus an appropriated initialisation, integration and validation if supported.
3.3.2.1 Authentication and identification scheme
There should be a way to provide confidentiality and authenticity in at least, the first packet sent
by the M2M gateway towards the server in order to start a communication. This process could
allow identify two things; the driver and the vehicle itself
3.3.3 M2M SERVER AND APPLICATION SPECIFICATION
The M2M Server and the linked application must perform two main activities:
Gather information, like GPS data from the M2M gateway located on the car.
Store the collected data in an easy and well-known format for the company, where non-
technical people might be working and would need the data straightaway.
Thus, the M2M server will define the message transmission scheduling and will be aware of
possible delay tolerance
3.3.4 ASSUMPTIONS AND CONSTRAINTS
This proof of concept will not need to handle with the following design, management and
installation aspects.
3.3.4.1 Communication network design
Low-cost system implementation is given as prime condition and main requirements. So, there
will be to assume that the system design may incur in the use of a long-standing technology that
cannot achieve some expected results, i.e. the use of GPRS may incur in the assumption to very
low-throughput rate, inadequate for other purposes, like on-board entertainment via video
streaming
3.3.4.2 Energy system management
It is logic to understand that the system implementation would need a power management system
in order to maintain its activity when the car is running. Therefore, there will be assumed that the
energy management system will be out of the project scope
3.3.4.3 System installation on the vehicle
It is not expected to provide a design or approach about how to implement and install the first
prototype on the car. However, the implementation design may present an embedded format able
to run out of the box when the driver starts to drive.
A System for Vehicle Sensor Data Acquisition Based on CoAP
39
3.3.5 ARCHITECTURE, TOPOLOGY AND INFORMATION FLOW
This last subsection mainly describes the use of CoAP as M2M communication protocol in the
system, for which a simple ETSI standard architecture is selected as system blocks in order to
explain and perform a proof of concept with all its data management stages present in a solution
of these characterises.
As already was introduced, CoAP is the most recent standard for M2M communications that
follows the simplicity of RESTful paradigms as well as it is easily mapped to other well-known
protocols like HTTP. Thus, for providing a scheme based on exchanging non-critical data that
can be retransmitted again if duplicated or not-validated on destination, like GPS data, it
represents an appropriate solution for saving radio and power resources. Therefore, the proposed
architecture and topology presents a detailed appearance as depicted in the Figure 32 and it
basically consists of exchanging CoAP packets between the two system endpoints.
Vehicle domain
M2M Server
~CoAP Client~
M2M Server and application Domain M2M Gateway and Device Domain
Users
User Web Interface
Internet
GPS report
M2M Gateway
~CoAP server~
M2M Device
GPS
Server domain
CoAP Responses
CoAP Requests
GPRSOtherInstructions
Instructions
Figure 32: Proposal of architecture, topology and information flow
On the right is shown the M2M gateway and device located inside the vehicle which aims at
acting as a CoAP server initialising its GPS and instructions resources, this last one intended to
act as a RESTful resource with its own ways to create, update, retrieve or delete data via the
second endpoint of the system that will be the M2M server and a website application located
at the customer premises that will run a CoAP client entity, as a backend service in order to
communicate with the CoAP server. Thus, all the data generated and acquired in the vehicle
domain will be send such as asynchronous fashion upon CoAP requests, towards the M2M server
in means of CoAP responses. Moreover, the required minimum of security is implemented in the
first packet which sends the M2M gateway towards the M2M server.
Implementation
40
Chapter 4 Implementation
This chapter briefly describes what elements contains the M2M Gateway and device domain in
order to deploy a real proof of concept that follows the solution design exposed in the Figure 32
as well as its system requirements explained in the previous chapter. Moreover, it describes what
programming languages and libraries where used as well as the entire implementation is provided
in such a way of Behaviour UML activity diagrams that provide a useful approach about the
relationships among actions, objects and methods besides a great understanding of how the
application works. In addition, small portions of code are included in order to endorse the
implementation itself.
4.1 HARDWARE IMPLEMENTATION
This subsection introduces the utilised hardware in the vehicle domain with the aim at deploying
a first proof of concept for a company vehicle.
4.1.1 M2M GATEWAY AND GPS DEVICE
The M2M gateway core for this implementation is a Raspberry Pi model 3 (Figure 33 and refer
to ) [43], basically because of its low-cost, small form factor (credit card size), its expansion
capabilities in terms of GPIO, the possibility for using a proper built-in tactile screen, the
possibility to use high-power demand devices without extra power source (the raspberry Pi
supports 5V or 3.3V up to 2.5A in DC) and its extra high power performance that can provide
further improvements in the near-future if the company would like to install other functionalities;
for example a navigation system or other more complex developments.
Additionally, a GPS device that complies with the NMEA standard needs to be included in the
system in order to generate the GPS raw data that will be acquired, validated and stored in the
Raspberry Pi afterwards. For this goal and to simplify things, there was chosen an embedded
micro-USB GPS device with a built-in LNA and GPS antenna powered by a MediaTek chipset
(its major specifications are in the Annex I). The hardware implementation takes part of an easy
plug-and-play configuration which is connected to one of the four available USB 2.0 ports in the
Raspberry PI board.
Figure 33: Raspberry Pi and a GPS dongle ND-105c
GND
VCC +5VD-
D+
Micro-USB adaptorRaspberry PI 3 GPS sensor
A System for Vehicle Sensor Data Acquisition Based on CoAP
41
4.1.2 COMMUNICATION ACCESS NETWORK
As per one of the main requirements, the solution must include a low-cost communication modem
able to interconnect the M2M Server and the Gateway. Thus, the chosen technology is GPRS
because is inexpensive, the data size of every single packet exchanged between entities would
not be higher than 1Kb and because the maturity and well-maintained GSM networks nowadays
imply the highest range of coverage.
Hence, for the purpose of this project, there was acquired an evaluation board which follows the
circuitry design considerations of a SIM800L [44], a GPRS modem embedded as a Data
Communication Equipment (DCE) and built-in to provide a full modem serial interface used for
sending and receiving UDP datagrams. For its application within the M2M Gateway, the GPRS
modem is configured using AT commands that are sent via the UART serial interface of the
Raspberry Pi (more information is added in the appendix A, please see GPRS modem SIM800L).
Additionally, Figure 34 and Figure 35 show some extra information about this module and how
it should be connected to the Raspberry Pi.
Figure 34: SIM800L Evaluation Board V2
Figure 35: SIM800L EVB connected to the raspberry Pi via proto-board and GPIO extensor
Status Net-light
and resistors
Power and ring indicator
lights and resistors
RF-GSM antenna
Serial Interface
connection circuitry
Rectifier Diode for
power supply
Power supply
circuitry
SIM card holder
circuitry
IN/OUTPINs
RST
GND
VCC
GND
RX
TX
VDD
Implementation
42
The next section will explain the whole implementation and functionality of the system as well
as how every single process is achieved in order to perform the requirements previously exposed.
4.2 PYTHON AS MAIN PROGRAMMING LANGUAGE
Python is an object-oriented scripting language [45] used for general-purpose and dynamic
implementations due to its ease to conduct very complicated programs, its automatic memory
management system and its considerable and comprehensive number of libraries written for it.
Moreover, Python interpreters are available for many operating systems like Linux or Windows
and therefore every single script is able to be distributed and compiled on them.
The use of Python on its version 2.7 mainly comes from two reasons:
It is widely compatible with the most constraints devices able to run a lightweight
implementation of Linux.
It allows a quick implementation and deployment of an entire system in much less time
than would take with another programming language, like for example Java or C++.
On the other hand, it is expected to run much slower than other programs written in other
languages, however the high performance of a Raspberry Pi is able to handle it.
Indeed, the Python libraries used in the implementation in the gateway are listed in the Table 5
Table 5: Main Python libraries
Library Description License
Pyserial [46] This module encapsulates the access for the serial port
providing a backend to be treated in Python SPDX
Pynmea2 [47] This module aims at parsing ASCII sentences that correspond
with the NMEA 0183 MIT
JSON [48] This module is the simplest and fastest way to load and dump
JSON objects in Python and vice versa. MIT
Pycrypto [49] It is a collection of both secure hash functions and various
encryption algorithms MIT
CoAPthon [31] It is a Python library to the CoAP protocol compliant with the
RFC15 MIT
Multithreading
[50]
It is a higher level interface to construct threading interfaces
on top of the lower level thread module PSF
Multiprocessing.
Queue [51]
It implements multi-producer and multi-consumer queues to
exchange information between threads and process PSF
Moreover, other Python packages for communicating with the GPRS modem were written on my
own in order to achieve the system requirements. So that, it will be introduced in the next
implementation stage
15 See the State of the art at CoAPthon
A System for Vehicle Sensor Data Acquisition Based on CoAP
43
4.3 M2M GATEWAY AND DEVICE IMPLEMENTATION
The main activities of the M2M gateway and device applications are exposed in the Figure 36 as
well as the relationship between them in such a way as all methods and functions involved in the
system will be appearing as soon as they are needed to perform the next activity, thus once a
function is introduced and explained, it may be reused afterwards.
At the beginning, it is mandatory as a precondition, to provide the following parameters as part
of the system configuration:
A valid IPv4 for the M2M server.
A shared key for the authentication procedure, which is used as vehicle identifier and is
cyphered once everything is ready to start communicating and the first CoAP message is
ready to be sent.
APN settings. It includes User, Password and Network Name for authentication into the
mobile operator network via GPRS and during the WAN initialisation.
Firstly, the GPS device initialisation process is required to start generating raw data, concerning
the geographical location of the M2M device.
Secondly, the process of data, which runs constantly in the background, is started and performed
in terms of acquisition, validation and storage for each resource that will be running in the CoAP
server afterwards.
Thirdly, the initialisation process of the CoAP server as well as the resources that will be handling
in terms of RESTful environment, are executed.
Fourthly, the whole initialisation process of the UDP Server engine is performed, starting from
the WAN initialisation and ending with the execution of a daemon-thread running in the
background that reads every single bit arriving at the input serial line. Furthermore, the activities
which read and send UDP datagrams are defined in order to be used when the CoAP server is
running.
Fifthly, it is explained the process of M2M authentication 16 and the concept of driver
identification against the M2M server.
Sixthly and only if the last step was successfully performed, the M2M gateway application will
start the CoAP server engine in order to process CoAP requests coming exclusively from the
M2M server.
Lastly and whether the M2M authentication procedure could not be performed successfully or
the M2M communication is interrupted via a SIGINT (CTRL+C), the M2M server will end its
activity and close any opened serial port.
16 Please note that in the M2M security step is required the interaction of the driver, who will
write a 4-numeric-digits identifier and also, the M2M server, which will grant the permissions to
run the CoAP server engine.
Implementation
44
M2M Gateway
and device
Application
Initialise
GPS Device Application
Perform M2M
Authentication and
Driver identification
Listen and process
CoAP requests
Keyboard
interruption?
Yes No
Authentication step
passed?
No YesStop server and close
GPS Device Application
Generate
Acquire
Validate
Store
Initialise
WAN
Initialise CoAP
Server and
resources
Independent
process
Assignate
Preconditions
Send UDP
datagram
Read input
serial buffer
Parallel
Process
Daemon-thread
Data Queues exchange
Read UPD
datagramUDP queue
exchange
Parallel process
1) IP M2M Server
2) Shared Key
3) APN settings
Figure 36: Gateway and Device application activity diagram
A System for Vehicle Sensor Data Acquisition Based on CoAP
45
4.3.1 INITIALISE GPS DEVICE APPLICATION
The GPS raw data are actively generated by the GPS dongle device and accessible via its Linux
file “ttyUSBx”17 in the Raspberry Pi, which represents the terminal of the current process that
will be initialised. For this purpose, the pyserial libraries were used because they provide an
encapsulated access for the serial port based on a full-working backend running on any OS. The
Figure 37 indicates how the GPS device application is configured in terms of activity diagram
and some Python code
Initialise
GPS Device application
Open
port
Port opened?
Flush input
serial bufferYes
Exit
program
No
Set Serial
port
Figure 37: Initialise GPS Device Application activity diagram and implementation18
Once the serial configuration is successfully performed, the script flushes the serial input buffer
and at this point, the raspberry Pi should be able to acquire and validate all the GPS data provided
in NMEA sentences style via the input serial port that has been just initialised.
4.3.2 ACQUISITION AND VALIDATION OF DATA
The next main activity exposed in the Figure 38 is the acquisition and validation of the data
generated by the GPS device, which is accessible via the serial port opened as a result of the
previous activity. Thus, a loop must be considered in order to read continuously entire ASCII
lines or NMEA sentences, that start by “$” and end by “\n” until the whole data is validated and
posteriorly stored in the raspberry Pi.
With the intention of decreasing the system complexity, a third party Python library was used to
parse every single NMEA sentence that fulfils the NMEA 0183 protocol explained in the second
chapter. Thus, the pynmea2 libraries [47] conduct this goal just parsing a string, which contains a
NMEA 0183 sentence and returning a NMEA_Sentence object with all its derived methods and
properties in Python.
17 The ‘x’ represents a number and indicates the USB device under use. For this project, there is
only one USB device used, so it is assumed that the port should be “tty/USB0” 18 Consider that the timeout is set to 1 second in order to return bits when immediately available
or None after 1 second
Implementation
46
Acquiring
raw Data
Acquire and
validate
GPS data
RMC sentence?
NMEA valid
sentence?
RMC data
validation
GGA data
validation
GSA data
validation
GSV data
validation
Parsing NMEA
sentenceYes
No
GSA sentence?GSV sentence? GGA sentence?
NoNoNo
YesYesYesYes
No
All sentences
Checked?
No
Yes
Figure 38: Acquire and validate GPS data activity diagram
It is important to note that the GPS device follows a strict order of sending NMEA sentences
to the Raspberry Pi, so that the analysis must start only when a RMC sentence is parsed and
discard all other sentences before this one19.
In the next subsections, there will be a further explanation about these minor activities, however
it is highly recommendable to refresh the concept of an NMEA sentence and its types described
in the State of the Art.
4.3.2.1 RMC data Validation
This first NMEA sentence would deliver the ground speed and the data stamp. So, in order to
validate this sentence before storing its data in the cache and continue with the background
process, the status of the sentence must be equal to “A” which means Data Valid. It can be
exposed in the Figure 38: Acquire and validate GPS data activity diagramFigure 38
19 A debugging test will clarify this methodology in the next chapter
A System for Vehicle Sensor Data Acquisition Based on CoAP
47
Data
validated
RMC data
Validation
Data valid?
Yes
No
Return RMC check
Ground speed
(km/h)
Date stamp
(dd/mm/yyyy)
Figure 39: RMC sentence data validation and acquisition activity diagram
At this time if everything was right, the speed of the vehicle is actually validated and acquired
in units of km/h following the Figure 39 and therefore the next involved sentence should be the
GGA (System Fix Data) that will provide the main GPS data
4.3.2.2 GGA data Validation
This second NMEA sentence aims at providing the most relevant GPS information like
Timestamp, latitude, longitude, altitude and number of satellites on tracking that also need
to be validated and acquired for its further storage and transmission as depicted in the Figure 40.
Data
validated
GGA data
Validation
GPS quality
>=1 and <=6?
No
RMC check?
No
YesYes
Return GGA check
- Timestamp
(hh:mm:ss)
- Latitude
(decimal)
- Longitude
(decimal)
- Altitude
(meters)
- Sats on
Tracking
(int number)
Figure 40: GGA sentence data validation and acquisition activity diagram
Therefore, this sentence will be valid if and only if the GPS quality parameter indicator is higher
or equal than one and lower than 6 as the NMEA standard indicates that is a valid sentence
Finally, the latitude and longitude are rounded up to 6 significant decimal figures as well as
the altitude is converted into meters. So that, the GGA sentence is acquired, validated and
returning its checking to proceed with the next NMEA sentence called GSA (GPS-DOP and active
satellites)
Implementation
48
4.3.2.3 GSA data Validation
This sentence is the whole responsible of sending the quality of a GPS sample. It includes the
numbers of the satellites on view and the dilution of precision, which is a non-dimensional
indicator at the effect of satellite geometry on the accuracy of the fix (smaller is better). Hence,
this NMEA sentence is only validated if and only if the data is fixed to 2D or 3D as it depicted in
the Figure 41
Data
validated
GSA data
Validation
Data fixed to
2D or 3D?
No
GGA checked?
No
YesYes
Return GSA check
Dilution Of Precision
V-Dilution Of Precision
H-Dilution Of Precision
Figure 41: GSA sentence data Validation and Acquisition activity diagram
Afterwards, the precision of the GPS sample is acquired in terms of its dilution of precision
(horizontal, vertical and total), returning a checking over GSA sentence which will allow to
investigate the total content and amount of next GSV sentences that arrive to the Raspberry Pi.
4.3.2.4 GSV data Validation
This NMEA sentence provides information about the satellites on view in terms of its SNR (dB-
Hz), azimuth (degrees) and elevation (degrees), thus the programmed script analyses all upcoming
sentences and validates the data of those satellites which have a SNR greater than 3dB as it could
be depicted in the Figure 42
Data
validated
GSV data
Validation
First GSV
sentence?
GSA check?
No
yesYes
Return all GSVs
check
Return First
GSV check
No
Last GSV
sentence?
Yes
Return midlle GSV
sentence check
No
- Number of satellites on view
- [SNR (dB-Hz), Elevation and Azimuth degrees] per Satellite
on view with SNR > 3 dB
Data
validated
Figure 42: GSV Sentence/s Validation and Acquisition activity diagram
A System for Vehicle Sensor Data Acquisition Based on CoAP
49
It is important to note that the above implementation cares about how many GSV sentences reach
to the raspberry Pi, so the final amount of data is variable and depends on the number of
available satellites on view. After completing one entire cycle and all GSV sentences were
checked, it is time to store this cached data into the Raspberry Pi for its further treatment as
resources of a CoAP server.
4.3.3 STORE DATA
According to the last subsections where all the data was already cached in the Raspberry Pi, these
files are stored encoded using JSON format because of the following advantages against others
format like XML:
It is lightweight and a valid subset of Python and other scripting languages as JavaScript.
It parses generally faster due to its simplicity and extensibility.
Its small grammar maps more directly onto data structures.
For this purpose, the json library [48] is utilised in order to dump the data into a suitable json
object, which will be written as a simple file following the next Figure 43
Store GPS
information
GPS Data
GPS device
specifications
GPS Satellites
information
Write data in
local drive
Written error?
No
Yes
Exit
program
Figure 43: Store GPS data activity diagram
Each file stored on the hard drive of the M2M gateway will have an aspect shown in the Table 6
Table 6: GPS data stored in JSON format
JSON file name Example (key field in bold)
Size range
estimated
(bytes)
Refresh
rate20
Current_GPS_
SAT_Info 21
{"AziDeg_16": "299", "AziDeg_21": "290",
"ElevDeg_16": "39", ElevDeg_21": "70",
"SNR_16": "21", "SNR_21": "22"}
100-800 ~1.5 Hz
Current_GPS_
Data
{"ALT": 48.9, "GS": 1.02, "LAT":
51.462038,"LON": -0.977977,"SOT": 7,"TS":
"09:23:32", "HDOP": 1.22, "PDOP": 1.47,
"SOV": 12, "VDOP": 0.83}
140-200 ~1.5 Hz
20 A set of NMEA sentences is acquired every second and the processing time of this script is
around 500 ms 21 Please note that the number on the right of each parameter, corresponds to the Sat ID which
identifies unequivocally every single GPS satellite
Implementation
50
Finally, these lines have just described the procedure of data management in terms of
generation, acquisition, validation and storage, which is performed in the background as an
independent and parallel process to keep refreshing the data along the vehicle is moving on the
road.
Figure 44: Background independent process for data management
4.3.4 INITIALISE COAP SERVER AND RESOURCES
The next main activity of the diagram is the initialisation of the CoAP server and its resources.
Hence, the initialisation of a CoAP server in a M2M gateway using CoAPthon [34] libraries is
performed in two clear steps:
Defining the resources to be exposed in the CoAP server
A new class which extends the base super-class Resource must be created and for the purpose
of this project, 4 different resources were created and they are exposed in a tree structure as
shown in the Figure 45:
Vehicle 1
Root
Applications
GPS GPS/
Instructions Instructions/
Location GPS/Location
Sat Info GPS/satelliteInfo
Specifications GPS/specs
Figure 45: Tree resource structure
Defining the server engines that will be interconnected between them after the M2M
security procedure is successfully performed:
o UDP Server engine
It includes the WAN initialisation and the instance of methods directly related to the
transmission; send_datagram and receive_datagram adapted by the SIM800 modem.
o CoAP Server engine
It includes the initialisation of CoAP sublayers like requests, responses and messages as
well as the message retransmission and further classes or methods collected in the
CoAPthon library. Finally, the already initialised resources must be linked to the CoAP
server engine following this way
A System for Vehicle Sensor Data Acquisition Based on CoAP
51
4.3.4.1 Instructions resource
The instructions resource is shown as a proof of concept of the CoAP protocol to confirm and
demonstrate its powerful resilience as a future RESTful protocol in constraints
environments over UDP
In addition, this resource includes a simple way of communication to exchange some kind of
instructions between the user of the M2M device (drivers) and the final M2M users. In other
words, its main utility is to establish a way of communication between the users of the M2M
server application and the drivers as it will be endorsed afterwards. Figure 47 shows the
implementation of this resource in the M2M gateway.
Figure 47: Definition of the Instructions resource
Figure 46: Resource initialisation
Implementation
52
This resource will be either reading from the M2M Gateway when processing a GET request (a
user asks for the value of this resource and retrieves any instruction already stored on it), writing
on the Raspberry Pi when receiving a POST request (updating or creating the information in the
same way) or deleting the instructions when receiving a DELETE request.
4.3.4.2 GPS data, specifications and satellite information resources
This resource is implemented via a class that implements the GET_render method for the GPS
location resource (refers to Figure 48) and leaves the POST, DELETE and PUT requests as
abstract methods with a pass Python statement to avoid any other exception execution during
its call. Besides, these class resources are keeping their stored data in JSON format as it was
introduced in the state of the art, the uint 50 refers to the reduced internet-media-type of
application/json
Figure 48: Definition of the GPS location resource as an example
The rest of GPS resources indicated in the figure 46Figure 45 are initialised in the same way and
the only difference among them it is the JSON file that are attempting to read.
4.3.5 INITIALISE WAN
This main activity comprises many small methods, functions and classes instances in order to
achieve a proper GPRS connectivity for the Gateway device. Therefore, the most representatives
are shown as blocks of activity diagrams with its title as distinctive. Please note that:
The algorithms exposed below correspond to a detailed and elaborated way of
programming strictly following the SIM800 series manual AT commands [52], the serial
Port SIM800 series [53] and the IP application Note [54]
The following Python programming classes involved in these activity flows were developed:
o SIM800L Includes the highest level methods in order to perform main activities
A System for Vehicle Sensor Data Acquisition Based on CoAP
53
o SIM800L_GPRS Includes methods and attributes related to GPRS and UDP
server establishment, like sending and receiving UDP packets
o SIM800L_GSM Includes methods that perform auto-sync baud serial connection,
hard reset of the device and check its network
o SIM800L_SerialApplication Main collection of functions in order to
communicate with the serial UART port during the full initialisation and
intercommunication process
The WAN initialisation process consists of basically three main activities and can be depicted in
Figure 49:
WAN initialization
Initialise
SIM800L
Check and
attach GPRS
Check and set UDP
extended mode
Figure 49: WAN initialisation activity diagram
Initialise SIM800L: Begins the serial communication with the serial SIM800 module.
Includes other two key activities:
o Initialising serial communication via auto-syncing baud rate and checking network
o Hard-reset SIM800L performed when modem does not initialise or the PDP context
is lost.
Check and attach GPRS: starts the process of network attachment through bearer settings
for applications based on IP, where a GPRS checking status must be performed before and
after attaching to the network via query bearer with the aim at verifying proper connectivity.
Check and set UDP extended mode22: starts the process of checking the status of UDP
extended mode and must return True in order to continue with the program. Otherwise, the
program would escalate a fatal error.
4.3.5.1 Initialize SIM800L
In the same way as the pyserial libraries were used for the GPS device application, the SIM800L
conducts the same initialisation process but using a different serial port, in this case the UART
and usually defined in Linux as the serial console, /dev/ttyAMA0. It is depicted in the Figure 50
Figure 50: SIM800 serial implementation
22 UDP extended mode is a term referred in [52] as a simple way to expand the UDP socket
capability to send and receive UDP datagram at the same time
Implementation
54
Initialise
UART Serial port
Open
port
Port opened?
Flush input/output
serial bufferYes
Exit
program
No
Set Serial
port
Figure 51: Initialise SIM800 serial port activity diagram
From our own perspective there was a lack of SIM800 series implementations over Python in order to achieve the goals and objectives established. Therefore, an entire Python library was
programmed from scratch for the SIM800L module which provides methods for serial port
initialisation, command checker, Attach, Detach, Check GPRS bearer, set an UDP extended mode
and exchange UDP packets between two endpoints with error corrections in the middle of any
transmission due to possible communication signal losses or other unknown causes.
Without entering in deeper details with the library, the method in the Figure 52 performs both
instructions:
1. Sending the string command to the module.
2. Waiting for any response within a 5 seconds window time (programmable)
3. Comparing the obtained results that by default are “OK” or “ERROR”.
Figure 52: Send command and check response SIM800 implementation
When the SIM800 is ready to be initialised and all methods and classes are properly imported,
the script performs the auto-banding setting. Thus, the modem automatically detects the baud rate
of the host device (already set to 115200 bauds in the port tty/AMA0) sending the simple “AT
string and waiting until the Raspberry Pi receives the “OK” response. If there would be an Echo
response (“AT” is returned by the input serial line), it must be deactivated by sending the
command “AT0”.
Besides, if no response is read through the input serial line and the “AT” string was sent more
than 5 times, a hard reset must be performed on the modem (see Hard reset SIM800L). This whole
process is depicted in the Figure 53
A System for Vehicle Sensor Data Acquisition Based on CoAP
55
Write line "AT"
Read data = "OK"?
Attempts++
Read data = "OK"x3?
NoAttempts > 5?
No
Yes
Write "ATE0"
Write line "ATV1"
Yes
Read data = "AT"
No
Write line "AT+CMEE=0"Write line "AT"
Yes
Init SIM800L
Hard reset SIM800L
Yes
Write line "AT+CGREG?"
Read data =
"+CREG: 0,1"?
Attempts++
No
Read data =
"ERROR"
"+CREG: 0,0"
"+CREG: 0,3"?Attempts > 5?
YesHard reset SIM800L
No
No
Figure 53: SIM800 Initialisation process activity diagram
Moreover, and for the target of this programming script, the entire-string response and the error
string-code must be disable sending the commands “ATV1” and “AT+CMEE=0”, respectively.
Finally, the SIM800L is also embedded and ready to work in order to conduct an automatic
network registration when the radio signal is reachable, therefore a network checking status is
needed when the modem is configured via the command “AT+CREG?”23.
4.3.5.1.1 Hard reset SIM800L
Nevertheless, something may go wrong and a system reboot might be required. Thus, a reset pin
(RST) is actually present in one of the pin-outs of the SIM800L EVB in order to provide a hard
reset when the AT command “AT+CPOWD” = 1 does not have an immediate effect on the
embedded chip. If this action is required, the RST pin must be pulled down to ground or where a
VIL is lower than 0.6V for at least 105 ms as shown in the Figure 54
23 Please note that the script does not include a way to whether check if the micro-SIM uses any
kind of PIN. Therefore, its deactivation is mandatory. Otherwise, the AT command
“AT+CPIN=XXXX” must be implemented, where the XXXX is the Personal Identifier Number
Implementation
56
Figure 54. Reset PIN time and voltage amplitude VIL
For this implementation, this function is called when the SIM800 does not respond or there is a
problem with the GPRS connectivity. Moreover, it will also initiate the Init_SIM800L activity as
well in order to check whether this hard reset was successfully achieved or not. This is achieved
using the Python script of the Figure 55
Figure 55: Hard reset SIM800L implementation
Also, the GPIO.RPi libraries [55] were used for this purpose to keep the level of the GPIO number
17 at a LOW (0V) state for at least 300ms24
4.3.5.2 Check and Attach to GPRS
The bearer data service will be the process to allow bidirectional transmissions of UDP
packets between the two endpoints of the system, it means between the M2M Gateway
(Raspberry Pi as CoAP server) and the M2M Server (as CoAP Client). Therefore, the SIM800
must start its attach request configuring the AT commands “AT+SAPBR” with the User, Name
and Password as previously was provided for its initialisation.
“AT+SAPBR” = <cmd_type>, <cid> [, <ConParamTag>, <ConParamValue>]
Where, <cmd_type> refers to 0 Close Bearer. 1 Open Bearer. 2 Query Bearer. 3 Set
bearer parameters or 4 Get bearer parameters. <cid> is the bearer identifier and might be 1 or
2 25. <ConParamTag> indicates either a “GPRS” or “CSD” connection and the strings for the
24 It is not 100% predictable for how long the GPIO will be set down as Python might be busy
doing other tasks as garbage collecting. Thus, to avoid further issues, the minimum time for a
hard reset was triply increased from 105ms to 300ms 25 The SIM800L allows the initialisation of two bearers for the same device
A System for Vehicle Sensor Data Acquisition Based on CoAP
57
User, Pass and Name. Finally, <ConParamValue> indicates the GPRS rate at which the modem
will negotiate the connection, thus it is set by default at 9600 bauds.
Firstly, the programming script must make sure that the SIM800 is not connected to the network
yet. Otherwise, the activity would end. Thus, the Figure 56 shows a GPRS checking in order to
figure out what is the modem state.
Check GPRS
Write line
"AT+SAPBR=2,1?"
Read data [2] =
"+SAPBR: 1,3,"0.0.0.0"?
Yes
Read data [2] =
"+SAPBR: 1,1,"X.X.X.X"?
No
YesReturn
SIM800
is closed
Read data [2] =
"+SAPBR: 1,0,"X.X.X.X"?
Read data [2] =
"+SAPBR: 1,2,"X.X.X.X"?
Yes Yes
No
Return
Unknown state
Return
SIM800
is connected
Return
SIM800
is closing
Return
SIM800
is connecting
Figure 56: GPRS check activity diagram
Secondly, if the SIM800 is not connected, the programmed script sends a “AT+CIPSHUT” in
order to close any volatile or unwanted GPRS context opened, which does not care about its result.
Thirdly, the attach request starts and the modem receives parameters as depicted in Figure 57:
Attach GPRS
Check GPRS
Write line
"AT+SAPBR=3,1,"APN","$APN_Name"
Write line "AT+CIPSHUT"
SIM800 is connected?
Yes
No
Write line
"AT+SAPBR=3,1,"CONTYPE","GPRS""
Write line
"AT+SAPBR=3,1,"USER","$APN_User"
Write line
"AT+SAPBR=3,1,"PWD","$APN_PWD"
Check GPRS
SIM800 is connected?
Yes
No Hard rest SIM800L
Figure 57: GPRS attach activity diagram
Implementation
58
The GPRS attach activity ends when the modem is finally connected to the PDP context and then,
can perform other kind of activities such as the setting of the UDP extended mode, which will be
introduced in the next section.
4.3.5.3 Check and Set UDP Extended Mode
To support the bidirectional communication between the CoAP client and server, the modem was
configured, to support the simultaneous reception (up to 1460 bytes per datagram) and sending of
UDP to any IP address and port, according to the embedded API socket functionality described
in the Series TCP/IP Application Note [54].
To do this, firstly, the script will check the connectivity of the current modem for a single IP
connection sending the “AT+CIPUDPMOD?” read command. Thus, in function on its response,
the module will perform the setting of the UDP extended mode or, otherwise if the read data
matches the string “+CIPUDPMODE: 1, $IP_M2M_SERVER, 5683” will end the activity.
Secondly, if the UDP extended is not configured in the modem yet, the own method will ask
whether the SIM800 is attached to the network or not. In a negative response, the previous step
of GPRS attach will be performed and with a positive response, the script will conduct to set the
UDP extended mode.
The Figure 58 explains graphically these steps.
Check UDP
extended
mode
Write line
"AT+CIPUDPMODE?"
Read data =
"+CIPUDPMODE: 1,
$IP_M2M_Server, 5683"?
Yes
SIM800 is connected?
No
Set UDP Extended Mode
Yes
Attach GPRSNo
Set UDP Extended Mode
Figure 58: Check UDP extended mode activity diagram
In order to configure the UDP extended mode [54], it is important to consider some relevant “AT”
commands that will limit the response of the modem in terms of receiving UDP packets or bind
a local port as also depicted in the Figure 59
“AT+CLPORT= UDP”, 568326 will set and bind the UDP local port for start listening
incoming CoAP requests
“AT+CIPSRIP” = 1 will display the IP address and the destination port of any incoming
request before the payload. In terms of format: “RECV FROM: <IP ADDRESS>:<PORT>
“AT+CIPHEAD” = 1 will add an IP header before the receiving data
“AT+CIPUDPMODE” = 1 will enable UDP extended mode in the modem
26 The port 5683 is the UDP CoAP port recognised by the IANA
A System for Vehicle Sensor Data Acquisition Based on CoAP
59
set UDP
extended
mode
Write line
"AT+CIPHEAD=1"
Write line
"AT+CIPSTART="UDP",$IP_M2M_Server,"5683"
Write line
"AT+CLPORT="UDP", 5683
Write line
"AT+CIPSRIP=1"
Write line
"AT+CIPUDPMODE=1"
Read data =
"CONNECT OK"?
No
Yes
Attach GPRS
Figure 59: Set UDP extended mode activity diagram
The last step is initialising the connection against the M2M server with the IPv4 added as
precondition at the beginning of the programming script:
“AT+CIPSTART = “UDP”, $IP_M2M_Server, “5683”
At this point, after confirming the “CONNECT OK” by the SIM800, the modem is fully ready to
send its first CoAP packet to the M2M Server.
4.3.6 READ INPUT SERIAL BUFFER
This is for sure, one of the most important activities within the UDP server engine as it refers to
the daemon-thread 27 which reads constantly all possible situations encountered in the input serial
buffer of the SIM800 and updates the main thread or other processes with its results.
In order to perform this goal, there are two basic things to reflect from the implementation:
Define a low level method for reading all data coming from the input serial buffer
Figure 60: Checking input serial buffer implementation
Exchange information among threads and processes. Concretely between the processes
created to send UDP packets and the main thread which needs UDP packets to interpret as
possible CoAP messages.
The safest way to implement this is via Fist Input, First Output (FIFO) queues, which are
implemented in the Python Module Queue [51] and execute multi-producer and multi-consumer
27 A daemon-thread represents an activity that runs out of the main or thread of control and is not
affected by any others process or threads until the entire Python program exits.
Implementation
60
queues, easily manageable with GET and PUT methods as well as straightforward checkable with
EMPTY and FULL calls
For example, when a UDP packet is sent, the particular process that is handling this activity must
wait until the SIM800L responds with a “SEND OK”. Hence, this daemon-thread will return the
result to the Queue with a PUT call when this string is received through the serial input buffer.
Thus, the UDP send process will be able to continue with its duties.
In the same way, this approach concerns the rest of possible values for UDP packets that reach
the SIM800, in terms of Data mode ON and any possible Error
Return None?Read input
seria
buffer
Return ">"? Return "SEND OK"?Return "UDP"?
No No No
Yes DATA MODE
queue++
UDP PACKET
queue++
SEND OK
queue++
Error Set queue++
Put datagram
into UDP
packet queue
Yes Yes No
Return "ERROR"?
No
Yes
No
SIM800
stopped?
Yes
NoCheck serial
input buffer
Figure 61: Read input serial port after initialising activity diagram
The error queue is handled separately in order to avoid losses of packets in the application.
Concretely, in the next section, the implementation of sending UDP packets.
A System for Vehicle Sensor Data Acquisition Based on CoAP
61
4.3.7 SEND UDP DATAGRAM
At any time and whenever the CoAP server would like to send a CoAP message to the M2M
server in terms of responding a request, it must utilise the method defined on the activity diagram,
which is in the Figure 62:
Send
datagram
Is a CoAP Message
instance?
No
Serialize CoAP
message to bit-streamYes
Send UDP packet to
serial port
Set error
Figure 62: Send datagram diagram activity diagram
The datagram must be a CoAP message instance (response with any options and/or any payload)
in order to pass and become serialized28 into a bit-stream ready to be sent through the network.
The next method shows how the bit stream is prepared to be sent via the output serial port of the
SIM800 modem.
4.3.7.1 Send UDP packet to serial port
Set UDP
packet error
UDP packet
size > 1460?
Yes
Write line
"AT+CIPSEND=
$UDP_SIZE"
Write UDP
packet
Error Set
queue
empty?
Data Mode
queue
empty?
No
Get ERROR from
queue
Yes
Check UDP
Extended Mode
No
Release main
thread
YesGet Data mode
from queueNo
No
Sleep
200ms
Send OK
queue
empty?
Get Send OK
from queueNo
Send
UDP packet
Start Parallel
Process
SIM800 free?
Yes
No
Wait until free
Aquire main
thread
Figure 63: Send bit stream packet via serial port activity diagram
28 The message serialisation is performed with libraries found in the CoAPthon package
Implementation
62
The programmed script only allows to send a bit stream of data simultaneously due to its fancy
way of real-time error-checking and because of the daemon-thread runs in parallel exchanging
data via FIFO Python Queues as it is illustrated in the Figure 63
Once the process of sending a UDP packet is initiated, a parallel process starts and the rest of
the program in exception of the daemon-threads waits until its ending.
The AT command “AT+CIPSEND = $UDP_Size” will let know the modem that something of
$UDP_size wants to be sent through the UDP connection previously established. Therefore, if the
daemon-threads finds the symbol “>” coming from the input serial buffer, the data mode queue
will not be empty and the packet can be sent with a simple raw write of data if and only if the
Error Set Queue is empty. Otherwise, the main method will be acquired via a simple lock method
proposed in Threading for Python [50] and the GPRS bearer will be checked in order to ensure
that the modem is still “CONNECTED”. Thus, if the SIM800 is not connected, all methods above
explained regarding to GPRS Attach and Set UDP extended mode are conducted. Finally, the lock
process will be released when the normal connectivity is actually present and the
“AT+CIPSEND” command will be executed in the exactly same way. Something similar must
occur in order to join this parallel process to the main thread. Hence, a “SEND OK” must be
received from the daemon-thread, otherwise an error-checking is handled.
A validation example will be exposed when the first CoAP packet is going to be sent in the next
chapter.
4.3.8 READ UDP DATAGRAM
This method, depicted in Figure 64 will be able to provide UDP datagrams to the CoAP server
engine as well as to the M2M security procedure in order to obtain the first CoAP response from
the M2M server.
Basically, it consists of same information exchange between queues that is handled by the
daemon-thread as already explained in the section 4.3.7.1. However, this method will be trying
to get the packet from the queue during a time window of 10 seconds and so, if the timeout expires,
the method will return a None value
Read
UDP buffer
UDP Packet
Queue
empty?
Starting
time
Get datagram
from UDP queue
No
Start.time < (Start.time + 10 seconds)
Yes
None
No
Yes
Figure 64: Read UDP buffer activity diagram
Again, an example of this method will be exposed in the next chapter, where the M2M
authentication and driver identification is conducted.
A System for Vehicle Sensor Data Acquisition Based on CoAP
63
4.3.9 M2M AUTHENTICATION AND DRIVER IDENTIFICATION
This activity is performed just when the UDP server initialisation is completed and the daemon-
thread, which reads information from the serial port, starts. Basically, the process fulfils the
minimum of security as it was indicated in the previous requirement design. It performs a method
able to send a cyphered payload of the first CoAP packet with a shared and unique key that
identifies a vehicle itself and also the driver who is using the M2M device via the CoAP token
header.
In addition, this step contemplates another activity that comes from the M2M server in order
to analyse the response to this first CoAP packet sent already. The Figure 65 shows the process
of this activity
M2M Authentication
step
Driver
identification
4-digit numeric
length?
No
First CoAP packet
initialisationYes
Send datagram
Read datagram
CoAP response
with Valid Code?
Yes
No
Is JSON Payload and
contains "REGISTERED"?
Yes
No
Return pass
Yes
CoAP message
received?
No
De-serialise
CoAP message
Decypher
Payload
Cypher CoAP
payload
##CoAP HEADER##
+Version: 1
+Type: Confirmable
+Token Length: 4
+Code: Response.CREATED
+Message ID: 1
##TOKEN##
-Token: 4-digit Driver ID
##OPTIONS##
-Content Type: JSON
##PAYLOAD##
Shared_Key (to be cyphered)
Figure 65: M2M authentication and driver identification activity diagram
Implementation
64
The driver identification scheme is provided as a simple way of driver recognition in order to
fulfil one of the main M2M requirements. Hence, the driver will be asked to introduced a numeric
ID number previously agreed with the company in order to identify him/herself in the M2M
server.
Figure 66: Driver identification implementation
At this time, the M2M gateway can start the initialisation of the first CoAP packet with the above
collected code and fill the rest of the fields as indicated in the activity diagram.
The next step will cypher the shared key provided as precondition for the system with the
Python crypto libraries that allow a very strong AES-256 bits which is already implemented and
used by [56]:
Thus, a pad function will be needed in order to perform the data encryption when the length is
not a multiple of 16, which makes reference to the Block_Size (BS) adopted as referenced
Figure 67: Pad function implementation
Please note, that this implementation shares the same encryption-key between the M2M
gateway and the server in order to allow the encryption which should be stored in a safe place
and not in the way as it is shown here.
Figure 68: Shared encryption key between M2M gateway and server
Afterwards, the encryption process starts with the call to an initialisation vector used to bewilder
the output of the encryption when the input is the same. For this purpose, a random string was
chosen thanks to the Crypto library and the standard method AES-CBC is applied as cipher,
referred at [57]. Finally, the payload will be returned with an encode typically of base64 in order
to be safely sending it through the network as part of a CoAP payload.
Figure 69: Encrypt method implementation
Following the Figure 65, it is the turn of sending the first CoAP message, creating a process
instance of the send datagram method. Thus, immediately, the programming script will start to
conduct the read datagram method explained to catch the response coming from the M2M server
which must answer to this first CoAP packet.
A System for Vehicle Sensor Data Acquisition Based on CoAP
65
Thus, the M2M gateway application will perform the de-serialise process via CoAPthon libraries
and then, the validation of the message received.
At this point, the datagram is received, de-serialised and checked that is a Valid Response Code.
Also, the server has identified the driver and validated him/her on the system.
Thus, a reverse decryption method is requested again and an unpad function will be needed as
well as it was demanded for the previous encryption step. The following figure shows the function
to decrypt the CoAP payload using the reverse approach and also the same encryption key.
Figure 70: Unpad and decrypt functions implementation
Finally, the payload should be a text plain in json format that indicates whether the car is registered
on the platform or not.
4.3.10 LISTEN AND PROCESS COAP REQUESTS
This is the core of the CoAP server engine as it will be expected to be responsible of listening,
receiving and processing CoAP requests and sending CoAP responses to the M2M server that in
this case is acting as CoAP client due to the CoAP basic scheme introduced in the State of the Art
and proposed in the solution design.
The hard work of CoAP implementation is already achieved by the CoAPthon [31] libraries and
the main thread runs continuously as an infinity loop which performs the functions previously
named.
Listen and
Process
CoAP requests
listen UDP and
keep alive
De-serialise
UDP datagram
Process CoAP
request
CoAP
response?
Set error and show
message source
Yes
Yes
UDP packet?
Yes
No
CoAP
request?
CoAP
message?
Yes
Send datagram
Prepare Reset
message
No
No
No
SIM800
stopped?
No
Yes
CoAP Sub-layers
- Resources
- Messages
- Requests
- Responses
Figure 71: Listen and process CoAP messages
Implementation
66
At this moment, it is just necessary to review the last activity which is listening to UDP packets
and is incited to send keep alive packets29 after non receiving response in a window time between
170 and 180 seconds 30
Listen to UDP
and
keep alive
Keep alive
initialisation
Read
datagram
UDP packet?
Keep Alive
counter ++
Send
datagram
Counter % 15 is 0?
Return UDP
packet
No
Yes
Return NoneYes
Return None No
##CoAP HEADER##
+Version: 1
+Type: NON-Confirmable
+Token Length: length.of.Token
+Code: Response.CREATED
+Message ID: 2
##TOKEN##
-Token: random.uint(100,1000)
##OPTIONS##
EMPTY
##PAYLOAD##
"Keep-Alive"
Figure 72: Listen to UDP packets and keep alive diagram activity
4.3.11 STOP SERVER AND CLOSE GPS DEVICE APPLICATION
The initialised application can be closed at any time just pressing CTRL+C or can finish due to
an unexpected error in the authentication and/or identification step. Therefore, a mechanism starts
to run in the application as depicted in the Figure 73
Stop server
and Close GPS
device application
Detach GPRS and
power off SIM800L
Close SIM800L
Serial port
Close GPS
device app
Stop server
engines
Figure 73: Stop server and close GPS device application activity diagram and implementation
29 The keep alive packets are seen as a concept of CoAP ping, where an Empty message is sent. 30 Please note that Python as scripting language is unpredictable most of the time, as many other
tasks can be performed at the same time. Like threads, processes or garbage collection among
others…
A System for Vehicle Sensor Data Acquisition Based on CoAP
67
The SIM800 is stopped and the script proceeds to detach the GPRS bearer executing the following
commands:
“AT+CIPSHUT” in order to close the current and established UDP extended mode
connection with the M2M server
“AT+SAPBR=0,1” with the intention of deactivate the GPRS bearer
Additionally, the SIM800L must be powered off by sending the command “AT+CPOWD = 1”
and receiving either a “NORMAL POWER DOWN”, “+PDP: DEACT” or “SAPBR 1: DEACT”.
Then, both serial ports of the GPS device application and SIM800 modem are closed by its own
method of serial.close()
4.4 M2M SERVER IMPLEMENTATION
This section will describe the implementation conducted for the M2M server in order to achieve
an overall knowledge of its activity processes as well as it was acquired previously in the M2M
gateway implementation.
In reference to the Figure 74, firstly, there is again an assignation of preconditions or parameters
in order to configure the execution of the M2M server:
IP M2M Server. It is mandatory to include the self-valid IP of the M2M server against
is going to be running and bind the HTTP server and the CoAP client under UDP
Shared key for the M2M authentication step performed against the server31.
ID driver list for the identification process that will allow to establish a CoAP session or
a M2M communication
Frequency rate for the auto-request implementation. It will determine a very
approximate value in seconds for the frequency of sending automatic requests to the
CoAP server located at the M2M gateway
Secondly, the CoAP client engine is initialised as well as its UDP protocol that runs behind,
concretely the socket library (low-level networking interface), which is used as driven-networking
engine of the CoAPthon library [31]. Moreover, the CoAP GET, DELETE and POST requests
are also initialised in order to provide a quick way to send them either by the M2M Web RESTful
application or the automatic gathering daemon-thread. Thirdly, the M2M security step is
performed in order to verify and authenticate the vehicle and via the first CoAP packet sent by
the M2M gateway and also, to identify who is the driver of the vehicle. Note that this activity
must return “pass”, otherwise the program would abruptly end with an exit error. Fourthly, two
parallel threads will start with a unique thread of control in order to allow the simultaneous use
of the CoAP client engine to communicate against the CoAP server located at the M2M gateway
via the user agent application that will be initialised and the mechanism to auto-fill the outcome
report (a CSV spreadsheet) with the data gathered from the GPS device. Thus, this core activity
process is split into two parallel activities.
The process of automatic gather GPS data that will send requests in function on the
frequency rate specified32
The HTTP server initialisation to allow users perform CoAP requests to the M2M
gateway via the HTTP method GET
Finally, the process will end in the same way as the M2M Gateway ends, by the signal system
SIGNIT (CTRL+C)
31 Note that this shared key must be the same as given to the M2M Gateway. 32 Please note, that the frequency rate is very approximated and the real window time could
oscillate between a relative error of +- 10 seconds due to packets losses, server response time,
network delay and other concerns out of the project scope
Implementation
68
CoAP client engine
Low-level networking interface
RESTful CoAP
Initialise
CoAP client
M2M Server
Application
Assignate
Preconditions
Start automatic GPS
data request
Keyboard interruption?
YesClose HTTP Server
and CoAP client
M2M web RESTful
application
Process CoAP messages
First UDP packet
received?
YesPerform M2M
security step
Authentication and
identification
pass?
Initialise CherryPy and
HTTP web Server
POST request
GET request
DELETE request
Initialise UDP
protocol stack
Send
datagram
Receive
datagram
Yes
User Web
Interface
User
choice
CoAP client
calls
No
CoAP client
calls
No
1) IP M2M Server (self)
2) Shared Key
3) ID driver list identification
4) Auto-request frequency
Figure 74: M2M Server activity diagram33
33 Please, consider that red connectors make reference to calls executed by any other activities
against the CoAP client engine whilst the blue ones are intended to be distinguish as also calls to
the CoAP client engine but just for initialise a CoAP request either by a parallel thread or the user
A System for Vehicle Sensor Data Acquisition Based on CoAP
69
4.4.1 INITIALISE COAP CLIENT ENGINE
For a second time, our CoAP client engine is based on the CoAPthon libraries and use all its 4
layers as well as the Socket low-level networking interface in order to process the server responses
and requests. Thus, the implementation centres on its CoAP message processing (main activity
core) and on the CoAP request methods that will be exchanged.
4.4.1.1 Process CoAP messages
In the next activity diagram of the Figure 75 is described the core of the CoAP client engine
explaining the process of CoAP messages management and its relationships with the Twisted
framework in order to send and/or receive UDP datagrams
Process CoAP
messages
Start
communication
with Twisted
framework
UDP packet
received?Received
Thread
SIGNIT?
Send CoAP
message
No
Exit
program
Yes No
Yes
Prepare RST
messageNo
Message payload
is "keep-Alive"?
Reset
timer
CoAP
message?
CoAP
response?
First UDP
packet?
Yes
Yes
No
Proceed
accordingly
Yes
Start
timer
Timeout?
Reset
timer
NoDe-serialise
UDP packetYes
Exit
program
No
Yes
Parallel
thread?
Keep
running
No
CoAPthon
layers
Figure 75: Process CoAP messages activity diagram
The main functionality occurs on the top of the Figure 75, where starts a parallel thread in order
to perform a couple of things:
Notify to the entire system that the first UDP packet has arrived and then, conduct all required
activities (see
Perform M2M security).
Implementation
70
Start the timer34 of the server which will determine whether the system would need to exit
or not, either because of lack of connectivity against the M2M gateway nor keep working due
to keep alive messages are arriving even when no requests are sent.
Process all CoAP responses and messages that should reach from the M2M gateway (CoAP
server) after either sending requests or just due to other reasons, like sending a RST message
after receiving neither a response nor a Keep-Alive message (see in the above diagram,
Prepare RST message)
On the bottom takes place the parallel process from where other activities are able to send CoAP
requests that is executed as a parallel process
4.4.1.2 CoAP Requests. GET, POST and DELETE
In the Figure 76 is shown an example of implementation code for a GET request where the
CoAP header is filled as well as its URI_PATH option which will indicate where to gather the
data in the CoAP server of the M2M Gateway
Figure 76: CoAP GET request implementation
Bear in mind that the main difference among POST, GET or DELETE requests differs in the
request code and if it is a POST method, it might include a payload. Therefore, the
implementation is not specified here as it is almost the same approach for each method.
4.4.2 PERFORM M2M SECURITY MECHANISM
This activity is the second and complementary part of M2M security implemented in the system.
It represents the ability to authorise a vehicle in the system as well as deny any unauthorised use
of the system (in terms of driver identification and vehicle authentication). Therefore, the activity
34 Bear in mind that the timer starts and is reset within a time window of 220s in order to allow
possible undesired delays or packet losses
A System for Vehicle Sensor Data Acquisition Based on CoAP
71
starts when a UDP packet arrives from the network at the port 5683 whose socket must have
performed its bind as follows Figure 77:
Figure 77: Socket bind on the M2M server IP35 implementation and recvfrom method
Figure 77 shows a lot of information regarding to the type of Socket in use and also the way to
obtain the dynamic IP and destination port of the M2M gateway when it sends the first message
towards the address $M2MserverIP:5683
Load json format
into Python dict.
M2M security
step
De-serialise UDP packet
to CoAP message
Decrypt message
payload
CoAP
response?
Password Key
matches?
No
Exit
program
Payload with
legible JSON format?
Yes
No
Yes
No
Exit
program
Check token value with ID
list of authorised drivers
Yes
Driver in
the list?
Send CoAP message
Send CoAP message
Return
pass
Yes
No
##CoAP HEADER##
+Version: 1
+Type: ACK
+Token Length: CoAP request (same)
+Code: Response.FORBIDDEN
+Message ID: 1
##TOKEN##
-Token: CoAP.request (same)
##OPTIONS##
EMPTY
##PAYLOAD##
"User not recognised in the system"
##CoAP HEADER##
+Version: 1
+Type: ACK
+Token Length: 4
+Code: Response.VALID
+Message ID: 1
##TOKEN##
-Token: Driver ID
##OPTIONS##
- Content Type: JSON
##PAYLOAD##
JSON
{"Car":"REGISTERED"}
Figure 78: M2M Security mechanism activity diagram
As per it is depicted in the activity diagram of the Figure 81, the second thing to do is the de-
serialisation of the UDP packet to become a CoAP object36 ,easily manageable in Python. If so,
35 Note, the string parameter self._client is the M2M server IP in terms of CoAP terminology and
implementation design 36 This method is conducted with CoAPthon libraries [31]
Implementation
72
next step must be decrypting the payload of the message with the same encryption key, as it was
explained in previous paragraphs (see M2M Authentication and Driver Identification)
Finally, ensure that reacts as valid JSON format. Then, the shared key is compared between any
supposed list or database storage that contains the vehicles information. If this shared key belongs
to an own vehicle, the system will be able to perform the driver identification via the Token field
of a CoAP header and whether this token matches any registered driver or not, the server will
have an expected response for each possibility like denying the use of the system and reporting
this bad use or authorizing its use.
At this time, if the driver is identified, the M2M server will run two parallel threads in order to
automatically gather data from the Gateway and initialise a web interface for the final users of the
system. See Figure 32 for a better understanding
4.4.3 START AUTOMATIC GPS DATA REQUEST
The core activity of this M2M server achieves the general requirement imposed in the system in
order to gather data automatically from the M2M gateway using a RESTful environment and
performing the data management activities of post processing and remanence. Thus, this method
acts as a parallel thread which runs the activity diagram depicted below.
Process CoAP
response
Start automatic
GPS data request
Initialise Datasets
and Databooks
M2M
Server
still on?
Initialise
CoAP requestYes
Response from
CoAP server?
Send UDP
message
CoAP
client
call
CoAP
client
call
No
Sleep for
$FrequencyRate
Yes
Store CoAP
payload in
Dataset
Gathing GPS
Satellite
information
Similar approach
Write or append databook
with all information
Generate final
report in CSV format
No
Gathing GPS
device
specifications
Similar approach
##CoAP HEADER##
+Version: 1
+Type:NON-CONFIRMABLE
+Token Length: lengthOf Token
+Code: Request.GET
+Message ID: Random
##TOKEN##
-Token: Random
##OPTIONS##
Uri-Path1 = "/GPS/"
URI-Path2 = "/Location/"
##PAYLOAD##
EMPTY
##CoAP HEADER##
+Version: 1
+Type:NON-CONFIRMABLE
+Token Length: Same as Request
+Code: Response.CONTENT
+Message ID: Same as Request
##TOKEN##
-Token: Same as Request
##OPTIONS##
- Content Type: JSON
##PAYLOAD##
{"LAT": xxx, "LON":xxx, "TS:
"xx:xx:xx", "SOT": x, "GS": xxx.xx}
Figure 79: Start Automatic GPS data request activity diagram
A System for Vehicle Sensor Data Acquisition Based on CoAP
73
Despite of above shown, there are other three methods which are performed in a similar
approach and the only difference between them is the second URI-PATH option that must be
modified for the right URI resource in use. For instance, the GPS satellite info would be
“/satelliteinfo/” and the GPS specs “/specs/”. Additionally, in order to generate the final report
about the gathered GPS data, the Tablib Python package [58] was used to create two datasets and
one databook that can handle both datasets in an easy and fancy style. For instance, the GPS
dataset is initialised with its headers:
Figure 80: GPS dataset and headers initialisation
Then, in a pythonic way37 the payload of each single CoAP response is loaded into a dictionary
with a validation process and is handled to fill the dataset, appending rows every time. Finally,
the data is exported into a csv format file that contains all the gathered data in this way, when the
main M2M Server activity ends.
Figure 81: Final GPS data report implementation
The next subsection will introduce the main thread that runs in order to provide a frontend to the
final user of the application.
4.4.4 INITIALISE HTTP WEB SERVER. CHERRYPY AND MAKO
TEMPLATE
CherryPy [59] is one of the oldest open-source web framework available for Python and used in
the big web platform like Netflix. Its Python libraries provide a quick development way for
applications based on HTTP, thus and thanks to its simplicity and powerful style, developing with
CherryPy is straightaway, because it also includes its own production-ready HTTP server to host
an application as quick as few lines of code are written, like in our case, where a HTTP web
service will be running at http://$IP_M2M_Server:8080.
37 Term that makes reference to code that follows the conventions of the Python community, PEP-
8 and uses the language in the way it is intended to be used [70]
Implementation
74
Figure 82: Implementation to run the HTTP Web server
The above implementation code in Python would initiate an instance of the class websiteTracking
that contains methods to perform any user request as well as process the HTML and CSS code
through a parsed template provided by the Mako libraries [60] in order to fill every output or input
into any HTML label with a value coming from or towards the Python code itself. This will be
better explained in the upcoming paragraphs.
4.4.5 M2M WEB RESTFUL APPLICATION
A simple webpage was developed using HTML5 and CSS2 for the final users of the system where
they might be able to check near to real time the current vehicle position and its speed in km/h
just pressing a button called “Retrieve current vehicle location” as it is shown in the Figure 84.
Besides, the backend of this implementation comes from the auto-request data activity, which
automatically fills the latitude, longitude and ground speed on the JavaScript that runs this action
through the Mako libraries
Python variables to be
initialised within the script
Figure 83: JavaScript implementation to show current position and speed of a vehicle
Moreover, in order to demonstrate the RESTful capability of the system with other request
methods, the page encompasses three additional buttons with its respective radio buttons linked
to them with the aim at sending either Confirmable or NON confirmable CoAP messages
directly to the CoAP server and being able to create, update, gather or delete information
from the Instructions resource previously explained (see
Instructions resource) in the M2M device for further use, like establish a way of communication
with the driver.
A System for Vehicle Sensor Data Acquisition Based on CoAP
75
Figure 84: Frontend implementation for a M2M web application server
On the other hand, the backend of this implementation works also as a forward-CoAP proxy
(CoAP client) where the URI /Instructions is statically mapped to the HTTP GET method and
internally, the system performs CoAP requests methods as corresponds either for POST, GET or
DELETE
Validation
76
Chapter 5 Validation
This chapter performs a sequence of different tests and validations in order to compare and verify
the prior implementation in two different stages; general tests and a validation on a real vehicle.
Moreover, it checks possible gaps and confirms that the requirements exposed in the Chapter III
were successfully achieved.
5.1 GENERAL CONFIGURATION AND VALIDATIONS In order to perform these tests, the following considerations were taken into account, like the
replication of the equipment and configuration by means of the implementation chapter
describes.
The M2M gateway with the same implementation as shown in the previous chapter; a Raspberry
Pi model 3 covered by the frame of a tactile screen (see Figure 85) and plugged via a DSI display
port. Then, it was also plugged into a power source of 5V able to provide more than 2.5A in DC38,
and connected via Ethernet to a LAN for the first validation tests that did not require to stay
within a vehicle.
Moreover, the GPS device ND-105C was connected via USB to the Raspberry Pi and a GPIO
extensor for the 40 GPIO was used in order to take extra space outside the cover (see Figure
86Figure 85Figure 86). In terms of software, the Raspberry Pi executes the latest version of
Raspbian (September 2016) and is managed via a SSH connection from the main laptop in order
to execute any script or command, using the well-known Putty client terminal, also while the
gateway stays outside the vehicle.
Figure 85: 7" Tactile screen appearance with on-screen keyboard
38 The SIM800L may consume up to 2A in peaks of DC during transmission bursts [44]
A System for Vehicle Sensor Data Acquisition Based on CoAP
77
Figure 86: Raspberry Pi and GPS USB
The GPRS modem SIM800L (Evaluation board) was connected to the GPIO
extension board, following the wired diagram of Figure 35 and glutted outside the screen
frame. Moreover, a GiffGaff39 micro-SIM was introduced into its correspond slot.
Figure 87: SIM800L modem connected to the Raspberry Pi40
39 Mobile Virtual Network operator in the UK using the O2 radio network 40 The first prototype includes some Velcro to tape the GSM antenna and fix the SIM800L on the
screen frame. The proto-board is glutted on the back of the Raspberry Pi tactile screen
Validation
78
The M2M Server was deployed on an Asus X550JK connected via Ethernet to the LAN
where the Raspberry Pi was connected (just for management tasks, at the beginning of
the tests and when the M2M gateway was not in the vehicle) with the following main
specifications:
o Processor: Intel i7-4710HQ up to 3.5 GHz
o Hard drive: SSD Samsung 850 Pro EVO 256 GB
o RAM installed: 12 GB
o Graphical card: 850M GTX
o OS Name: Windows 10 Pro x64
o Python compiler 2.7
o Pycharm41 as graphical debugger tool
The tools used for these tests were very varied from scripts to check serial connectivity
(Minicom [61] ) until Wireshark as packet analyser on its version RC.2.25 in order to
verify and validate the CoAP messages exchanged between the two endpoints (M2M
Gateway and Server)
Environment and conditions. The first validations are performed static and out of the
vehicle with a RSRP received in the modem around -88/-90 dBm (value obtained sending
the AT command “AT+CSQ” to the modem and receiving the response +CSQ: 19/22)
and the second validations are conducted dynamically as it will be explained afterwards.
Precondition or parameters assignation:
o The APN of the service provider employed in this proof of concept is shown below
as a dictionary.
o Shared key between Server and Gateway
o IP M2M Server
o Driver ID list for identification purposes
5.1.1 DATA MANAGEMENT
Some verifications were conducted for the data management process in its terms of generation,
acquisition, validation and storage in the Raspberry Pi before starting with the whole process of
CoAP exchange, that transmit the data from the gateway to the server. In the next subsections is
indicated how this main process was conducted very briefly.
41 Pycharm [71] is an Integrated Development Environment (IDE) used for code analysis and
graphical debugger
A System for Vehicle Sensor Data Acquisition Based on CoAP
79
5.1.1.1 GPS data Acquisition
Minicom [61] was used as a text-based serial port communications program to communicate to
the Linux file ttyUSB0 (USB device) and make sure everything was operating well. A screenshot
is showed below, in the Figure 88
Figure 88: Raw GPS data generation
Thus, after running it with above configuration, the results were clear and the data were being
generated and acquired properly by the Raspberry Pi.
5.1.1.2 GPS data Validation and Storage
Once the generation of data were checked, the script could run standalone to verify the
implementation status. Therefore, the NMEA sentences must have been analysed in strict order
as indicated in the previous chapter. Hence, in the following Figure 89 is depicted how the script
was waiting until getting a RMC sentence to start the validation process.
Figure 89: Debugging RMC NMEA sentence validation
Then, the other sentences are checked and validated straightaway and following the same
algorithm, for instance, some GGA and GSA sentences were validated in the Figure 90.
Validation
80
Figure 90: Debugging GGA and GSA NMEA sentences
Finally, when a set of sentences were validated, the data must be stored in JSON format in the
Raspberry Pi as Figure 91 reveals:
Figure 91: Location storage in JSON format
5.1.2 WAN INITIALISATION
The WAN initialisation performed by the SIM800 is merely indicated in the following Figure 92
and it can validate the activity diagrams described in [Initialize SIM800L] with no attempt to reset
the device if everything run as expected.
A System for Vehicle Sensor Data Acquisition Based on CoAP
81
Figure 92: Debugging SIM800L serial initialisation with ECHO activated
Nevertheless, the SIM800 may fail during its initialisation after sending five time the simple line
“AT” via serial input. So, in the Figure 93 is illustrated the mechanism of hard reset performed
after this minor issue.
Figure 93: Debugging SIM800 series after hard reset
Validation
82
5.1.2.1 Check and Attach to GPRS
The same approach is conducted for the GPRS attach method. The Figure 94 is one screenshot of
a successful network attach via its GPRS checking and attach mechanisms42 for the APN details
utilised in the validation.
Figure 94: Debugging a successful GPRS bearer setting
5.1.2.2 Check and Set UDP Extended Mode
This validation incurs in the initialisation of the UDP extended mode that will allow execute an
UDP server in the SIM800 in order to send and receive CoAP packets. Therefore, a debug
example is showed in the Figure 95
42 Refer to Check and Attach to GPRS
A System for Vehicle Sensor Data Acquisition Based on CoAP
83
Figure 95: Debugging setting UDP extended mode
5.1.3 M2M AUTHENTICATION AND DRIVER IDENTIFICATION
This activity needs to be validated in two different ways; the first one from the perspective of
the SIM800L which is the sender of the first CoAP message, as seen in the Figure 96, and the
second one using the packet network analyser as an external source of verification out of our
influence.
Figure 96: Debugging first Confirmable CoAP message43
43 In blue is the ID driver input; in yellow, the First CoAP packet in format UTF-8 with the
payload at the end already cyphered; in red, the parallel process performing the datagram sending
method and in green is the read-serial input buffer performed by the daemon-thread.
Validation
84
Thus, the Figure 97 verifies the confirmable CoAP response44 with a 2.01 Created code, token
length 4 (ID driver identifier) sent from the M2M gateway (Src IP) towards the M2M server
(Dst IP)
Figure 97: Verifying first confirmable CoAP message via Wireshark45
5.1.3.1 Valid M2M server response
This is the authentication process (see Figure 98) that must be followed in order to establish a
CoAP session between the two endpoints. So, the server has to respond with a Valid CoAP
Response in an ACK message and its payload again cyphered just to avoid possible spoofing
attacks only during this first authentication process.
Figure 98: Verifying ACK in response for the first CoAP message sent by the M2M server (client
CoAP)
44 In terms of a request/response model, the first CoAP sent by the gateway should have been a
request instead 45 Despite the Wireshark cannot decrypt the payload of the message, the content-format is sent
as a suggestion of how the data is encoded after its decryption, to inform to the M2M server how
to proceed
A System for Vehicle Sensor Data Acquisition Based on CoAP
85
Finally, this message will be processed by the CoAP server in the SIM800 and will be reproduced
below, in the Figure 99
Figure 99: Debugging the first CoAP message from the Server in the Raspberry Pi46
5.1.3.2 Forbidden M2M server response
However, either the shared-key (password used to identify the vehicle) or the driver identification
number does not match with the server identification list, the M2M server must respond with a
CoAP response 4.03 Forbidden and its content-type must become text/plain in order to be
human readable. It is shown in the Figure 100
Figure 100: Verifying Forbidden response CoAP from the M2M server
5.1.4 AUTOMATIC DATA EXCHANGE
The M2M server is encouraged to ask to the M2M gateway about the representation of their
GPS resources (/location and /satellite-info) in a frequency basis chosen by the user47.
It means, that the CoAP client will be sending, in the background, CoAP requests to the CoAP
server to process the GPS data and store it in a CSV file as it is shown in the figures Figure 101
and Figure 102.
46 In red is the parallel process performing the datagram sending method and in green is the read-
serial input buffer performed by the daemon-thread 47 In this example, the frequency chosen was 5 seconds
Validation
86
Figure 101: Spreadsheet with GPS location data stored in the M2M server. Each line corresponds
to one CoAP response payload
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
A System for Vehicle Sensor Data Acquisition Based on CoAP
87
The next screenshot, Figure 103, Figure 104 and demonstrate how GPS data are automatically
being exchanged and captured in Wireshark via NON confirmable CoAP messages (requests and
responses)
Figure 103:Auto data request model verification for the GPS/location resource
Figure 104: Auto data response model verification for the GPS/location resource
5.1.5 KEEP-ALIVE MESSAGE
After initialising the CoAP server engine and no requests are coming through, the CoAP server
(M2M gateway) should send a keep-alive CoAP message (also known as CoAP ping) every 180-
200 seconds towards the M2M server in order to keep the connectivity up as it was described in
the implementation (see Figure 72). Therefore, in the Figure 105 is demonstrated and showed the
process via an accumulative sets of Keep-Alive messages.
Validation
88
Figure 105: Verifying Keep-alive messages
5.1.6 M2M WEB SERVER APPLICATION
In this section, a test validation is performed for the M2M web application where any authorised
user might try the functionality of “Retrieve GPS vehicle location” and the RESTful /Instructions
resource via the web application developed for them. For example, in the Figure 106 is shown the
result after pressing the blue button above the google maps and leave the cursor over the red
marker.
Figure 106: Retrieve Current vehicle location validation. Vehicle location and speed
Furthermore, the Figure 107 verifies the POST instructions method which sends a CoAP request
to the CoAP server that updates or creates the resource.
A System for Vehicle Sensor Data Acquisition Based on CoAP
89
Figure 107: Updating the Instructions Resource
Additionally, after pressing the GET button, the following message can be seen in the web
application. See Figure 108 and Figure 109
Figure 108: Retrieving the Instructions Resource
Validation
90
Figure 109: Validation of a confirmable GET request
Finally, the DELETE request in the WEB application server will remove the resource from the
CoAP server in the M2M gateway as verifies the Wireshark in the Figure 110
Figure 110: Validation of a DELETE request
In the next subsection, there will be performed a small verification of this first proof of concept
within a vehicle.
5.2 TESTS ON A REAL VEHICLE
In order to verify the continuous connectivity of the system and do a preliminary validation of the
prototype under real-life conditions, a test was conducted within a real vehicle enabled with the
already introduced and implemented prototype. Therefore, a vehicle was driven by myself (see
Figure 111) following the premediated route of the Figure 111
Please note that the M2M gateway (both raspberry and tactile screen) were plugged into a DC
source of power. A high capacity power-bank able to provide up to 2.4A via USB ports
A System for Vehicle Sensor Data Acquisition Based on CoAP
91
Figure 111: M2M Gateway on the vehicle before starting to drive
Figure 112: Planned route for the real validation
A few results measured in real time around the B-point are shown in the Figure 113
Validation
92
Figure 113: Real GPS data obtained from the vehicle in real time 48
From the above figure of results, it is clear to note that the GPS data update rate in the server is
not actually fixed and some data might get discarded at any system endpoint, for which the data
transmission is not ordered and unreliable. It means that there is no concept of
acknowledgement (use of UDP) and messages can reach too late and thus, the application layer
(CoAP) is the unique responsible of performing retransmission and message duplication, if
needed with every single packet that reaches the server (CoAP client) and the gateway (CoAP
server). However, besides the GPS data is not critical information to receive in the server, it
does not matter if some data cannot be processed as Figure 114 and Figure 115 validate the proof
of concept representing the vehicle speed and its horizontal dilution of precision using the tool
My Maps [62] of Google.
48 The total amount of cached samples was 168 during 25 min and 51 seconds of driving test.
So, it indicates an average of almost 7 samples per minute.
Figure 114: Latitude and longitude projection over Google Maps showing
ground speed in km/h
A System for Vehicle Sensor Data Acquisition Based on CoAP
93
Additionally, it is important to remark that there were some kind of dead-points during the real
driving. So that, neither signal reached the GPRS modem nor UDP packets arrived either on-time
at the M2M gateway or the server as it could be perceived in the Figure 116
Figure 116: Dead point
Figure 115: Latitude and longitude projection over Google Maps showing horizontal dilution of precision
Conclusion and future lines
94
Chapter 6 Conclusions and future lines
This chapter includes a final overall assessment about this thesis in terms of conclusions to
summarise the achievements related to the introduced objectives and the most significant
improvements to be conducted after the detailed implementation and validation results.
6.1 CONCLUSIONS
This master’s thesis has presented the design and implementation of a real proof of concept for a
feasible, reliable and real-time Machine-To-Machine communication, which also removes
some limitations and considers other several improvements from an earlier M2M deployment.
Furthermore, it also includes how the Global Positioning System data were successfully retrieved
and processed on the deployed server, as well as the identification mechanism for which every
driver and vehicle were identified and authenticated through a basic security implementation.
Therefore, the validation results included in this work, prove that the main and initial objective
has been satisfactorily fulfilled.
The deployed architecture satisfies the simplest ETSI M2M structural design with its well-defined
main blocks as M2M Gateway/device, communication access network and M2M server.
Moreover, it also considers the well-known RESTful network topology through the lightweight
M2M protocol CoAP standardized by the IETF, between the Gateway, which acts as CoAP
server and the Server, which performs as a CoAP client in the background for resource
management purposes between these two endpoints.
The GPS data management process was also successfully achieved as the acquisition and
validation stages on the M2M Gateway have followed strict methods listed in the National
Marine Electronics Association in order to posteriorly store these data and retransmitted them
back to the server upon the request/response model above described.
The development of two different ways of communication from the M2M server towards the
M2M gateway was performed using freeware and open-source code. Firstly, an automatic
gathering thread of GPS data (latitude, longitude, timestamp, precision) with some satellite
information was easily introduced into the system to consecutively, give way to a more complex
system which actually shares the CoAP client resources in order to, directly, send CoAP requests
to the M2M gateway upon user-demand via the web application developed for it and make use of
the designed proof-of-concept RESTful resource. This has been by far, the most difficult task to
be accomplished during the implementation stage due to the loads of issues between different
threads and secondary processes
A further and equally important consideration is the effectiveness of how the GPRS modem
was successfully deployed on the M2M gateway side due to its potential to receive and process
all the CoAP requests that reach from the M2M server upon an entire set of Python libraries
programmed on my own
As a final remark it should be clarified that, although the entire implementation is performed
using a high-level and object-oriented programming language as Python, almost the whole
activities implemented could be easily used as a main activity diagram to perform something
similar in any other programming languages.
A System for vehicle sensor data acquisition based on CoAP
95
6.2 FUTURE LINES
In order to make a more ambitious thesis, the main future line to be considered is the expansion
of the entire designed and implemented proof of concept into a real deployment project of a
fleet of vehicles. However, from a general system perspective and the two system endpoints, other
future lines are interesting are analysed and described below.
6.2.1 ADDITION OF OTHER VEHICLE SENSORS TO THE SYSTEM
As per the Raspberry Pi model 3 is a very powerful built-in Bluetooth and Wi-Fi connectivity
device and the main M2M communication paradigm is already implemented and validated, other
vehicle sensors can be utilised to acquire more data and send them back to the server.
Moreover, all vehicles produced nowadays are obliged, by law, to provide an interface for
connection of diagnostic test called On Board Diagnostic (OBD) [63] that continually monitors
the electronic sensors of engines and emissions control systems, usually refer as Engine Control
Units (ECU). Therefore, a simple and commercial low-cost Bluetooth device [64] can be used in
order to retrieve complementary information about several KPIs that permit generate a proper
driver profile, in terms of driving performance and also get Diagnostic Trouble Codes (DTC) that
allow rapidly identify and remedy malfunctions on the vehicle.
6.2.2 OBSERVING COAP RESOURCES
In order to save power and radio resources on the M2M gateway, CoAP also offers a simple
protocol extension that enables CoAP clients to observe resources [21], which is really similar to
the basis of MQTT that we introduced in the State of the Art (see above MQTT).
Basically, it consists on retrieve the resource representations of a CoAP server in such a way of
CoAP responses, each time its representation is updated. Thus, keeping these resources updated
on the M2M server (CoAP client) automatically after just sending only one CoAP Observe
request. Therefore, the M2M gateway would only need to process this first request and keep
updated the M2M server every time the resource representation changes.
For example, when the vehicle location changes (every few seconds), the M2M gateway/CoAP
server might keep sending CoAP responses with this updated resource information to the M2M
Server/CoAP client, without having to request for this information every time. Another
example might be delivering CoAP responses when the vehicle raises a specific threshold of
ground speed.
6.2.3 ENABLING SECURE COAP COMMUNICATIONS
In the actual implementation, the mechanism to provide some kind of security in the system is
very basic and only cyphers the first CoAP payload messages exchanged between the M2M
gateway and server. Therefore, it is highly recommended that future implementations include the
Datagram Transport Layer Security (DTLS) protocol to provide an extra of integrity,
authentication, privacy and confidentiality along the rest of CoAP message exchanged
between endpoints, as well as the use of DTLS is also proposed on the CoAP RFC [21] as
primary security protocol.
6.2.4 OTHER IMPROVEMENTS
There are other minor things on the system that could be reviewed in order to increase the
functionality, stability and usability of the system.
Conclusion and future lines
96
The use of a round-robin (RR) algorithm for infinite files on the M2M server when it
receives loads of data.
Design and integrate a Data Base into the M2M server to keep a proper record of the whole
company drivers with other relevant information according to when they have utilised the
vehicle or their traffic penalties.
Development of an improved and more aesthetic web user application to interact with the
M2M server
A System for vehicle sensor data acquisition based on CoAP
97
Appendix A – M2M Gateway and
device Technical specifications
RASPBERRY PI MODEL 3
These are the specs of a Raspberry Pi model 3 and a figure which shows its GPIO configuration
[43]
Figure 117: Raspberry Pi model 3 [43]
Processor: Broadcom BCM2837 64bit ARMv7 Quad Core Processor powered Single Board
computer running at 1.2 GHz RAM: l GB Wireless chipset: BCM43143 Wi-Fi “n” and
Bluetooth “LE” on board. 40pin extended as GPIO (see Figure 118) 4 x USB ports 2.0, 4 pole
Stereo output and Composite video port. Full size HDMI. CSI camera port for connecting the
Raspberry Pi camera. DSI display port for connecting the Raspberry Pi touch screen display.
Micro SD slot for loading operating system and storing data. Micro USB power source (supports
up to 2.4 Amps)
Figure 118: Raspberry Pi model 3 GPIO layout
M2M Gateway and device technical specifications
98
USB-GPS DEVICE ND-105C
Below are the most relevant characteristics of this GPS USB device which aims at generating the
GPS raw data
Table 7: USB GPS Technical specs
General specifications
GPS Chipset MediaTek MT3337
Frequency L1, 1575.42 MHz
Datum WGS-84
Max. Acquisition Channels 66 Satellites
Max. Tracking Channels 22 Satellites
C/A code 1.023 MHz chip rate
Tracking Sensitivity -165 dBm
Acquisition Sensitivity -148 dBm
Accuracy
Position Horizontal <2m 2D RMS with WAAS Enable
Velocity 0.01 m/s
Heading <0.01 degrees
Acquisition rate
Hot start 1s Average
Cold Start 35s Average
Reacquisition 0.1s Average
Protocol
GPS protocol NMEA 0183 v4
Electrical compliance NMEA 0183 V2 onwards
GPS Output Data GP - (GGA + GSA + GSV + RMC)
NMEA update rate 1 Hz
Power
Voltage 4.5 – 5.5 V
Current 40 mA typical
Dynamic Condition and Physical Characterization
Acceleration limit <4g
Altitude limit 18000 meters
Velocity limit 515 m/s
Connection interface Micro-USB
A System for vehicle sensor data acquisition based on CoAP
99
GPRS MODEM SIM800L
Frequency bands:
GSM850 (TX: 824 to 849MHz) TX Power: Class 4 (2W) and (Rx: 869 to 894MHz)
EGSM900 (TX: 880 to 915MHz) TX Power: Class 4 (2W) and (Rx: 925 to 960MHz)
DCS1800 (TX: 1710 to 1785MHz) TX Power: Class 1 (1W) and (Rx: 1805 to 1880MHz)
PCS1900 (TX: 1850 to 1910MHz) TX Power: Class 1 (1W) and (Rx: 1930 to 1990MHz)
Table 8: Downlink and uplink throughputs for the Coding Schemes
Coding scheme
1 Timeslot 2 timeslots 4 timeslots
CS-1 9.05 Kbps 18.1 Kbps 36.2 Kbps
CS-2 13.4 Kbps 26.8 Kbps 53.6 Kbps
CS-3 15.6 Kbps 31.2 Kbps 62.4 Kbps
CS-4 21.4 Kbps 42.8 Kbps 85.6 Kbps
Power supply
GSM Antenna UART
interface
SIM
Figure 120: SIM800L featured by SIMCOM
Figure 119: PIN assignment for SIM800 EVB V2
M2M Gateway and device technical specifications
100
Figure 121: Functional diagram of a SIM800L
The Table 9 shows the main features of a SIM800L
Table 9: SIM800L main features
Module information
Flash memory 16 Mbit
RAM 32 Mbit
Power supply 3.4 ~4.4V
Operating Temperature -40°C ~ +85°C
Size 17.8*15.8*2.4mm
Weight 1.35g
Firmware version SIM800L_20151222
GPRS, radio and data features
Max DL Transfer 85.6 Kbps
Max UL Transfer 85.6 Kbps
Coding-Scheme CS-1, CS-2, CS-3, CS-4
Integrated TCP/IP stack
PAP protocol for PPP connections
Support Packet Broadcast Control Channel
SMS support (MT, MO, CB) and storage via SIM card
SIM interface: 1.8V and 3.3V
Supports Real Time Clock
Serial Port
Baud rate From 1200 to 460800 bps
AT commands and data stream support
Hardware and Software control flow (RTS/CTS)
Upgrading firmware
Auto-baud rate supports until 115200 bps
A System for vehicle sensor data acquisition based on CoAP
101
Appendix B – CoAP Server Python Class diagram
CoAP
SIM800: SIM800()
client_address: tuple
firstCoAPpacket: Response()
resourceLayer: ResourceLayer()
CoAP_Server
GPS_dev_app: Process()
init_device_app()
run_device_app()
exit_device_app()
init_resources()
_messageLayer: MessageLayer()
_blockLayer: BlockLayer()
_requestLayer: RequestLayer()
serialize = Serialize()
purge: Thread()
stopped: Threading.Event()
root: Tree()
processing_requests
M2M_Authentication()
close_server()
add_resource()
notify()
purge()
receive_request()
send_datagram()
listen()
Process
authkey
daemon
daemon : bool exitcode
ident
name
pid
is_alive()
join()
run()
start()
terminate()
BlockLayer
error()
incomplete()
receive_empty()
receive_request()
receive_response()
send_request()
send_response()
MessageLayer
purge()
receive_empty()
receive_request()
receive_response()
send_empty()
send_request()
send_response()
RequestLayer
receive_request()
send_request()
ResourceLayer
add_resource()
corelinkformat()
create_resource()
delete_resource()
discover()
edit_resource()
get_resource()
update_resource()
valid()
Serialize
as_sorted_list()
convert_to_raw()
deserialize()
get_option_nibbl()
int_to_words()
is_request()
is_response()
read_option_value_from_nibble(
)
serialize()
Thread
daemon
daemon : bool exitcode
ident
name
is_alive()
join()
run()
start()
terminate()
_Event
daemon
daemon:bool
indent
is_alive
name
clear()
isSet()
set()
wait()
Tree
dump()
with_prefix()
with_prefix_resource()
tree: dict
Response
code
content_type : int
destination : None
location_path : str
location_query: str
max_age: int
mid : int
payload : str
source : tuple
timestamp : int
token : str
version : int
SIM800
attach_to_GPRS()
check_UDP_extended_mode()
check_serial_in_application()
close_SIM800L()
read_UDP_buffer()
send_UDP_packet()
set_IP_M2M_Server()
IP_Bearer : Str
apnName: Str
apnPass: Str
apnUser: Str
free : bool
read_Buffer: Thread()
stopped : bool
write_Buffer : Process ()
Message
acknowledged: bool
block1 : bool
block2 : bool
code: int
content_type
destination : Tuple
Type: int
duplicated : bool
line_print mid
mid : int
options: option()
payload
source : tuple
timeouted : bool
timestamp : str
token : int
type : int
version: int
CLASS LEGEND : Class developed on my own Class developed with CoAPthon Libraries CoAPthon libraries Multiprocessor/Threading Python libraries
References
102
Appendix C – Budget
This appendix presents an estimation of the costs for the first prototype developed of this master’s
thesis.
Hardware costs for M2M Gateway/device and Communication network
The Table 10 details and shows the costs of hardware for the M2M Gateway/device and
communication network.
Table 10: Hardware costs 49
Description Units Unit price
(£/unit) Cost (£)
Raspberry Pi model 3 1 30 30
Tactile screen 10” with frame 1 55 55
GPS mini-USB device 1 15 15
Modem GPRS SIM800L EVB 1 12 12
Proto-board, wires for interconnection and
Velcro 6 10 10
USB extensor 1 2 2
GSM antenna 1 2 2
Micro-SIM50 1 0 0
Total (£) 126
Mobile data SIM plan consumption forecast
For the purpose of this project, there was considered one driver who worked 7:30 hours per
working day from Monday to Friday and 22 working-days a month.
Moreover, the application performed automatic-data request from the M2M server to the gateway
in such a way as it was validated in the project (see Figure 113) with 7 requests plus 7 responses
per minute as average. Moreover, with an average packet size of 300 bytes per CoAP response
and 60 bytes per request and performing some quick calculations; 6300 CoAP messages would
be exchanged in ideal conditions. However, as we already know that UDP is a non-ordered and
non-reliable protocol, we should increase that number in such an estimated percentage of error
rate of 5%51, because of possible retransmission of packets conducted by either the CoAP client
or server. Finally, an estimated number of both 6615 requests and responses would be exchanged
between the M2M Server and Gateway. So that, the total estimated mobile data consumed in a
daily basis would be 969 KB in terms of responses and 194 KB for requests. The Table 11: CoAP
message total size exchanged via GPRS mobile network on the M2M gateway. The Table 11
shows these data consumptions.
Table 11: CoAP message total size exchanged via GPRS mobile network on the M2M gateway
CoAP requests
(daily number)
CoAP responses
(daily number)
CoAP request
size (KB daily)
CoAP response
(Kb daily)
Total CoAP
packets size in a
daily basis (KB)
Monthly data
consume
(MB)
3708 3708 194 969 840 22,7
49 Please, consider that the reference prices were taken in Sterling Pounds as the project was
developed in the UK 50 The used micro-SIM does not have not any upfront cost in any MVNO across the UK 51 This percentage is estimated as per the results obtained in the Validation chapter and includes
messages duplicated or unordered
A System for vehicle sensor data acquisition based on CoAP
103
Currently, the rate per MB in the UK for the GiffGaff [65] MVNO is £0.01/MB. Therefore, the
estimated and monthly rate would be less than £0.25 monthly.
This concludes that the proposed solution does have a very affordable cost in terms of network
usage and also that the performed tests did not incur in any remarkable expenses.
Software costs
All technology used to deploy this first proof-of-concept was open-source code and freeware,
however the server was deployed on a Windows machine and the report was written using
Microsoft Office. As the Table 12 shows
Table 12: Software costs
Description Units Unit price (£/unit) Cost (£)
Microsoft Windows 10 Professional
64bits
1 99 99
Microsoft Office 365 1 39 39
Labour costs
For this purpose, the work of a junior telecommunication engineer was considered on each task
presented in a supposed work planning, for a total of 120 working-days and 7:30 per day.
Moreover, a senior telecommunication engineer provided support in other several tasks spending
2 hours per week during 120 working-days as well, whilst a supervisor spent 2 hours per week
during 60 working-days.
Table 13: Labour costs
Profile Units (hour) Unit price (£/hour) Cost (£)
Junior Engineer – Marcos Soutullo 900 20 18,000
Senior Engineer – Neil French 48 35 1,680
Supervisor– Iván Vidal 24 50 1,200
TOTAL (£) 20,880
Indirect costs
This costs might include travel expenses, technical assistance, offices supplies, trainings and other
costs related to the project. Hence, a 10% over the labour costs was considered £ 2,088
Total costs
Finally, the total costs of development this first proof of concept is summarised in the table below:
Cost concept Costs (£)
Hardware deployment 126
Software 138
Labour 20,880
Indirect 2,088
TOTAL (£) 23,232
References
104
REFERENCES
[1] C. Antón-Haro, “Introduction to machine-to-machine (M2M) communications,” in
Machine-to-Machine (M2M) Communications, Amsterdam, Elsevier, 2015, pp. 15 - 20.
[2] S. M. a. T. Nigg, “The fast-growing M2M market presents a series of wireless design
challenges,” Embedded computing design, pp. 1-4, 15 June 2015.
[3] Infonetics Research, “M2M connections and services by vertical annual market size and
forecasts,” Infonetics Research, 2013.
[4] Infonetics Research, “Connected car M2M connections and services,” Infonetics
Research, 2014.
[5] D. Boswarthick, O. Elloumi and O. Hersent, “Introduction to M2M,” in M2M
Communications. A system approach, Chichester, UK, John Wiley & Sons, 2012, pp. 1-
19.
[6] ETSI, “TR 102 725, M2M definitions,” ETSI, Sophia Antipolis Cedex, 2013.
[7] I. B. a. M. K. V. Galetic, “Basic principles of Machine-to-Machine communication and
its impact on telecommunications industry,” in Proceedings of the 34th International
Convention, MIPRO, 2011.
[8] Machina Research, “Spectrum Demand for M2M Applications,” Egis Systems Limited,
London, 2014.
[9] O. Elloumi and F. Scholler, “M2M Requirements and High-Level Architectural
Principles,” in Machine-To-Machine Communications - A System Approach, Velizy,
John Wiley & Sons Ltd, 2012, pp. 57 - 94.
[10] IEEE, “Develop Standards,” 2006. [Online]. Available:
https://standards.ieee.org/develop/overview.html. [Accessed 22 06 2016].
[11] ETSI, ETSI completes foundation standards package for M2M services, Sophia
Antipolis: ETSI press, 2012.
[12] ETSI, “Machine-to-Machine communications (M2M); M2M Service requirements,”
ETSI, Sophia Antipolis Cedex, 2013.
[13] ETSI, “TS 102 690 Machine-to-Machine communications (M2M); Functional
architecture,” ETSI, Sophia Antipolis Cedex, 2013.
[14] ETSI, “M2m Interface descriptions in ETSI TS 102 921,” ETSI, Sophia Antipolis
Cedex, 2012.
[15] J. Höller, V. Tsiatsis and C. Mulligan, “IoT Architecture - State of the Art,” in From
Machine-To-Machine to the Internet of Things, Amsterdam, Elsevier, 2014, pp. 145 -
163.
[16] O. Elloumi and C. Forlivesi, “ETSI M2M Service Architecture,” in M2M
Communications: A Systems Approach, Antwerp, John Wiley & Sons, 2012, pp. 95 -
140.
A System for vehicle sensor data acquisition based on CoAP
105
[17] R. T. Fielding, “Architectural Styles and the Design of Network-based Software
Architectures,” University of California, Irvine, 2000.
[18] D. Guinard, V. Trifa and E. Wilde, “A resource oriented architecture for the Web of
Things,” in Internet of Things (IOT), Tokyo, 2010.
[19] H. Alvestrand, A Mission Statement for the IETF, Trondheim: IETF, 2004.
[20] A. K. a. C. Bormann, “Internet of Things: Standards and Guidance from the IETF,”
IETF Journal April, vol. 11, no. 3, pp. 20 - 21, 2016.
[21] C. Bormann, “ Block-Wise Transfers in the Constrained Application Protocol (CoAP)
RFC-7959,” IETF, Bremen, 2016.
[22] K. H. a. C. B. Z. Shelby, The Constrained Application Protocol (CoAP) (RFC 7252),
Bremen: IETF, 2014.
[23] C. Bormann, M. Ersue and A. Keranen, RFC 7228 - Terminology for Constrained-Node
Networks (Informational), Bremen: IETF, 2014.
[24] N. Freed and N. Borenstein, “Multipurpose Internet Mail Extensions RFC-2046,” IETF,
Dallas, 1996.
[25] M. Becker, L. K. and P. T., Transport of CoAP over SMS - draft-becker-core-coap-sms-
gprs-05, Bremen: IETF-CoRE, 2015.
[26] Z. Shelby, “Constrained RESTful Environments (CoRE) Link Format RFC-6690,”
IETF, Vuokatti, 2012.
[27] K. Hatke, “Observing Resources in the Constrained Application Protocol (CoAP),”
IETF, Bremen, 2015.
[28] M. Kovatsch and K. Hudalla, “Californium,” Eclipse, 2012. [Online]. Available:
https://www.eclipse.org/californium. [Accessed 30 08 2016].
[29] Z. Hamed, “Canopus,” Github, 2014. [Online]. Available:
https://github.com/zubairhamed/canopus. [Accessed 30 08 2016].
[30] Exilant Technologies, “CoAPsharp,” EXILANT Tehcnologies, 2013. [Online].
Available: http://www.coapsharp.com/. [Accessed 30 08 2016].
[31] G. Tanganelli, “CoAPthon,” 2014. [Online]. Available:
https://github.com/Tanganelli/CoAPthon. [Accessed 30 08 2016].
[32] M. Kovatsch, “Copper,” 2014. [Online]. Available: https://github.com/mkovatsc/Copper.
[Accessed 30 08 2016].
[33] K. Cullen, “FreeCoAP,” 2015. [Online]. Available: https://github.com/keith-
cullen/FreeCoAP. [Accessed 30 08 2016].
[34] G. Tanganelli, C. Vallati and E. Mingozzi, “CoAPthon: Easy Development of CoAP-
based IoT Applications with Python,” in IEEE 2nd World Forum on Internet of Things,
Milan, 2015.
[35] M. H. Elgazzar, “Perspectives on M2M protocols,” in IEEE Seventh International
Conference on Intelligent Computing and Information systems, 2015.
[36] MQTT, “MQTT,” 2014. [Online]. Available:
https://github.com/mqtt/mqtt.github.io/wiki. [Accessed 25 08 2016].
References
106
[37] XMPP developers, “XMPP,” 2013. [Online]. Available:
https://xmpp.org/about/technology-overview.html. [Accessed 25 08 2016].
[38] J. Höller, V. Tsiatsis and S. Avesand, “Data management,” in From M2M to IoT,
Oxford, El Sevier, 2014, pp. 106 - 111.
[39] G. Wu, S. Talwar and J. Kerstin, “M2M: From Mobile to Embedded Internet,” IEEE
Communications Magazine, vol. 49, no. 4, pp. 36 - 43, 2011.
[40] National Marine Electronics Association, “NMEA,” NMEA, 2008. [Online]. Available:
http://www.nmea.org/content/about_the_nmea/about_the_nmea.asp. [Accessed 03 08
2016].
[41] National Marine Electronics Association, “NMEA,” NMEA, 2008. [Online]. Available:
http://www.nmea.org/content/nmea_standards/nmea_0183_v_410.asp. [Accessed 03 08
2016].
[42] National Marine Electronics Association , “Standard For Interfacing Marine Electronic
Devices V. 3.01,” NMEA, Severna Park, MD 21146 USA, 2002.
[43] Raspberry Pi foundation, “Raspberrypi,” 2015. [Online]. Available:
https://www.raspberrypi.org/products/raspberry-pi-3-model-b/. [Accessed 10 09 2016].
[44] SIMcom, “SIM800 Hardware design,” SIMCOM, Shanghai, 2015.
[45] Python community, “About Ptython,” Python, 2010. [Online]. Available:
https://www.python.org/about/. [Accessed 05 09 2016].
[46] C. Liechti, “Pyserial,” Python, 2015. [Online]. Available:
http://pythonhosted.org/pyserial/pyserial.html#overview. [Accessed 15 08 2016].
[47] T. Flanagan, “pynmea2,” 2016. [Online]. Available: https://github.com/Knio/pynmea2.
[Accessed 05 09 2016].
[48] Python, “JSON Encoder and decoder,” Python, 2012. [Online]. Available:
https://docs.python.org/2/library/json.html. [Accessed 05 09 2016].
[49] D. Litzenberger, “Python packages,” [Online]. Available:
https://pypi.python.org/pypi/pycrypto. [Accessed 05 10 2016].
[50] Python, “Python,” [Online]. Available: https://docs.python.org/2/library/threading.html.
[Accessed 07 09 2016].
[51] Python, “Pthon documentation,” Python, 2015. [Online]. Available:
https://docs.python.org/2/library/queue.html. [Accessed 06 09 2016].
[52] SIMcom, “SIM800 Series_AT Command Manual V1.09,” SIMcom, Shanghai, 2015.
[53] SIMCom, “SIM800 Serial Serial Port Application Note,” SIMCom, Shanghai , 2014.
[54] SIMCom, “SIM800 Series IP Application Note,” SIMCom, Shanghai, 2015.
[55] B. Croston, “Sourceforge,” [Online]. Available: https://sourceforge.net/p/raspberry-gpio-
python/wiki/BasicUsage/. [Accessed 06 09 2016].
[56] D. Lasley, “Stackoverflow,” 2012 09 21. [Online]. Available:
http://stackoverflow.com/questions/12524994/encrypt-decrypt-using-pycrypto-aes-256.
[Accessed 07 09 2016].
[57] R. P. a. R. Adams, “The ESP CBC-Mode Cipher Algorithms - RFC 2451,” IETF, 1998.
A System for vehicle sensor data acquisition based on CoAP
107
[58] K. Reitz, “Tablib: Pythonic tabulat datasets,” 2016. [Online]. Available:
http://docs.python-tablib.org/en/latest/. [Accessed 09 09 2016].
[59] CherryPy Team, “Cherrypy,” 12 December 2015. [Online]. Available:
http://docs.cherrypy.org/en/latest/intro.html. [Accessed 22 08 2016].
[60] Michael Bayer, “Mako,” 2016. [Online]. Available: http://www.makotemplates.org/.
[Accessed 09 09 2016].
[61] J. Lahtinen, “Linux man,” Linux, [Online]. Available:
http://linux.die.net/man/1/minicom. [Accessed 06 09 2016].
[62] Google, “My maps,” Google, 2015. [Online]. Available:
https://www.google.co.uk/maps/about/mymaps/. [Accessed 14 09 2016].
[63] Technology, NAPA Institute of Automotive, “Introduction to OBD-II,” in OBD II and
Second generation tools, New York, NAPA, 1996, pp. 9 - 28.
[64] ELM Electronics, “ELM327 OBD to RS232 Interpreter,” ELM, 2015.
[65] GiffGaff, “GiffGaff,” 15 09 2016. [Online]. Available: https://www.giffgaff.com/.
[Accessed 2016].
[66] S. Babar, N. Prasad and R. Nielsen, “Multi-disciplinary Applications Rrequiring
Advance IoT and M2M,” in Role of ICT for Multi-Disciplinary Applications in 2030,
Conasense, River publisher, 2016, pp. 23-58.
[67] D. Boyle, S. Avesand, S. Karnouskos, J. Ho and V. Tsiatsis, “M2M to IoT - The
Vision,” in From Machine-to-Machine to the Internet of Things, London, Elsevier Ltd,
2014, pp. 9 - 37.
[68] J. Höller, V. Tsiatsis and C. Mulligan, “M2M and IoT Technology fundamentals,” in
From Machine-to-Machine to the Internet of Things, London, Elsevier, 2014, pp. 81 -
143.
[69] “Federal Administration Aviation,” U.S. Department of Transportation, 2016. [Online].
Available:
http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/nav
services/gnss/faq/waas/. [Accessed 15 08 2016].
[70] J. R., “Stackoverflow,” [Online]. Available:
http://stackoverflow.com/questions/25011078/what-does-pythonic-mean. [Accessed 09
09 2016].
[71] JetBrains, “PyCharm,” JetBrains, [Online]. Available:
https://www.jetbrains.com/pycharm/. [Accessed 09 09 2016].
![A CoAP Publish-Subscribe Broker for More Resource ... · response to certain messages[7, p. 35] . The Constrained Application Protocol (CoAP) is specifically designed for resource](https://static.fdocuments.us/doc/165x107/5f0953437e708231d4264ae3/a-coap-publish-subscribe-broker-for-more-resource-response-to-certain-messages7.jpg)
![1st CoAP Plug test ; Paris, France ; 24 - 25 March 2012€¦ · [1] Constrained Application Protocol (CoAP); draft-ietf-core-coap-08 [2] CoRE Link Format; draft-ietf-core-link-format-11](https://static.fdocuments.us/doc/165x107/5f093f497e708231d425ecba/1st-coap-plug-test-paris-france-24-25-march-2012-1-constrained-application.jpg)
