Skip to product information
1 of 6

PayPal, credit cards. Download editable-PDF and invoice in 1 second!

GB/T 43258.2-2023 English PDF (GBT43258.2-2023)

GB/T 43258.2-2023 English PDF (GBT43258.2-2023)

Regular price $1,205.00 USD
Regular price Sale price $1,205.00 USD
Sale Sold out
Shipping calculated at checkout.
Delivery: 3 seconds (Download full-editable-PDF + Invoice).
Quotation: Click GB/T 43258.2-2023>>Add to cart>>Quote
Editable-PDF Preview (Reload if blank, scroll for next page)

GB/T 43258.2-2023: Road vehicles -- Diagnostic communication over Internet Protocol (DoIP) -- Part 2: Transport protocol and network layer services
GB/T 43258.2-2023
GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 43.040.10
CCS T 36
Road vehicles - Diagnostic communication over Internet
Protocol (DoIP) - Part 2: Transport protocol and network
layer services
与网络层服务
(ISO 13400-2:2019, MOD)
ISSUED ON: NOVEMBER 27, 2023
IMPLEMENTED ON: NOVEMBER 27, 2023
Issued by: State Administration for Market Regulation;
Standardization Administration of the People’s Republic of China.
Table of Contents
Foreword ... 4
Introduction ... 6
1 Scope ... 9
2 Normative references ... 10
3 Terms and definitions ... 11
4 Symbols and abbreviated terms ... 14
4.1 Symbols ... 14
4.2 Abbreviated terms ... 14
5 Conformance ... 16
6 DoIP introduction ... 16
6.1 General information ... 16
6.2 Connection establishment and vehicle discovery ... 17
6.3 Vehicle network integration ... 22
6.4 Communication examples using message sequence charts ... 23
6.5 IP-based vehicle communication protocol — General information ... 23 7 Application (APP) requirements ... 24
7.1 APP implementation of DoIP requirements ... 24
7.2 APP data transmission order ... 24
7.3 APP DoIP entity synchronization of a vehicle’s GID ... 24
7.4 APP vehicle identification and announcement request message ... 27
7.5 APP diagnostic power mode information request and response ... 34
7.6 APP DoIP entity status information request and response ... 34
7.7 APP timing and communication parameters ... 35
7.8 APP logical addressing ... 37
7.9 APP communication environments and recommended timings ... 38
7.10 APP DoIP entity functional requirements ... 38
8 Service interface ... 39
8.1 General ... 39
8.2 Service primitive parameters (SPP) ... 40
8.3 SPP DoIP layer service interface ... 42
9 Application layer (AL) ... 44
9.1 AL dynamic host control protocol (DHCP) ... 44
9.2 AL generic DoIP protocol message structure ... 50
9.3 AL handling of UDP packets and TCP data ... 56
9.4 AL supported payload types over TCP and UDP ports ... 56
9.5 AL diagnostic message and diagnostic message acknowledgement ... 57 9.6 AL alive check request and alive check response ... 62
10 Transport layer security (TLS) ... 63
10.1 TLS secure diagnostic communication ... 63
10.2 TLS DoIP application profile ... 66
11 Transport layer (TL) ... 68
11.1 TL transmission control protocol (TCP) ... 68
11.2 TL user datagram protocol (UDP)... 71
11.3 TL handling of UDP messages ... 75
12 Network layer (NL) ... 75
12.1 NL internet protocol (IP) ... 75
12.2 NL IPv4 address resolution protocol (ARP) ... 76
12.3 NL IPv6 neighbour discovery protocol (NDP) ... 77
12.4 NL internet control message protocol (ICMP) ... 77
12.5 NL IP-based vehicle communication protocol ... 78
12.6 NL socket handling ... 84
13 Data link layer (DLL) ... 92
13.1 DLL general ... 92
13.2 DLL MAC-layer ... 92
Bibliography ... 93
Foreword
This document is drafted in accordance with the rules provided in GB/T 1.1-2020 Directives for standardization - Part 1: Rules for the structure and drafting of standardizing documents.
This document is part 2 of GB/T 43258 Road vehicles - Diagnostic communication over Internet Protocol (DoIP). The following parts have been issued for GB/T 43258: — Part 2: Transport protocol and network layer services;
— Part 3: Wired vehicle interface based on IEEE 802.3;
— Part 4: Ethernet-based high-speed data link connector.
This document adopts ISO 13400-2:2019 Road vehicles - Diagnostic communication over Internet Protocol (DoIP) - Part 2: Transport protocol and network layer services by modification.
The technical differences between this document and ISO 13400-2:2019, and the causes for these differences are as follows:
— USE the normatively referenced GB 16735 to replace ISO 3779 (see Table 4 and Table 5), to adapt to the technical conditions in China and to improve operability; — ADD the symbol < k> (see 4.1), to improve the usability of the document; — ADD the abbreviated terms AutoIP, PDU and OTA, and DELETE the unused
abbreviated term FMI (see 4.2), to improve the usability of the document; — CHANGE “the DoIP entity has an IP address configured in approximately two seconds” to “the DoIP entity has an IP address configured in approximately seven seconds”, and CHANGE “an IP address is configured after approximately seven seconds” to “an IP address is configured after approximately two seconds” (see 9.1.2.2), so that the timing parameters are consistent with those in Table 15; — CHANGE “node management (××1616)” to “0×××16” (see 9.2), to adapt to the technical conditions in China and improve the operability;
— CHANGE “Response by the DoIP gateway” to “Response by the DoIP entity” (see Table 48), to improve the technical application flexibility.
Please note that some of the contents of this document may involve patents. The issuing organization of this document is not responsible for identifying patents. This document was proposed by the Ministry of Industry and Information Technology of the People's Republic of China.
Road vehicles - Diagnostic communication over Internet
Protocol (DoIP) - Part 2: Transport protocol and network
layer services
1 Scope
This document specifies the requirements for secured and unsecured diagnostic communication between client DoIP entity and server(s) installed in the vehicle using Internet protocol (IP) as well as the transmission control protocol (TCP) and user datagram protocol (UDP). This includes the definition of vehicle gateway requirements (e.g., for integration into an existing computer network) and test equipment (client DoIP entity) requirements (e.g., to detect and establish communication with a vehicle). This document specifies features that are used to detect a vehicle in a network and enable communication with the vehicle gateway as well as with its sub-components during the various vehicle states. These features are separated into two types: mandatory and optional.
This document specifies the following mandatory features:
— vehicle network integration (IP address assignment);
— vehicle announcement and vehicle discovery;
— vehicle basic status information retrieval (e.g., diagnostic power mode); — connection establishment (e.g., concurrent communication attempts), connection maintenance and vehicle gateway control;
— data routing to and from the vehicle's sub-components;
— error handling (e.g., physical network disconnect).
This document specifies the following optional features:
— DoIP entity status monitoring;
— transport layer security (TLS);
— DoIP entity firewall capabilities.
announcement message broadcast in the previous step is processed in some way. For example, the vehicle somehow indicates to be “ready” or an automated process is initiated based on the information that a vehicle is now available for a DoIP session. Although in the networked scenario there is still the networking equipment between the client and the DoIP entity, the communication is now logically directly between the two communication endpoints. Thus, no network is shown in Figure 5.
The first step in order to initiate a connection between the client DoIP entity and the DoIP entity in the vehicle is to open a socket (destination port is TCP_DATA). This is done prior to any message exchange. Therefore, a DoIP entity provides the resources to handle the incoming communication request (e.g., socket resources). The DoIP entity provides sufficient resources to handle the specified number of concurrently supported DoIP sessions (< n>) plus one extra socket (see DoIP-002). If more than < n + 1> connection attempts arrive at the same time, it is possible that no more resources are free and the < n + 2nd> connection attempt is refused (because there are no longer any sockets in the listening state because of DoIP protocol handling).
Once a socket is established, some initializing steps are performed. An initial inactivity timer (see 12.6.3) and a general inactivity timer (see 12.6.2) is assigned and started. Additionally, it is necessary to ensure that no arriving data, except the routing activation request message, is routed or processed by setting the connection state to “initialize” (see 12.6.1.3). All subsequent messages are exchanged through this TCP_DATA socket. This connection handling is also applied by the DoIP entity in case of secure TLS-based communication and the corresponding TCP_DATA TLS socket (see 6.2.5).
To activate routing on the initialized connection, the client sends a routing activation request message (see 12.5) to the DoIP entity. If the client DoIP entity is eligible and if there are fewer than < n> active connections registered, the corresponding initial timer is stopped and – assuming that no additional authentication or confirmation or secure TLS connection is required – the socket state changes to “registered [routing active]”. Now valid DoIP messages (e.g., DoIP diagnostic messages) are routed or processed. This is reported to the client DoIP entity by a positive routing activation response message. The general inactivity timer is restarted and remains active.
When receiving any kind of data, the DoIP entity first calls the DoIP header handler. If the payload consists of a diagnostic message (identified through the payload type 800116 in the generic DoIP header, see 9.5), the diagnostic message handler is called to process the payload.
When a diagnostic message arrives, the DoIP confirmation is sent to the calling client DoIP entity immediately after the message has successfully passed the diagnostic message handler (confirmation acknowledgement), in essence the message has passed through the corresponding internal routing mechanism but has not yet been processed by the DoIP gateway or forwarded to the final non DoIP server.
View full details