JT/T 808-2019/XG1-2021 GNSS system for operational vehicles—General specifications for vehicle terminal communication protocol and data format,includes Amendment 1 (English Version)
Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
This standard is developed in accordance with the rules given in G/T 1.1-2009.
This standard replaces JT/T 808-2011 GNSS system for operational vehicles - General specifications for vehicle terminal communication protocol and data format. In addition to a number of editorial changes, the following main technical changes have been made with respect to JT/T 808-2011:
——The 14th bit of the message body attribute format of message header is modified to "version identity" (see 4.4.3; 4.4.3 of Edition 2011);
——The terminal phone number length in the message header is modified (see 4.4.3; 4.4.3 of Edition 2011);
——The server time query request is added (see 8.4);
——The additional points report request for terminal subpacket is added (see 8.7);
——The terminal model, terminal ID length and license plate format description of the register message are modified (see 8.8; 8.4 of Edition 2011);
——The manufacturer ID length and format definition of terminal register message as well as the reference standard for license plate color are modified (see 8.8; 8.8 of Edition 2011);
——The format of terminal authentication message is modified, and the software version number and IMEI number fields are added (see 8.11; 8.11 of Edition 2011);
——The definition of license plate color in terminal parameters setting is modified (see 8.12; 8.12 of Edition 2011);
——The parameter content of terminal parameters setting is modified (see 8.12; 8.12 of Edition 2011);
——The instruction of “specified terminal parameters query” is added (see 8.14);
——The instruction of “terminal attribute query” is added (see 8.16);
——The parameter description of controlling the terminal to connect to the designated server in the terminal control instruction is modified. Three control instructions, i.e., "terminal shutdown", “close data communication" and "close all wireless communication", are deleted. The data type description of wireless upgrade command removal command parameter is deleted, and the specific command parameter type is subject to the parameter type of the corresponding command word (see 8.16; 8.16 of Edition 2011);
——The requirements on event setting, event report, question issuing, question answering, information on-demand menu setting, information on-demand/cancellation and information service in the data format are deleted (see 8.17, 8.18, 8.19, 8.20, 8.21, 8.22 and 8.23 of Edition 2011);
——The instruction of “terminal upgrade patch issuing” is added (see 8.19);
——The requirements for the message of location information reporting are modified (see 8.21; 8.21 of Edition 2011);
——The instruction of “artificial acknowledgment alarm” is added (see 8.25);
——The instruction of “terminal link detection” is added (see 8.26);
——The requirements for text information issuance are modified (see 8.27; 8.27 of Edition 2011);
——The data format of vehicle control instruction is modified (see 8.30; 8.12 of Edition 2011);
——Definitions such as opening and closing door for the area attribute of circular area establishment instruction are added (see 8.32);
——The name fields for rectangular area establishment, circular area establishment, polygonal area establishment, route establishment, etc. are added (see 8.32~8.38);
——The message bodies “area or route data query response” are added (see 8.40);
——The field definition of data block for driving record data acquisition command is added (see 8.42);
——The request for reporting driver's identity information is added (see 8.46);
——The structure of driver's identity information acquisition and reporting message is modified (see 8.47; 8.47 of Edition 2011);
——The request for batch uploading of locating data is added (see 8.48);
——The request for CAN bus data uploading is added (see 8.49);
——The location information field for multimedia data uploading is added (see 8.51);
——The definitions of minimum resolution and maximum resolution of the command of immediate shooting for camera are added (see 8.53);
——The response to command of immediate shooting for camera is added (see 8.54);
——The data format of multimedia retrieval item for stored multimedia data retrieval response is added (see 8.56);
——The instruction for single stored multimedia data retrieval and uploading is added (see 8.59);
——The transparent transmission message type definition table of the transparent transmission message type description is added in the downlink data transparent transmission instruction (see 8.60);
——The transparent transmission message type description of the uplink data transparent transmission instruction is modified (see 8.61; 8.61 of Edition 2011);
——The peripheral type number table is modified, and the peripheral type of burglar alarm is added (see Table A.2);
——The command type table is modified, and the content of special protocol related to road transport certificate IC card and the content of peripheral self-test and firmware update are added (see Table A.3);
——The slave version number information query instruction is added (see A3.4);
——The slave self-test instruction is added (see A3.5);
——The slave firmware update instruction is added (see A3.6);
——The instruction for peripheral attribute query is added (see A3.7);
——The description of special protocol for IC card authentication is added (see A.4);
——The table for message comparison is modified, all newly added instructions are supplemented, and the scope of vendor defined uplink message and vendor defined downlink message is specified (see Annex B).
This standard was proposed by and is under the jurisdiction of SAC/TC 521 National Technical Committee on Road Transport of Standardization Administration of China.
The previous edition of this standard is as follows:
——JT/T 808-2011.
GNSS for operating vehicles - General specifications for vehicle terminal communication protocol and data format
1 Scope
This standard specifies the communication protocol and data format between the on-board terminal of GNSS for operating vehicles and the supervision/monitoring platform, including protocol basis, communication connection, message processing, protocol classification and requirements, and data format.
This standard is applicable to the communication between the on-board terminal of GNSS for operating vehicles and the supervision/monitoring platform.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
GB/T 2260 Codes for the administrative divisions of the Peoples Republic of China
GB/T 19056 Vehicle travelling data recorder
JT/T 697.7-2014 Basic data element of transportation information - Part 7: Basic data element of road transportation information
JT/T 794 GNSS system for operating vehicles - Technical specification for vehicle terminals
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
abnormal data communication link
state in which the wireless communication link is disconnected or temporarily suspended (such as during a call)
3.1.2
register
operation that a terminal sends a message to the platform to inform its installation on a certain vehicle
3.1.3
unregister
operation that a terminal sends a message to the platform to inform its removal from the vehicle
3.1.4
authentication
operation that a terminal sends a message to the platform at the time of being connected to the platform to enable the platform to verify its identity and at the same time reports the protocol version currently in use to communicate with the platform
3.1.5
location reporting strategy
rules for reporting at regular time interval or certain distance or a combination of both
3.1.6
location reporting program
rules for determining location reporting interval according to location reporting strategy
3.1.7
additional points report while turning
rules for the terminal to send the location information reporting message when judging that the vehicle will turn. The sampling frequency shall not be less than 1Hz, and the change rate of vehicle azimuth angle shall not be less than 15°/s, and the sampling shall last at least more than 3s
3.1.8
answering strategy
rules for the terminal to answer incoming calls automatically or manually
3.1.9
sms text alarm
operation of sending text messages by SMS when the terminal alarms
3.1.10
multi-center connection strategy
the terminal shall report the same data content to multiple central servers at the same time. For the downlink instruction operation of central servers, the terminal shall only respond to the downlink instruction of the primary server, but not to the downlink instruction of the secondary server
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
ID——Identity
APN——Access Point Name
GZIP——a GNU free software file compression program (GNU zip)
LCD——Liquid Crystal Display
RSA——an asymmetric cryptography algorithm (developed by Ron Rivest, Adi Shamirh, and Len Adleman, named after them)
SMS——Short Message Service
TCP——Transmission Control Protocol
TTS——Text To Speech
UDP——User Datagram Protocol
VSS——Vehicle Speed Sensor
GNSS——Global Navigation Satellite System
GBK——Chinese Internal Code Specification
4 Protocol basis
4.1 Communication mode
The communication mode adopted in the protocol shall meet the relevant requirements in JT/T 794. The communication protocol adopts TCP or UDP, with the supervision/monitoring platform (hereinafter referred to as "platform") as the server side and the on-board terminal of GNSS for operating vehicles (hereinafter referred to as "terminal") as the client side. In case of an abnormal data communication link, the terminal may communicate via SMS message.
4.2 Data type
See Table 1 for data types used in protocol messages.
Table 1 Data types
Data type Description and requirement
BYTE Unsigned single-byte integer (byte, 8 bits)
WORD Unsigned double-byte integer (byte, 16 bits)
DWORD Unsigned four-byte integer (double word, 32 bits)
BYTE[n] n bytes
BCD[n] 8421 code, n bytes
STRING GBK code. Null if there is no data
4.3 Transmission rules
The protocol shall adopt the network byte order in big-endian mode to transmit word and double word. The transmission rules are agreed as follows:
——BYTE transmission, which is performed in the form of byte stream;
——WORD transmission, in which the high 8 bits are transmitted first, and then the low 8 bits are transmitted;
——DWORD transmission, in which the high 24 bits are transmitted first, then the high 16 bits, the high 8 bits, and finally the low 8 bits.
4.4 Message composition
4.4.1 Message structure
Each message consists of identity bits, a message header, a message body and a check code, and the message structure is shown in Figure 1.
Identity bit Message header Message body Check code Identity bit
Figure 1 Message structure diagram
4.4.2 Identity bit
The identity bit shall be represented by 0x7e, and if 0x7e and 0x7d appear in the check code, message header and message body, they shall be escaped. The escape rules are defined as follows:
Firstly, 0x7d is escaped and converted into fixed two-byte data: 0x7d 0x01;
Secondly, 0x7e is escaped and converted into fixed two-byte data: 0x7d 0x02.
The escape process is as follows:
When sending a message: first encapsulate the message, then calculate and fill in the check code, and finally escape it;
When receiving a message: firstly escape and restore the message, then verify the check code, and finally parse the message.
Example: When sending a data packet of 0x30 0x7e 0x08 0x7d 0x55, it is encapsulated as follows: 0x7e 0x30 0x7d 0x02 0x08 0x7d 0x01 0x55 0x7e.
4.4.3 Message header
4.4.3.1 See Table 2 for the content of message header.
4.4.3.2 The format structure of message body attribute is shown in Figure 2.
Table 2 Content of message header
Start byte Field Data type Description and requirement
0 Message ID WORD —
2 Message body attribute WORD The format structure of message body attribute is shown in Figure 2
4 Protocol version number BYTE Protocol version, which is incremented with each critical revision, with an initial version number of 1
5 Terminal phone number BCD[10] It is converted according to the phone number of the terminal installed. If the phone number is insufficient, the number 0 will be added before it
15 Message serial number WORD It is circularly accumulated from 0 in the sending order
17 Message packet encapsulation item — If the relevant identity bit in the message body attribute determines that the message is sub-packaged, then this item has content, otherwise this item does not exist
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Version identity Subpacket Data encryption mode Message body length
Note: The value of the version identity bit is fixed at 1.
Figure 2 Format structure diagram of message body attribute
4.4.3.3 Data shall be encrypted as follows:
——bit10~bit12 are data encryption identity bits;
——when all three bits are 0, it means that the message body is not encrypted;
——when the 10th bit is 1, it means that the message body is encrypted by RSA algorithm;
——other bits are reserved.
4.4.3.4 Message subpacket shall be processed according to the following requirements:
——when the 13th bit in the message body attribute is 1, it means that the message body is a long message and is subjected to subpacket transmission processing, and the specific subpacket information is determined by the message packet encapsulation item;
——if the 13th bit is 0, there is no message packet encapsulation item field in the message header.
See Table 3 for the content of message packet encapsulation item.
Foreword II
1 Scope
2 Normative references
3 Terms, definitions and abbreviations
4 Protocol basis
5 Communication connection
6 Message processing
7 Protocol classification and requirements
8 Data format
Annex A (Normative) Communication protocol between on-board terminal and external equipment
Annex B (Normative) Table for message comparison
JT/T 808-2019/XG1-2021 GNSS system for operational vehicles—General specifications for vehicle terminal communication protocol and data format,includes Amendment 1 (English Version)
Standard No.
JT/T 808-2019/XG1-2021
Status
valid
Language
English
File Format
PDF
Word Count
25000 words
Price(USD)
600.0
Implemented on
Delivery
via email in 1 business day
Detail of JT/T 808-2019/XG1-2021
Standard No.
JT/T 808-2019/XG1-2021
English Name
GNSS system for operational vehicles—General specifications for vehicle terminal communication protocol and data format,includes Amendment 1
JT/T 808-2019/XG1-2021, JT 808-2019/XG1-2021, JT 808-2019XG1-2021, JT/T808-2019/XG1-2021, JT/T 808, JT/T808, JT808-2019/XG1-2021, JT 808, JT808, JT808-2019XG1-2021, JT 808, JT808
Introduction of JT/T 808-2019/XG1-2021
Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
This standard is developed in accordance with the rules given in G/T 1.1-2009.
This standard replaces JT/T 808-2011 GNSS system for operational vehicles - General specifications for vehicle terminal communication protocol and data format. In addition to a number of editorial changes, the following main technical changes have been made with respect to JT/T 808-2011:
——The 14th bit of the message body attribute format of message header is modified to "version identity" (see 4.4.3; 4.4.3 of Edition 2011);
——The terminal phone number length in the message header is modified (see 4.4.3; 4.4.3 of Edition 2011);
——The server time query request is added (see 8.4);
——The additional points report request for terminal subpacket is added (see 8.7);
——The terminal model, terminal ID length and license plate format description of the register message are modified (see 8.8; 8.4 of Edition 2011);
——The manufacturer ID length and format definition of terminal register message as well as the reference standard for license plate color are modified (see 8.8; 8.8 of Edition 2011);
——The format of terminal authentication message is modified, and the software version number and IMEI number fields are added (see 8.11; 8.11 of Edition 2011);
——The definition of license plate color in terminal parameters setting is modified (see 8.12; 8.12 of Edition 2011);
——The parameter content of terminal parameters setting is modified (see 8.12; 8.12 of Edition 2011);
——The instruction of “specified terminal parameters query” is added (see 8.14);
——The instruction of “terminal attribute query” is added (see 8.16);
——The parameter description of controlling the terminal to connect to the designated server in the terminal control instruction is modified. Three control instructions, i.e., "terminal shutdown", “close data communication" and "close all wireless communication", are deleted. The data type description of wireless upgrade command removal command parameter is deleted, and the specific command parameter type is subject to the parameter type of the corresponding command word (see 8.16; 8.16 of Edition 2011);
——The requirements on event setting, event report, question issuing, question answering, information on-demand menu setting, information on-demand/cancellation and information service in the data format are deleted (see 8.17, 8.18, 8.19, 8.20, 8.21, 8.22 and 8.23 of Edition 2011);
——The instruction of “terminal upgrade patch issuing” is added (see 8.19);
——The requirements for the message of location information reporting are modified (see 8.21; 8.21 of Edition 2011);
——The instruction of “artificial acknowledgment alarm” is added (see 8.25);
——The instruction of “terminal link detection” is added (see 8.26);
——The requirements for text information issuance are modified (see 8.27; 8.27 of Edition 2011);
——The data format of vehicle control instruction is modified (see 8.30; 8.12 of Edition 2011);
——Definitions such as opening and closing door for the area attribute of circular area establishment instruction are added (see 8.32);
——The name fields for rectangular area establishment, circular area establishment, polygonal area establishment, route establishment, etc. are added (see 8.32~8.38);
——The message bodies “area or route data query response” are added (see 8.40);
——The field definition of data block for driving record data acquisition command is added (see 8.42);
——The request for reporting driver's identity information is added (see 8.46);
——The structure of driver's identity information acquisition and reporting message is modified (see 8.47; 8.47 of Edition 2011);
——The request for batch uploading of locating data is added (see 8.48);
——The request for CAN bus data uploading is added (see 8.49);
——The location information field for multimedia data uploading is added (see 8.51);
——The definitions of minimum resolution and maximum resolution of the command of immediate shooting for camera are added (see 8.53);
——The response to command of immediate shooting for camera is added (see 8.54);
——The data format of multimedia retrieval item for stored multimedia data retrieval response is added (see 8.56);
——The instruction for single stored multimedia data retrieval and uploading is added (see 8.59);
——The transparent transmission message type definition table of the transparent transmission message type description is added in the downlink data transparent transmission instruction (see 8.60);
——The transparent transmission message type description of the uplink data transparent transmission instruction is modified (see 8.61; 8.61 of Edition 2011);
——The peripheral type number table is modified, and the peripheral type of burglar alarm is added (see Table A.2);
——The command type table is modified, and the content of special protocol related to road transport certificate IC card and the content of peripheral self-test and firmware update are added (see Table A.3);
——The slave version number information query instruction is added (see A3.4);
——The slave self-test instruction is added (see A3.5);
——The slave firmware update instruction is added (see A3.6);
——The instruction for peripheral attribute query is added (see A3.7);
——The description of special protocol for IC card authentication is added (see A.4);
——The table for message comparison is modified, all newly added instructions are supplemented, and the scope of vendor defined uplink message and vendor defined downlink message is specified (see Annex B).
This standard was proposed by and is under the jurisdiction of SAC/TC 521 National Technical Committee on Road Transport of Standardization Administration of China.
The previous edition of this standard is as follows:
——JT/T 808-2011.
GNSS for operating vehicles - General specifications for vehicle terminal communication protocol and data format
1 Scope
This standard specifies the communication protocol and data format between the on-board terminal of GNSS for operating vehicles and the supervision/monitoring platform, including protocol basis, communication connection, message processing, protocol classification and requirements, and data format.
This standard is applicable to the communication between the on-board terminal of GNSS for operating vehicles and the supervision/monitoring platform.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
GB/T 2260 Codes for the administrative divisions of the Peoples Republic of China
GB/T 19056 Vehicle travelling data recorder
JT/T 697.7-2014 Basic data element of transportation information - Part 7: Basic data element of road transportation information
JT/T 794 GNSS system for operating vehicles - Technical specification for vehicle terminals
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
abnormal data communication link
state in which the wireless communication link is disconnected or temporarily suspended (such as during a call)
3.1.2
register
operation that a terminal sends a message to the platform to inform its installation on a certain vehicle
3.1.3
unregister
operation that a terminal sends a message to the platform to inform its removal from the vehicle
3.1.4
authentication
operation that a terminal sends a message to the platform at the time of being connected to the platform to enable the platform to verify its identity and at the same time reports the protocol version currently in use to communicate with the platform
3.1.5
location reporting strategy
rules for reporting at regular time interval or certain distance or a combination of both
3.1.6
location reporting program
rules for determining location reporting interval according to location reporting strategy
3.1.7
additional points report while turning
rules for the terminal to send the location information reporting message when judging that the vehicle will turn. The sampling frequency shall not be less than 1Hz, and the change rate of vehicle azimuth angle shall not be less than 15°/s, and the sampling shall last at least more than 3s
3.1.8
answering strategy
rules for the terminal to answer incoming calls automatically or manually
3.1.9
sms text alarm
operation of sending text messages by SMS when the terminal alarms
3.1.10
multi-center connection strategy
the terminal shall report the same data content to multiple central servers at the same time. For the downlink instruction operation of central servers, the terminal shall only respond to the downlink instruction of the primary server, but not to the downlink instruction of the secondary server
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
ID——Identity
APN——Access Point Name
GZIP——a GNU free software file compression program (GNU zip)
LCD——Liquid Crystal Display
RSA——an asymmetric cryptography algorithm (developed by Ron Rivest, Adi Shamirh, and Len Adleman, named after them)
SMS——Short Message Service
TCP——Transmission Control Protocol
TTS——Text To Speech
UDP——User Datagram Protocol
VSS——Vehicle Speed Sensor
GNSS——Global Navigation Satellite System
GBK——Chinese Internal Code Specification
4 Protocol basis
4.1 Communication mode
The communication mode adopted in the protocol shall meet the relevant requirements in JT/T 794. The communication protocol adopts TCP or UDP, with the supervision/monitoring platform (hereinafter referred to as "platform") as the server side and the on-board terminal of GNSS for operating vehicles (hereinafter referred to as "terminal") as the client side. In case of an abnormal data communication link, the terminal may communicate via SMS message.
4.2 Data type
See Table 1 for data types used in protocol messages.
Table 1 Data types
Data type Description and requirement
BYTE Unsigned single-byte integer (byte, 8 bits)
WORD Unsigned double-byte integer (byte, 16 bits)
DWORD Unsigned four-byte integer (double word, 32 bits)
BYTE[n] n bytes
BCD[n] 8421 code, n bytes
STRING GBK code. Null if there is no data
4.3 Transmission rules
The protocol shall adopt the network byte order in big-endian mode to transmit word and double word. The transmission rules are agreed as follows:
——BYTE transmission, which is performed in the form of byte stream;
——WORD transmission, in which the high 8 bits are transmitted first, and then the low 8 bits are transmitted;
——DWORD transmission, in which the high 24 bits are transmitted first, then the high 16 bits, the high 8 bits, and finally the low 8 bits.
4.4 Message composition
4.4.1 Message structure
Each message consists of identity bits, a message header, a message body and a check code, and the message structure is shown in Figure 1.
Identity bit Message header Message body Check code Identity bit
Figure 1 Message structure diagram
4.4.2 Identity bit
The identity bit shall be represented by 0x7e, and if 0x7e and 0x7d appear in the check code, message header and message body, they shall be escaped. The escape rules are defined as follows:
Firstly, 0x7d is escaped and converted into fixed two-byte data: 0x7d 0x01;
Secondly, 0x7e is escaped and converted into fixed two-byte data: 0x7d 0x02.
The escape process is as follows:
When sending a message: first encapsulate the message, then calculate and fill in the check code, and finally escape it;
When receiving a message: firstly escape and restore the message, then verify the check code, and finally parse the message.
Example: When sending a data packet of 0x30 0x7e 0x08 0x7d 0x55, it is encapsulated as follows: 0x7e 0x30 0x7d 0x02 0x08 0x7d 0x01 0x55 0x7e.
4.4.3 Message header
4.4.3.1 See Table 2 for the content of message header.
4.4.3.2 The format structure of message body attribute is shown in Figure 2.
Table 2 Content of message header
Start byte Field Data type Description and requirement
0 Message ID WORD —
2 Message body attribute WORD The format structure of message body attribute is shown in Figure 2
4 Protocol version number BYTE Protocol version, which is incremented with each critical revision, with an initial version number of 1
5 Terminal phone number BCD[10] It is converted according to the phone number of the terminal installed. If the phone number is insufficient, the number 0 will be added before it
15 Message serial number WORD It is circularly accumulated from 0 in the sending order
17 Message packet encapsulation item — If the relevant identity bit in the message body attribute determines that the message is sub-packaged, then this item has content, otherwise this item does not exist
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Version identity Subpacket Data encryption mode Message body length
Note: The value of the version identity bit is fixed at 1.
Figure 2 Format structure diagram of message body attribute
4.4.3.3 Data shall be encrypted as follows:
——bit10~bit12 are data encryption identity bits;
——when all three bits are 0, it means that the message body is not encrypted;
——when the 10th bit is 1, it means that the message body is encrypted by RSA algorithm;
——other bits are reserved.
4.4.3.4 Message subpacket shall be processed according to the following requirements:
——when the 13th bit in the message body attribute is 1, it means that the message body is a long message and is subjected to subpacket transmission processing, and the specific subpacket information is determined by the message packet encapsulation item;
——if the 13th bit is 0, there is no message packet encapsulation item field in the message header.
See Table 3 for the content of message packet encapsulation item.
Contents of JT/T 808-2019/XG1-2021
Foreword II
1 Scope
2 Normative references
3 Terms, definitions and abbreviations
4 Protocol basis
5 Communication connection
6 Message processing
7 Protocol classification and requirements
8 Data format
Annex A (Normative) Communication protocol between on-board terminal and external equipment
Annex B (Normative) Table for message comparison
JT/T 808-2019/XG1-2021, JT 808-2019/XG1-2021, JT 808-2019XG1-2021, JT/T808-2019/XG1-2021, JT/T 808, JT/T808, JT808-2019/XG1-2021, JT 808, JT808, JT808-2019XG1-2021, JT 808, JT808