GB/T 20851.3-2019Electronic toll collection - Dedicated short range communication - Part 3: Application layer (English PDF)

Foreword

GB/T 20851 `` Special short-range communication for electronic toll collection '' is divided into 5 parts.

--- Part 1. physical layer;

--- Part 2. Data link layer;

--- Part 3. Application layer;

--- Part 4. Equipment application;

--- Part 5. Test methods for main parameters of the physical layer. This part is the third part of GB/T 20851. This section is drafted in accordance with the rules given in GB/T 1.1-2009. This section replaces GB/T 20851.3-2007 "Special short-range communication for electronic tolling-Part 3. Application layer", and Compared to.2007, only editorial changes were made. This section is proposed and managed by the National Intelligent Transportation System Standardization Technical Committee (SAC/TC268). This section was drafted by: Highway Research Institute of the Ministry of Transport, Zhongguancun CCCC Guotong Intelligent Transportation Industry Alliance, Beijing CCCC Guotong Intelligent Transportation System Technology Co., Ltd., Shenzhen Jinyi Technology Co., Ltd., Beijing Sutong Technology Co., Ltd., Beijing Juli Technology Co., Ltd. Co., Ltd., Shenzhen Chenggu Technology Co., Ltd. The main drafters of this section. Chen Bingxun, Liu Hongwei, Song Xianghui, Liu Yongping, Zhang Beihai, Gui Jie, Zhou Jian, Zhang Yujun, Lu Liyang, Zhou Bin, Zhang Chunjie. The previous versions of the standards replaced by this section are.

--- GB/T 20851.3-2007. Dedicated short-range communication for electronic toll collection Part 3. Application layer

1 Scope

China's national application layer specification for electronic toll collection DSRC. It is Part 3 of GB/T 20851 and specifies the core framework of the application layer together with the basic services provided by the transfer kernel, the initialisation kernel and the broadcast kernel, and it applies to electronic toll collection on highways and urban roads, with reference use in automatic vehicle identification and vehicle access management. The application layer is where the transaction actually happens, and its structure follows from the constraint the physical layer imposes: a very short and unrepeatable exchange. The initialisation kernel handles the first moments, in which the roadside unit announces itself and the applications it supports and an on-board unit entering the zone declares what it is and what it carries. The transfer kernel provides the services by which the two then exchange data - reading and writing the elements of the on-board unit, invoking actions on it, and getting the results, each service defined with its parameters, its encoding and its error responses. The broadcast kernel serves the case where information goes to every unit in the zone without any of them replying. On top of those services the toll transaction itself is built by Part 4. Separating the kernels from the application is what allows one national DSRC platform to carry more than tolling - parking, access control, weight and vehicle identification can use the same on-board unit and the same roadside equipment, which is the reason the framework is defined as a general one and not simply as a toll protocol. Issued on 10 May 2019 and in force since 1 December 2019, it replaces GB/T 20851.3-2007.

This part of GB/T 20851 specifies the core framework of the short-range communication application layer dedicated to electronic toll collection, as well as the transmission kernel and initialization Basic services provided by the nuclear and broadcast kernels. This section applies to electronic toll systems for highways and urban roads. References can be made to areas such as automatic vehicle identification and vehicle access management.

2 Normative references

The following documents are essential for the application of this document. For dated references, only the dated version applies to this article Pieces. For undated references, the latest version (including all amendments) applies to this document.

GB/T 9387.1-1998 Information Technology Open System Interconnection Basic Reference Model Part 1. Basic Model

GB/T 16263.2 Information technology ASN.1 coding rules Part 2. Compact coding rules (PER) specification

GB/T 20839-2007 General terms for intelligent transportation systems

GB/T 20851.2-2019 Short-distance communication dedicated to electronic charges Part 2. Data link layer

GB/T 20851.4-2019 Short-distance communication dedicated to electronic charges Part 4. Equipment applications

3 Terms and definitions

The terms and definitions defined in GB/T 9387.1-1998 and GB/T 20839-2007 and the following apply to this document.

3.1 Application Users of DSRC protocol services.

3.2 File On-board unit (OBU) is the basic organizational unit for application data. Generally, multiple related data units form a file.

3.3 File identifier The identification number of the file. Under the same directory, the file identification number is unique.

3.4 Directory identifier A logo that clearly identifies a directory.

3.5 Broadcast The Road Side Unit (RSU) sends out messages using broadcast addresses and is targeted at all OBU communication applications that do not require OBU responses.

3.6 Initialization The process initiated by the RSU to negotiate the communication parameters and configuration with the OBU.

3.7 Layer management Provides DSRC communication parameter values and information necessary to collect and publish other control communication systems to support the communication system management.

3.8 Configuration profile Information about features, performance, settings of different layers or application processing. It is identified by an integer value.

4 Acronyms

The following abbreviations apply to this document. ADU. Application Data Unit AID. Application Identifier ASN.1. AbstractSyntaxNotationOne B-KE. BroadcastKernel BST. BeaconServiceTable DID. DirectoryIdentifier DSRC. DedicatedShortRangeCommunication ETC. Electronic Toll Collection FID. File Identifier IID. InvokerIdentifier I-KE. Initialization Kernel L1. DSRC physical layer (Layer1) L2. DSRC data link layer (Layer2) L7. DSRC application layer (Layer7) LID. Link Identifier LLC. Logical Link Control LPDU. Logical Link Control Protocol Data Unit (LLCProtocolDataUnit) LSAP. Logical Link Control Service Access Point (LLCServiceAccessPoint) LSDU. Logical Link Control Service Data Unit (LLCServiceDataUnit) MAC. Medium Access Control OBU. OnBoardUnit PDU. Protocol Data Unit PER. PackedEncodingRules PPDU. Physical layer protocol data unit (PhysicallayerProtocolDataUnit) RID. Record Identifier RSU. Roadside Unit SAP. ServiceAccessPoint SDU. Service Data Unit T-APDU. Transfer-Application Protocol Data Unit T-ASDU. Transfer-Application Service Data Unit T-KE. TransferKernel VST. Vehicle Service Table

5 Application layer core framework

The core of the application layer includes T-KE, B-KE, I-KE, and T-KE provides the I-KE and data transmission foundation required by the application. Application layer core The frame is shown in Figure 1. Figure

7 INITIALIZATION

Enabled by I-KE to initialize communication between the RSU and each OBU that has not established communication with it. early Initialization services should only be used by I-KE

6.2.2 Service primitives T-KE shall be serviced by the following service primitives.

a) GET.request, GET.indication, GET.response, GET.confirm;

b) SET.request, SET.indication, SET.response, SET.confirm;

c) CREATE.request, CREATE.indication, CREATE.response, CREATE.confirm;

d) REMOVE.request, REMOVE.indication, REMOVE.response, REMOVE.confirm;

e) ACTION.request, ACTION.indication, ACTION.response, ACTION.confirm;

f) EVENT-REPORT.request, EVENT-REPORT.indication, EVENT-REPORT.response, E- VENT-REPORT.confirm;

g) INITIALIZATION.request, INITIALIZATION.indication, INITIALIZATION.response, INITIALIZATION.confirm. INITIALIZATION.request and INITIALIZATION.confirm primitives should be used on the RSU side, INITIALIZA- The TION.indication and INITIALIZATION.response primitives should be used on the OBU side. The services used by the confirmation model are shown in Figure 2. The services used in unconfirmed mode are shown in Figure 3. Figure

10 Flow control, data unit exchange preparation DL-REPLY-UPDATE.request

11 Flow control, data unit exchange preparation status DL-REPLY-UPDATE-STATUS.indication

6.2.4.9 File, file list and file identification list The file is the content of the file sent by SET.request/SET.indication or GET.response/GET.confirm. If the access bar The file is satisfied, and the directory receiving SET.indication should modify the file content identified in the file identification to the content value given in the file. in In the case of GET.response/GET.confirm, if the access conditions are met, the directory receiving the corresponding GET.indication shall The GET.indication file identification file content value is sent to the GET.request-enabled directory. The file list is a list containing file identification and file length information, and the file identification list is a list of file identification information.

6.2.4.10 Return code A return code issued in response to an indication of a service primitive. The predefined code is as follows:

a) NoError. the requested operation was performed successfully;

b) AccessDenied. The requested operation was not performed due to system security reasons;

c) ArgumentError. The file content access failed because the specified file content was not recognized or the specified file content exceeded the standard Surrounding or unsuitable for certain content of the file, or the enabled event reporting is not supported by the receiving entity;

d) ComplexityLimitation. The requested operation was not performed because the parameters were too complex;

e) ProcessingFailure. general failures encountered in processing operations;

f) Processing. The requested operation is being processed, but the result cannot be used;

g) ChainingError. The requested operation was not performed according to the rules defined in 6.3.9.

6.2.4.11 Mode Boolean parameter. If the value is "TRUE", the indication of the service primitive has a response of the service primitive.

6.2.4.12 Operation type Identifies a specific operation on the recipient directory.

6.2.4.13 Operating parameters Information required to enable ACTION operations.