Use Case 15
Use Case 15
Use case 15 - V-16 Conection support (Protocol A)
This document is prepared with the aim of serving as a guide for the development of the functionalities required as a backup service in the case of connections of V-16 devices using Protocol A described in the Resolution of November 30, 2021, of the Dirección General de Tráfico, which defines the protocol and format for sending data from the V-16 signal to the National Access Point, within the scope of Directive 2010/40/EU of the European Parliament and of the Council, of July 7, 2010, which establishes the framework for the implementation of intelligent transport systems in the road transport sector.
On May 23, 2022, the MOV 3/2022 Directive Document has been published: Process for the certification of V16 signals connected to DGT 3.0. [https://www.dgt.es/muevete-con-seguridad/conoce-las-normas-de-trafico/todas-las-normas/] As a complement to it, a guide is published with the length of the fields to be those referred to in said regulations and in the Resolution of November 30, 2021, of the Dirección General de Tráfico, which defines the protocol and format for sending data from the V-16 signal to the Point of National Access, within the scope of Directive 2010/40/EU of the European Parliament and of the Council, of July 7, 2010, which establishes the framework for the implementation of intelligent transport systems in the road transport sector.
3. Data Model
As indicated in the reference documentation, it is necessary to have, in addition to a standard channel (protocol A), a standardized language that allows interoperability between the different manufacturers. This is achieved by standardizing the data model that devices are required to send to the operator and then route it to the manufacturer's cloud.
Next, the set of required attributes is described, with the fixed length of each one of them.
|message||Length||3||Actual datagram length|
|Datagram version||3||Version of the datagram|
|Datagram type||1||Datagram type: 0=Battery report, 1=Incidence, 2 =Incidence End|
|Sequence||3||Sequence number incremented by the datagram. It is restored in each incidence|
|Device||Manufacturer ID||4||Manufacturer ID provided by DGT3.0|
|SW Version||2||Version of the used software|
|HW version||2||Version of the used hardware|
|Device ID||8||Major, number|
|Activation time||3||Time awake since the button is pressed (minutes)|
|IMEI||15||ASCII character string. IMEI="000000000000000"|
|Cell + ECL||8||Cell ID 30bit (Only 28 are used) + ECL|
|RSSI||4||Received signal strength level|
|RSRP||4||Reference signal received power|
|RSRQ||4||Reference signal received quality|
|PLMN||6||PLMN (Public Land Mobile Network) 5 to 6 digits ASCII string (MCC MNC)|
|Secondary||5||Secondary field reserved for future use|
|Location||NS||1||N (North) o S (South) (1 char)|
|DD.DDDDDD||9||Latitude Degrees (DD.DDDDDD)|
|EW||1||E (East) o W (West) (1 char)|
|DDD.DDDDDD||10||Longitude Degrees (DDD.DDDDDD)|
|YYYYMMDDHHMISS||14||UTC GPS TIMESTAMP|
|EPE_horiz||2||Horizontal Position Error (metros), number|
|Satellites||2||Number of satellites used|
|HDOP||5||Horizontal Dilution Of Precision * 100, number|
The attributes related to message, device and quality will be given in text format and those of location in text. Hardware manufacturers have been consulted and it has been found that this is the most efficient solution from the point of view of the chip that manages the device.
Here are two sample datagrams that follow the above format. The first datagram corresponds to the start of an incident, the second to its end after several messages.