GB/T 20851.3: Evolution and historical versions
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 20851.3-2019 | English | 500 |
Add to Cart
|
0--9 seconds. Auto-delivery
|
Electronic toll collection -- Dedicated short range communication -- Part 3: Application layer
| Valid |
GB/T 20851.3-2019
|
| GB/T 20851.3-2007 | English | RFQ |
ASK
|
6 days [Need to translate]
|
Electronic toll collection -- Dedicated short range communication -- Part 3: Application layer
| Obsolete |
GB/T 20851.3-2007
|
PDF similar to GB/T 20851.3-2019
Basic data | Standard ID | GB/T 20851.3-2019 (GB/T20851.3-2019) | | Description (Translated English) | Electronic toll collection -- Dedicated short range communication -- Part 3: Application layer | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | L79 | | Classification of International Standard | 35.100.70 | | Word Count Estimation | 42,413 | | Date of Issue | 2019-05-10 | | Date of Implementation | 2019-12-01 | | Older Standard (superseded by this standard) | GB/T 20851.3-2007 | | Quoted Standard | GB/T 9387.1-1998; GB/T 16263.2; GB/T 20839-2007; GB/T 20851.2-2019; GB/T 20851.4-2019 | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration | | Summary | This standard specifies the core framework of the dedicated short-range communication application layer for electronic charging and the basic services provided by the transmission core, the initialization core and the broadcast core. This standard is applicable to electronic toll collection systems for highways and urban roads, and can be used for reference in the fields of automatic vehicle identification and vehicle exit management. | GB/T 20851.3-2019: Electronic toll collection -- Dedicated short range communication -- Part 3: Application layer
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Electronic toll collection--Dedicated short range communication--Part 3. Application layer
ICS 35.100.70
L79
National Standards of People's Republic of China
Replaces GB/T 20851.3-2007
Dedicated short-range communication for electronic toll collection
Part 3. Application layer
Part 3. Applicationlayer
Published on May 10,.2019
2019-12-01 Implementation
State Administration of Market Supervision
Published by China National Standardization Administration
Contents
Foreword I
1 Scope 1
2 Normative references 1
3 Terms and definitions 1
4 Abbreviations 2
5 Application layer core framework 3
6 T-KE 3
7 I-KE 18
8 B-KE 22
Appendix A (Normative) Data Structure 25
Appendix B (informative) Coding example 33
Appendix C (informative) Class A and B compatibility management 36
Appendix D (Normative) Naming and Registration 37
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
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 1 Core framework of the application layer
6 T-KE
6.1 Function
T-KE transfers information between two service users by converting a predefined service primitive into a T-APDU and its inverse process.
Abstract representation of the concrete implementation of the transfer.
6.2 Service
6.2.1 Scope
T-KE shall provide the services listed in Table 1.
Table 1 T-KE services
Serial number service description
1 GET
Enabled by the application to read out the application data file of the other party. The service can only be requested in confirmation mode
And ask for an answer
2 SET
Enabled by the application to update the other application information data file. Can be requested in confirmed or unconfirmed mode
The service. Ask for an answer in confirmation mode
3 CREATE
Enabled by the application to create data formatting information (directories and files) for the other application. Only in confirmation mode
To request the service and request a response
4 REMOVE
Enabled by the application to delete data formatting information (directories and files) of the other application. Only in confirmation mode
To request the service and request a response
5 ACTION
Enabled by the application, which requires the other application to complete a specific operation. Operations are further qualified by operation type values. Available at
Request the service in confirmed mode or unconfirmed mode, and ask for response in confirmed mode
6 EVENT-REPORT is enabled by the application or I-KE to report events to peer applications or I-KE. Ask for an answer in confirmation mode
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 2 Services used in confirmation mode
Figure 3 Services used in unconfirmed mode
6.2.3 Service primitive format
The T-ASDU of the GET service primitive shall have the format of Table 2.
Table 2 GET service primitives
Parameter name in English means request indication response confirmation ASN.1 type c
Enable identification IID optional optional = a = Dsrc-DID
Link ID LID Required = = INTEGER
Link Chaining Essentials == BOOLEAN
Catalog ID DID Required IID/DIDb IID/DID Dsrc-DID
AccessCredentials Optional--OCTETSTRING
Document Identification FID Mandatory Mandatory Mandatory FID
Offset must-have--INTEGER
Length Required--INTEGER
Data Flow Control Mandatory Mandatory Mandatory Optional INTEGER
FileContent--Optional File
Return Code--Required Mandatory ReturnStatus
Note. For record-type files, Offset indicates the record identification number, and Length indicates the length of the record content.
a Same as the corresponding request/instruction.
b Required. If IID appears, relevant instructions will be given, otherwise DID relevant instructions will be given.
c ASN.1 types are as specified in Appendix A.
The T-ASDU of the SET service primitive shall have the format shown in Table 3.
Table 3 SET service primitives
Parameter name in English means request indication response confirmation ASN.1 type d
Enable identification IID optional optional = b = Dsrc-DID
Link ID LID Required = = INTEGER
Link Chaining Essentials == BOOLEAN
Catalog ID DID Required IID/DIDc IID/DID DID
AccessCredentials Optional--OCTETSTRING
Document Identification FID Mandatory Mandatory Mandatory FID
Table 3 (continued)
Parameter name in English means request indication response confirmation ASN.1 type d
Offset a Offset Required--INTEGER
Length Required--INTEGER
FileFileContent Required--File
Mode Required--BOOLEAN
Data Flow Control Mandatory Mandatory Mandatory Optional INTEGER
Return Code--Required Mandatory ReturnStatus
a When writing to a record file, it is added to the record format; if the same content as the previous record is detected, no operation is performed.
b Same as the corresponding request/instruction.
c Required. If IID appears, relevant instructions will be given, otherwise DID relevant instructions will be given.
d ASN.1 types are as specified in Appendix A.
The T-ASDU of the CREATE service primitive shall have the format of Table 4.
Table 4 CREATE service primitives
Parameter name in English means request indication response confirmation ASN.1 type c
Enable identification IID optional optional = a = Dsrc-DID
Link ID LID Required = = INTEGER
Catalog ID DID Required IID/DIDb IID/DID Dsrc-DID
Link Chaining Essentials == BOOLEAN
AccessCredentials Optional--OCTETSTRING
FileList Essentials--FileList
Data Flow Control Mandatory Mandatory Mandatory Optional INTEGER
Return Code--Required Mandatory ReturnStatus
Note. Two types of files are supported. binary files and record files (variable length records).
a Same as the corresponding request/instruction.
b Required. If IID appears, relevant instructions will be given, otherwise DID relevant instructions will be given.
c ASN.1 types are as specified in Appendix A.
The T-ASDU of the REMOVE service primitive shall have the format of Table 5.
Table 5 REMOVE service primitives
Parameter name in English means request indication response confirmation ASN.1 type c
Enable identification IID optional optional = a = Dsrc-DID
Link ID LID Required = = INTEGER
Link Chaining Essentials == BOOLEAN
Catalog ID DID Required IID/DIDb IID/DID Dsrc-DID
Table 5 (continued)
Parameter name in English means request indication response confirmation ASN.1 type c
AccessCredentials Optional--OCTETSTRING
FileIdList Required--FileIdList
Data Flow Control Mandatory Mandatory Mandatory Optional INTEGER
Return Code--Required Mandatory ReturnStatus
a Same as the corresponding request/instruction.
b Required. If IID appears, relevant instructions will be given, otherwise DID relevant instructions will be given.
c ASN.1 types are as specified in Appendix A.
The T-ASDU of the ACTION service primitive shall have the format of Table 6.
Table 6 ACTION service primitives
Parameter name in English means request indication response confirmation ASN.1 type c
Enable identification IID optional optional = a = DID
Link ID LID Required = = INTEGER
Link Chaining Essentials == BOOLEAN
Catalog ID DID Required IID/DIDb IID/DID DID
ActionType Mandatory Mandatory--INTEGER (0.127, ..)
AccessCredentials Optional--OCTETSTRING
ActionParameter Optional--Container
Mode Required--BOOLEAN
Data Flow Control Mandatory Mandatory Mandatory Optional INTEGER
ResponseParameter--Optional Container
Return code Ret--Optional ReturnStatus
a Same as the corresponding request/instruction.
b Required. If IID appears, relevant instructions will be given, otherwise DID relevant instructions will be given.
c ASN.1 types are as specified in Appendix A.
The T-ASDU of the EVENT-REPORT service primitive shall have the format of Table 7.
Table 7 EVENT-REPORT service primitives
Parameter name in English means request indication response confirmation ASN.1 type c
Enable identification IID optional optional = a = DID
Link ID LID Required = = INTEGER
Link Chaining Essentials == BOOLEAN
Catalog ID DID Required IID/DIDb IID/DID DID
EventType Required Type-INTEGER (0.127, ..)
Table 7 (continued)
Parameter name in English means request indication response confirmation ASN.1 type c
AccessCredentials Optional--OCTETSTRING
EventParameter Optional--Container
Mode Required--BOOLEAN
Data Flow Control Mandatory Mandatory Mandatory Optional INTEGER
Return code Ret--Optional ReturnStatus
a Same as the corresponding request/instruction.
b Required. If IID appears, relevant instructions will be given, otherwise DID relevant instructions will be given.
c ASN.1 types are as specified in Appendix A.
The T-ASDU of the INITIALIZATION service primitive shall have the format of Table 8.
Table 8 INITIALIZATION service primitives
Parameter name in English means request indication response confirmation ASN.1 type a
Link ID LID Mandatory Mandatory Mandatory INTEGER
Initialization parameter InitializationParameter Mandatory Mandatory Mandatory Mandatory BST/VST
aASN.1 types are as specified in Appendix A.
6.2.4 Parameter setting and interpretation
6.2.4.1 Enable identification
ASN.1 type dedicated short-range communication directory identifier corresponding to the service enabler. If the response is delivered to the default enabler, this parameter is not required
Number; if an IID is used, it should include the DID in response to this primitive.
6.2.4.2 Link identification
The LID selected by the I-KE of the OBU; the value of LID is the same as the MAC address.
6.2.4.3 Link
If the value of Boolean parameter is "TRUE", then the provisions of 6.3.9 are implemented.
6.2.4.4 Directory identification
The recipient's ASN.1 type dedicated short-range communication directory identifier, and the recipient's T-KE uses the DID to submit an instruction or confirmation to the directory.
6.2.4.5 Access credentials
ASN.1 type octet string with security related information required to meet access conditions, used to perform on specified directories
operating.
6.2.4.6 File identification
The file ID of the directory receiving the GET.indication. The access conditions are met, the contents of the file are obtained via GET.response and
GET.confirm is served to directories that have GET.request enabled.
6.2.4.7 Offset
In the GET service, the starting position of the data content in the binary file or the RID of the record-type file.
In the SET service, the starting position of the data content in the binary file or the RID of the record-type file.
6.2.4.8 Data flow control
Parameters that represent the behavior of basic communication services, which are mapped by T-KE to an LLC service
2019. The relationship between data flow control parameters, behaviors, and LLC services is shown in Table 9.
Table 9 Relationship between data flow control parameters, behaviors, and LLC services
Data Flow Control Behavior LLC Service
1 no flow control, no response DL-UNITDATA.request without response request
2 no flow control, DL-UNITDATA.request with response request
3 DL-UNITDATA.indication without flow control
4 Flow control, data unit transmits DL-DATA-ACK.request
5 Flow control, data unit transmission DL-DATA-ACK.indication
6 Flow control, data unit transmission status DL-DATA-ACK-STATUS.indication
7 Flow control, data unit exchange DL-REPLY.request
8 Flow control, data unit exchange DL-REPLY.indication
9 Flow control, data unit exchange status DL-REPLY-STATUS.indication
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.
6.2.4.14 Response parameters
|