T/CSAE 159-2020 PDF in English
T/CSAE 159-2020 (T/CSAE159-2020, TCSAE 159-2020, TCSAE159-2020)
Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
T/CSAE 159-2020 | English | 1105 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
LTE-based vehicular communication - Direct communication system roadside unit technical requirements
| Valid |
Standards related to (historical): T/CSAE 159-2020
PDF Preview
T/CSAE 159-2020: PDF in English (TCSAE 159-2020) T/CASE 159-2020
ASSOCIATION STANDARD
ICS 35.100
CCS L 79
ITE-based vehicular communication - Direct communication
system roadside unit technical requirements
ISSUED ON: NOVEMBER 26, 2020
IMPLEMENTED ON: NOVEMBER 26, 2020
Issued by: China Society of Automotive Engineers
Table of Contents
Foreword ... 5
1 Scope ... 6
2 Normative references ... 6
3 Terms and definitions... 7
4 Abbreviations ... 7
5 General requirements ... 8
5.1 Standards to be followed by each layer ... 8
5.2 Access layer/PC5 ... 9
5.3 Network layer ... 10
5.4 Roadside message sending cycle and PDB requirements ... 10
5.5 Priority setting of roadside messages ... 11
6 Requirements of MAP message ... 11
6.1 Requirements of application layer ... 11
6.2 Message content ... 14
6.3 Minimum sending criteria ... 16
6.4 Requirements of data element ... 18
7 SPAT message sending requirements ... 22
7.1 Requirements of application layer ... 22
7.2 Message content ... 24
7.3 Minimum sending criteria ... 25
7.4 Requirements of data element ... 26
8 RSM message sending requirements ... 33
8.1 Requirements of application layer ... 33
8.2 Message content ... 35
8.3 Minimum sending criteira ... 36
8.4 Requirements of data element ... 38
9 RSI message sending requirements ... 41
9.1 Requirements of application layer ... 41
9.2 Message content ... 42
9.3 Classification of RSI messages ... 43
9.4 Minimum sending criteria ... 44
9.5 Requirements of data element ... 45
10 Message scheduling and congestion control ... 51
11 Requirements of RF performance ... 51
11.1 Transmitter indicators ... 51
11.2 Receiver indicators ... 51
12 Security requirements ... 51
12.1 Requirements of data format ... 51
12.2 Sending requirements of security layer message ... 52
12.3 Requirements of system security ... 53
Appendix A (Informative) System overview ... 54
Appendix B (Informative) Application description ... 55
Appendix C (Normative) Type and value of DE_EventType (traffic event index),
DF_Description (additional description) ... 56
Appendix D (Normative) Selection requirements of road abstraction point ... 60
Appendix E (Normative) Extended indication maneuver in DF_MovementList ... 62
ITE-based vehicular communication - Direct communication
system roadside unit technical requirements
1 Scope
This document specifies the technical requirements for direct communication roadside
units, which is supported by the ITE-based vehicular communication (LTE-V2X).
This document applies to roadside units, which adopts the LTE-V2X-based direct
communication.
2 Normative references
The following documents are essential to the application of this document. For the dated
documents, only the versions with the dates indicated are applicable to this document;
for the undated documents, only the latest version (including all the amendments) is
applicable to this standard.
GB 5768.2-2009 Road traffic signs and markings - Part 2: Road traffic signs
GB 14886 Specifications for road traffic signal setting and installation
GB/T 27957-2011 Grade of hail
GB/T 27967-2011 Format of weather forecast on highway traffic
GB/T 29100-2012 Road traffic information service - Traffic event classification and
coding
GB/T 30699-2014 Road traffic signs code
YD/T 3340-2018 Technical requirements of air interface of LTE-based vehicular
communication
YD/T 3707-2020 Technical requirements of network layer of LTE-based vehicular
communication
YD/T 3709-2020 Technical requirements of message layer of LTE-based vehicular
communication
YD/T 3755-2020 Technical requirements for roadside unit supporting direct
well as the expansion parts such as bus stops), as the road segment width. Width
changes, which are caused by lane extensions or bus stops, etc., are reflected in lane-
level information. The accuracy of road segment width shall be accurate to 0.1 m.
6.4.3.4 points
A column of road segment center points. It needs to meet the requirements of Appendix
D, where ActualError is not greater than 2 m.
6.4.4 DF_Movement
6.4.4.1 remoteIntersection
It consists of a globally unique region ID and a unique node ID within a region, refer
to 6.2.
6.4.4.2 phaseId
Signal light's phase ID, where the value 0 means invalid ID. The phaseId shall be
consistent with the situation that the road segment is controlled by the actual signal
lights. Refer to 7.4.3.1.
6.4.5 DF_RegulatorySpeedLimit
speed: The size of the speed limit value, which has an accuracy of 0.02 m/s.
6.4.6 DF_RoadPoint
posOffset:
Indicates the deviation value of the road's abstract location point, which is selected
according to Appendix D, as relative to the reference coordinates, including the
latitude and longitude deviation and the altitude deviation. It should adopt the
principle of cost saving, to select an appropriate encoding method.
offsetLL PositionOffsetLL:
The horizontal deviation, BETWEEN the position point as determined by the
latitude and longitude deviation AND the actual position, which is corresponding to
the point, shall not exceed 0.5 m.
offsetV VerticalOffset:
The vertical deviation, BETWEEN the position point as determined by the height
deviation AND the actual position corresponding to the point, shall not exceed 0.5
m.
6.4.7 DF_Lane
6.4.7.1 laneID
Within a road segment, each lane has a unique ID, which uses the direction of the lane
as a reference; the numbering starts from 1 from left to right; the maximum valid value
is 254. 0 means invalid ID or unknown ID. 255 is a reserved value.
6.4.7.2 laneWidth
Indicates the average width of this lane. The accuracy is 0.1 m.
6.4.7.3 laneAttributes
Define lane attributes, including lane sharing (shareWith) and the class characteristic
(laneType) to which the lane itself belongs. If it wants to represent a crosswalk, it can
set the laneType to crosswalk; meanwhile set its ID, width, center point column and
other attributes.
6.4.7.4 maneuvers
Indicates all steering behaviors, which are permitted in this lane. If, in practice, this lane
is allowed to connect to the downstream segment, at least one accessible connection
shall be expressed, in the maneuvers. Refer to 6.4.8.2 for the expression of steering-
allowing behavior of the lane.
6.4.7.5 connectsTo
Indicates the connection information of this lane to the downstream road segment. If
the actual lane is allowed to be connected to the downstream road segment, at least one
accessible connection shall be expressed as connectionsTo. The principle of geometric
maximization connection shall be adopted, between lanes and lanes.
6.4.7.6 points
Represents a column of road segment center points. It needs to meet the requirements
of Appendix D, where ActualError is not greater than 0.5 m.
6.4.8 DF_Connection
6.4.8.1 remoteIntersection
It consists of a globally unique region ID and a unique node ID within a region, refer
to 6.2.
6.4.8.2 ConnectingLane
Indicates the lane number of the downstream road segment, which is connected to this
lane, as well as the corresponding steering.
was sent, the system shall reinitialize the msgCount to a random value, which ranges
from 0 to 127, before sending the next SPAT (see YD/T 3709-2020).
When the certificate, which is used to sign the SPAT, has not changed, since the last
SPAT was sent, the system shall set the msgCount to increase by 1, as compared to the
value, which is used to send the previous SPAT; return to 0 for the next one, if the
number reaches 127.
7.4.1.2 moy & timeStamp
The system shall set moy (DE_MinuteOfTheYear) and timeStamp (DE_DSecond), as
shown in YD/T 3709-2020, using UTC as the reference time.
The moy value is used to represent the total number of minutes (UTC time) that have
passed, in the current year. The timeStamp data is used to represent the millisecond time
(UTC time), within the current minute.
The combination of the two values can represent the total elapsed time of the year, in
milliseconds.
To ensure the accuracy of the transmitted information, the deviation, between the time
represented by the two values AND the UTC real time at which the SPAT was generated,
shall be less than vMaxPosAge (150) milliseconds.
7.4.1.3 name
The name or description of the SPAT message, which is expressed by a string. The
minimum is 1 byte; the maximum is 63 bytes.
7.4.2 DF_IntersectionState
7.4.2.1 intersectionId
It consists of a globally unique region ID and a unique node ID within a region. See
6.4.2.2.
7.4.2.2 status
Indicates the current control mode state of the signal light; the internal value needs to
be set, according to the actual working state of the signal control system. The specific
setting method is as shown in Table 9. Each bit of status is initially set to 0; each
condition is independently judged and set.
7.4.5.3 minEndTime
Indicates the shortest time, from the current time to the next end of the phase state
(regardless of whether the phase state starts at the current time). For fixed period timing
signal light, minEndTime shall be equal to maxEndTime.
7.4.5.4 maxEndTime
Indicates the maximum time, from the current time to the next end of the phase state
(regardless of whether the phase state starts at the current time).
7.4.5.5 likelyEndTime
Indicates the estimated time, from the current time to the next end of the phase state
(regardless of whether the phase state starts at the current time or not). If the phase of
the signal light has a fixed period and a fixed duration, the value represents the exact
time, from the current time to the next end of the phase state. If the current phase of the
signal light is not fixed timing (induction timing, manual control, etc.), the value
represents the end time of the prediction, meanwhile the prediction time must be
between minEndTime and maxEndTime, which may be triggered by historical data or
some events. If the current light color duration continues to increase, the likelyEndTime
shall be updated synchronously, to reflect the latest timing scheme in real time.
When there is only one fixed phase state for the phase (ever green, yellow flashing,
etc.), the likelyEndTime of the phase state shall be set to 36000.
7.4.5.6 timeConfidence
The confidence level of the predicted time of the above likelyEndTime.
7.4.5.7 nextStartTime
If the current phase state has started (not ended), the value represents the estimated time,
from the current time to the next start of the phase state. If the current phase state has
not started, it represents the time, from the current time to the second start of this phase.
Usually, it is used in some related applications, such as ECO Drive.
7.4.5.8 nextDuration
If the current phase state has started (not ended), the value represents the duration after
the next start of the phase state. If the current phase state has not started, it represents
the duration after the second start of the phase state. It is used in conjunction with
nextStartTime; it is usually used in some related applications, such as ECO Drive.
Figure 1 shows the time values in both cases, when the phase state starts or does not
start, at the current time.
8.4 Requirements of data element
8.4.1 MSG_RSM
8.4.1.1 msgCount
When the first RSM is sent, after the system device is started, the system shall initialize
DE_MsgCount to a random value, which ranges from 0 to 127 (see YD/T 3709-2020).
When the certificate, which is used to sign the RSM, has changed since the last RSM
was sent, the system shall re-initialize DE_MsgCount to a random value, which ranges
from 0 to 127, before sending the next RSM (see YD/T 3709-2020).
When the certificate, which is used to sign the RSM, has not changed since the last
RSM was sent, the system shall set DE_MsgCount to increase by 1, as compared to the
value used to send the previous RSM; return to 0 for the next one, if the number reaches
127.
8.4.1.2 Id
For the first RSM, which is generated after the system device is started, the system shall
initialize the RSU device identification id to a random value, whose range is defined by
YD/T 3709-2020.
When the certificate, which is used to sign the RSM, has changed since the last RSM
was sent, the system shall reinitialize the id to a random value, before sending the next
RSM, the range of which is defined by YD/T 3709-2020.
8.4.1.3 refPos
The system shall set lat and lon, in refPos, to the 2D horizontal position reference.
The system shall set elevation to the elevation of its corresponding location reference
above or below the reference ellipse ("height above the reference ellipse").
8.4.1.4 participants
It defines the traffic participant information set, including at least one piece of RSU
self-information, which is applied to the RSM message, to represent all or part of the
traffic participant information, which is currently detected by the roadside unit.
8.4.2 DF_ParticipantData
8.4.2.1 ptcType
The type of traffic participant, which is detected by the roadside unit. 0 is unknown, 1
is motor vehicle, 2 is non-motor vehicle, 3 is pedestrian, 4 is rsu itself.
The transmission shall correctly reflect the gear state of the vehicle.
8.4.2.9 speed
In 68% of the test measurements, the difference between speed and the actual speed of
the traffic participant shall be within vSpeedAccuracy (1kph). When the data of traffic
participants comes from RSU perception, the data accuracy requirements depend on the
specific RSU indicators, which are not specified in this document.
8.4.2.10 heading
The heading describes the direction of the traffic participant's reference point; its value
increases clockwise, with true north as 0.
When the traffic participant speed does not exceed vHeadingSpeedThresh (45kph), the
difference of DE_Heading, as relative to the traffic participant's actual heading angle,
in 68% of the test measurements, shall be within vHeadAccuracyB (3 degrees).
When the traffic participant speed exceeds vHeadingSpeedThresh (45kph), the
difference of DE_Heading, as relative to the traffic participant's actual heading angle,
in 68% of the test measurements, shall be within vHeadAccuracyA (2 degrees).
When the traffic participant's speed drops below vHeadLatchThresh (4kph), the system
shall latch the value of DE_Heading as the last known heading angle value, when the
traffic participant's speed is above vHeadLatchThresh.
When the traffic participant speed is higher than vHeadUnlatchThresh (5kph), the
system unlatches the value of DE_Heading.
When the data of traffic participants comes from RSU perception, the data accuracy
requirements depend on the specific RSU indicators, which are not specified in this
document.
8.4.2.11 angle
Define the steering wheel angle of the vehicle. Rightward is positive, leftward is
negative. The resolution is 1.5°. The value 127 is an invalid value.
8.4.2.12 motionCfd
Describe the accuracy of the vehicle's operating state, including speed accuracy,
heading accuracy, steering wheel angle accuracy.
8.4.2.13 accelSet
The lat and long of this field shall be within vAccelAccuracy (0.3 m/s2), as relative to
the actual longitudinal and lateral acceleration of traffic participants, in over 68% of the
test measurements.
g) The rtsid, in DF_RTSData, needs to ensure the uniqueness in the RSU device;
h) In use, the device ID in Msg_RSI and the id in DF_RTSData and DF_RTEData
shall be used as the unique identifier of RTS or RTE;
i) The DF_SignType, in DF_RTSData, indicates the type of the traffic sign; the
specific type can refer to GB 5768.2-2009;
j) One of DF_ReferencePathList and DF_ReferenceLinkList, in DF_RTSData, must
be not empty, traffic sign information, specifically affected Path or Link, at least
one of them shall be sent;
k) DF_RTSData shall contain the description field; the description shall use the
textGB2312 format, in which characters 1 ~ 16 shall use the road traffic sign
encoding in GB/T 30699-2014, corresponding to the road traffic sign; other
characters can be added behind it;
l) The DF_EventType, in DF_RTEData, identifies the type of traffic event; please
refer to Appendix C for details;
m) The priorities of DF_RTEData and DF_RTSData are only coded, within their
respective ranges; there is no need for unified arrangement between the two
priorities.
9.3 Classification of RSI messages
The information, which is contained in the RSI message, is divided into three categories:
a) Dynamic information: It is closely related to road traffic participants; event
information changes dynamically with the number of traffic participants;
b) Semi-static information: It is related to road traffic participants, but a slow-
changing process; OR it means that once the event occurs, it will maintain the
event state for a period of time;
c) Static information: Typically road marks and signs, where signs can be electronic
signs or static signs; the information does not change with the number of traffic
participants, OR the event message exists for a long time.
All RTS data elements are static information; the classification of each RTE data
element is as shown in Table C.1 of Appendix C.
Each RSI message can only carry one of dynamic, semi-static, static information; it
shall set the corresponding user priority and AID to send.
9.5.1.3 moy
The system shall set DE_MinuteOfTheYear, as shown in YD/T 3709-2020, using UTC
as the reference time.
The value is used to represent the total number of minutes that have elapsed (UTC time),
in the current year, with a resolution of 1 min.
To ensure the accuracy of the information transmitted, the time, which is represented
by the value of DE_MinuteOfTheYear, shall be less than vMaxPosAge (150)
milliseconds, from the UTC, at which the RSI was generated.
9.5.1.4 refpos
RSI reference coordinate point, which is used as the reference point of the point set, in
the referencePath of RTS and RTE.
The system shall set lat and lon, in refPos, to the 2D horizontal position reference.
The system shall set DE_Elevation to the elevation of its corresponding location
reference above or below the reference ellipse ("height above the reference ellipse").
9.5.1.5 rtes
Define a set of road traffic events, including at least 1 and at most 8 road traffic event
information.
Note: In the RSI message, DF_RTEList and DF_RTSList cannot be empty, at the same time.
9.5.1.6 rtss
Define a collection of road traffic signs.
It contains at least 1 road traffic sign information and a maximum of 16.
9.5.2 DF_RTEData
9.5.2.1 Description
DF_RTEData defines road traffic event information. Traffic incident classification
currently supports the national standard GB/T 29100-2012. The data frame includes the
information source, occurrence area, time limit, priority, affected area of the traffic
event. The event information can also be supplemented with description or explanation,
in the form of text.
9.5.2.2 rteid
The ID is the unique ID identification of the rte in the RSU; the receiver needs to use
...... Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|