U

Use Case 15

Use Case 15

Use case 15 - V-16 Conection support (Protocol A)

1. Objective

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.

2. Precedents

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.

Scope Field Length Description
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
Minor, number
Quality Battery 2 Number Volts*10.
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
Altitud 4 Meters, number
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.

  1. 125001100171060101yFjRSR5I01100123456789ABCDEF12345678001000100010ABCCBAXXXXXN40.509784W003.743978202209020844180100020500001
  2. 125001201571060101yFjRSR5I01100123456789ABCDEF12345678001000100010ABCCBAXXXXXN40.509784W003.743978202209020844190100020500001