HOME   Cart(0)   Quotation   About-Us Tax PDFs Standard-List Powered by Google www.ChineseStandard.net Database: 189759 (3 Nov 2024)

T/CSAE 159-2020 PDF in English


T/CSAE 159-2020 (T/CSAE159-2020, TCSAE 159-2020, TCSAE159-2020)
Standard IDContents [version]USDSTEP2[PDF] delivered inName of Chinese StandardStatus
T/CSAE 159-2020English1105 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.