YD/T 3707-2020 English PDF (YDT3707-2020)

Delivery: 3 seconds. Download true-PDF + Invoice.
Get QUOTATION in 1-minute: Click YD/T 3707-2020
Historical versions: YD/T 3707-2020
Preview True-PDF (Reload/Scroll if blank)

YD/T 3707-2020: Technical requirements of network layer of LTE-based vehicular communication
YD/T 3707-2020
YD
COMMUNICATION INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 33.060.99
M 36
Technical Requirements of Network Layer of LTE-
based Vehicular Communication
ISSUED ON: APRIL 16, 2020
IMPLEMENTED ON: JULY 1, 2020
Issued by: Ministry of Industry and Information Technology of the
People’s Republic of China.
Table of Contents
Foreword ... 3 
1 Scope ... 4 
2 Normative References ... 4 
3 Abbreviations ... 4 
4 Technical Requirements of Network Layer ... 5 
4.1 System Introduction ... 5 
4.2 Network Layer Framework ... 6 
4.3 Technical Requirements for Data Sublayer ... 7 
4.4 Technical Requirements for Management Sublayer ... 13 
4.5 Access Point and Service Primitive ... 16 
Appendix A (normative) Type and Value of Protocol Type ... 32 
Appendix B (normative) Frame Structure of Extension ... 33 
Appendix C (normative) MIB Messages ... 34 
Appendix D (normative) Mapping Relations between Priority and PPPP ... 35 
Appendix E (informative) Example of Source Address / Destination Address
Design of Adaptation Layer ... 37 
Technical Requirements of Network Layer of LTE-
based Vehicular Communication
1 Scope
This Standard specifies the technical requirements of network layer of LTE-based
vehicular communication, including short message protocol, application registration,
service management and service advertisement. Specifically, they include network
layer framework, technical requirements of data sublayer, data sublayer of
management sublayer, access point and service primitive.
This Standard is applicable to the network layer of LTE-based vehicular communication.
2 Normative References
The following documents are indispensable to the application of this document. In
terms of references with a specified date, only versions with a specified date are
applicable to this document. In terms of references without a specified date, the latest
version (including all the modifications) is applicable to this document.
YD/T 3340-2018 Technical Requirements of Air Interface of LTE-based Vehicular
Communication
YD/T 3400-2018 General Technical Requirements of LTE-based Vehicular
Communication
3 Abbreviations
The following abbreviations are applicable to this document.
AID Application ID
CBR Channel Busy Ratio
DME Dedicated Management Entity
DSA Dedicated Service Advertisement
DSM Dedicated Short Message
DSMP Dedicated Short Message Protocol
IP Internet Protocol
The main forms of service request include: provider service request, user service
request and short message service request. See the detailed description of the three
forms of service request below:
a) For DME, provider service request indicates that the upper layer hopes it will
send DSA, and after DME accepts the provider service request, it will
generate a corresponding table entry of the provider service request in MIB
and consider the service request when deciding on channel access allocation;
b) For DME, user service request indicates that the upper layer entity is
interested in available service that satisfies the specified criteria. The request
indicates the action to be taken when DME identifies this available service.
When DME accepts the user service request, it will generate a corresponding
table entry of the user service request in MIB and consider the service request
when deciding on channel access allocation;
c) For DME, short message service request indicates that the upper layer entity
wants to receive a DSM with a specified AID. When DME accepts the short
message service request, it will generate a corresponding table entry of the
short message service request in MIB and deliver any received DSM with
matching AID to the requested upper layer entity.
When DME receives service requests of different action types, it will adopt different
response modes as follows:
a) When receiving a service request with the action type of “ADD”, add the
corresponding service message in MIB;
b) When receiving a service request with the action type “UPDATE”, update the
corresponding service message in MIB;
c) When receiving a service request with the action type “DELETE”, delete the
corresponding service message in MIB.
4.4.3 MIB maintenance
The MIB operating procedures are shown in Figure 10. MIB is responsible for the
management and maintenance of the application configuration and status information
of the LTE-based vehicular communication module. DME sets and inquires MIB
information through designated signaling. After DME receives a service request
message, it will establish a MIB message list corresponding to the service in MIB. This
message list items include application configuration and status information, and
transmission environment configuration of service data based on the status information.
DME-mibSet.request is used to indicate the value of a specific DME MIB attribute
specified by the upper layer.
The parameters of the service primitive are as follows:
4.5.5.10 DME-mibSet.confirm
DME-mibSet.confirm confirms that the corresponding configuration request has been
received from the upper layer and responds DME-Set.request. If Status is successful,
it feeds back the value of a specific DME MIB attribute, which has been set as
requested; otherwise, an error indication is returned in Status field. Possible error
indications include: “invalid MIB attribute” and “attempt to set read-only MIB attribute”.
The parameters of the service primitive are as follows:
4.5.5.11 DME-Notification.indication
DME-Notification.indication is used to notify the upper layer entity that something has
happened. The specific content may be expanded as needed during execution.
The parameters of the service primitive are as follows:
The stipulations of the parameters of the service primitive of DME-
Notification.indication are shown in Table 19.
Appendix E
(informative)
Example of Source Address / Destination Address Design of Adaptation Layer
E.1 General Description
The adaptation layer address is formed by the concatenation of the remote
communication interface address field and the local communication interface address
field, as it is shown in Table E.1.
The specific meaning of each field is as follows:
a) The remote communication interface address field is used to indicate the
bottom layer MAC address. It adopts EUI-64 address format and supports
encapsulated 48-bit MAC address, 24-bit MAC address and atypical address
encapsulation. See E.2 for the form of encapsulation;
b) The local communication interface address field is used to indicate the
hardware address of the bottom layer transmission or the identifier of the
bottom layer communication technology. This address is associated with a
certain access technology. An example of the correspondence between the
value of the local communication interface address field and the access
technology is shown in E.3.
E.2 Format of Remote Communication Interface Address Field
The remote communication interface address field is based on the EUI-64 address
format defined by IEEE. See the format in Figure E.1.
Figure E.1 -- EUI-64 Format
For the communication technology that supports 48-bit MAC address, the
encapsulation format of MAC address is shown in Figure E.2.