ETSI TR 137 985 V16.2.0 (2024-01)

LTE; 5G; Overall description of Radio Access Network (RAN) aspects for Vehicle-to-everything (V2X) based on LTE and NR (3GPP TR 37.985 version 16.2.0 Release 16)

RTR/TSGR-0137985vg20

General Information

• Status: Not Published
• Technical Committee: 3GPP RAN 1 - Radio layer 1 specification
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Completion Date: 30-Jan-2024

Standards Content (Sample)

TECHNICAL REPORT
LTE;
5G;
Overall description of Radio Access Network (RAN)
aspects for Vehicle-to-everything (V2X) based on LTE and NR
(3GPP TR 37.985 version 16.2.0 Release 16)

3GPP TR 37.985 version 16.2.0 Release 16 1 ETSI TR 137 985 V16.2.0 (2024-01)

Reference
RTR/TSGR-0137985vg20
Keywords
5G,LTE
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 2 ETSI TR 137 985 V16.2.0 (2024-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under https://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 3 ETSI TR 137 985 V16.2.0 (2024-01)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 6
1 Scope . 7
2 References . 7
3 Definitions of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Services and requirements . 9
5 LTE V2X . 10
5.1 V2X sidelink physical layer . 10
5.1.1 Physical sidelink channels and signals. 10
5.1.2 Sidelink synchronization . 11
5.1.2.1 Synchronization references and priorities . 11
5.1.2.2 SLSS . 11
5.1.2.2.1 SLSSID . 12
5.1.3 Concurrent operation and carrier aggregation. 12
5.2 V2X sidelink resource allocation . 13
5.2.1 Resource pools . 13
5.2.2 Resource allocation modes . 14
5.2.2.1 Resource allocation mode 3 . 14
5.2.2.2 Resource allocation mode 4 . 15
5.2.2.2.1 Zones . 16
5.2.2.3 Modes 3 and 4 resource pool sharing . 17
5.3 Sidelink congestion control . 17
5.4 V2X sidelink higher-layer protocols . 17
5.4.1 General . 17
5.4.2 Resource pool configuration . 18
5.4.3 Measurement and reporting . 18
5.4.4 Mobility management . 18
5.4.5 Assistance information for SL SPS configuration . 18
5.4.6 Transmission carrier selection . 18
5.4.7 SL packet duplication . 18
5.4.8 Coordination between UL and V2X SL transmission . 19
5.4.9 Multi-PLMN operation . 19
5.5 V2X via the Uu interface . 19
5.6 Network aspects . 19
5.6.1 V2X service authorization . 19
5.6.2 Sidelink AMBR . 19
6 NR V2X. 20
6.1 Sidelink unicast, groupcast, and broadcast . 20
6.2 V2X sidelink physical layer . 20
6.2.1 Physical sidelink channels and signals. 20
6.2.2 Sidelink synchronization . 21
6.2.2.1 Synchronization references and priorities . 21
6.2.2.2 S-SSB and SLSS . 22
6.2.2.2.1 SLSSID . 22
6.2.3 Sidelink CSI . 23
6.2.4 Sidelink HARQ . 23
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 4 ETSI TR 137 985 V16.2.0 (2024-01)
6.2.5 In-device coexistence between LTE-V2X and NR-V2X sidelinks . 23
6.2.6 Concurrent operation . 24
6.3 V2X sidelink resource allocation . 24
6.3.1 Sidelink bandwidth parts and resource pools . 24
6.3.1.1 Sidelink bandwidth parts . 24
6.3.1.2 Resource pools . 24
6.3.2 Resource allocation modes . 25
6.3.2.1 Mode 1 . 25
6.3.2.2 Mode 2 . 25
6.4 Sidelink congestion control . 28
6.5 V2X sidelink higher-layer protocols . 28
6.5.1 General . 28
6.5.2 Measurement and reporting related to NR sidelink communication . 29
6.5.3 Mobility management for NR SL transmission/reception . 30
6.5.4 Assistance information and SL configured grant configuration . 30
6.5.5 Coordination between UL and NR SL transmission . 30
6.5.6 QoS mechanism . 30
6.5.7 Sidelink RRC . 30
6.6 V2X via the Uu interface . 31
6.7 Network aspects . 31
6.7.1 V2X service authorization . 31
6.7.2 Alternative QoS Profiles . 31
7 Multi-RAT V2X . 31
7.1 Cross-RAT operation . 31
7.2 MR-DC . 32
8 Transmission profiles . 34
9 Pedestrian UE . 34
10 Roadside unit . 35
Annex A: Change history . 36
History . 37

ETSI
3GPP TR 37.985 version 16.2.0 Release 16 5 ETSI TR 137 985 V16.2.0 (2024-01)
Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, certain modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
NOTE 1: The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not
appear in Technical Reports.
NOTE 2: The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use
is avoided insofar as possible, and they are not used in a normative context except in a direct citation from
an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or
modifying the provisions of such a referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
NOTE 3: The construction "may not" is ambiguous and is not used in normative elements. The unambiguous
constructions "might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
NOTE 4: The constructions "can" and "cannot" shall not to be used as substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 6 ETSI TR 137 985 V16.2.0 (2024-01)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
NOTE 5: The constructions "is" and "is not" do not indicate requirements.
Introduction
The 3GPP platform was first expanded to the automotive industry by the introduction of support for V2V and V2X
services in Release 14. This support forms Phase 1 of 3GPP's ongoing project relating to V2X, and was intended to
support a set of requirements sufficient for basic road safety services. Vehicles containing UEs with these features can
use the uplink, downlink and sidelink to exchange information on their own status, such as position, speed, and heading
with other nearby vehicles, infrastructure nodes, and pedestrians. Phase 2 of the V2X project was standardised in
Release 15, and adds a number of new features to the sidelink intended to enhance efficiency and exploit developments
in UE and network designs. These enhancements include sidelink carrier aggregation, higher-order modulation, and
reduced latency.
Phase 3 of V2X, in Release 16, adds support to NR (and also 5GC, not addressed in this TR) for advanced V2X use
cases, and includes introduction of the NR sidelink. The use-cases are broadly grouped to enable vehicular platooning,
exchange of extended sensor information, advanced driving, and remote driving. Phase 3 also allows either RAT's
sidelink to be operated under control of the other RAT's Uu interface, as well as permitting connection to EPC or 5GC,
to enable usage in the main MR-DC deployment scenarios.
In the following clauses, LTE-V2X is described first, then NR-V2X, and finally certain aspects which have a degree of
commonality to both RATs.
Although this TR deals with RAN aspects, note that the core network architectures also have many adaptations to
support V2X in both EPC and 5GC. These are referred to only as needed for other explanations in this TR, and details
can be found in the relevant specifications.
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 7 ETSI TR 137 985 V16.2.0 (2024-01)
1 Scope
The present document provides an overall description of the features introduced by 3GPP to LTE and NR in support of
V2X services, starting from Rel-14. The purpose of this TR is to give an overview across the RAN specifications of
how the features have been designed, and how they operate together. This document addresses LTE V2X and NR V2X
via both sidelink, i.e. the PC5 interfaces, and via the cellular uplink/downlink, i.e. the Uu interfaces. It covers V2V,
V2I/N, and V2P, as well as the eNB/gNB, UE, and RSU nodes. The intention is to provide descriptions at
approximately the Stage 2 level of detail, and thus references are provided to RAN specifications for the reader to
obtain precise details.
The document is a 'living' document, i.e. it is permanently updated and presented to TSG-RAN meetings.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TR 36.885: "Study on LTE-based V2X Services".
[3] ETSI EN 302 637-2: "Specification of Cooperative Awareness Basic Service".
[4] SAE J2735: "Dedicated Short Range Communications (DSRC) Message Set Dictionary".
[5] ETSI EN 302 637-3 "Specifications of Decentralized Environmental Notification Basic Service".
[6] 3GPP TS 22.185: "Service requirements for V2X services".
[7] 3GPP TS 22.186: "Enhancement of 3GPP support for V2X scenarios".
[8] 3GPP TS 36.211: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and
modulation".
[9] 3GPP TS 36.212: "Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and
channel coding".
[10] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC)".
[11] 3GPP TS 36.101: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE)
radio transmission and reception".
[12] 3GPP TS 36.214: "Evolved Universal Terrestrial Radio Access (E-UTRA); Measurements".
[13] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[14] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC)".
[15] 3GPP TS 36.323: "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
Convergence Protocol (PDCP)".
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 8 ETSI TR 137 985 V16.2.0 (2024-01)
[16] 3GPP TS 38.211: "NR; Physical channels and modulation".
[17] 3GPP TS 38.331: "NR; Radio Resource Control (RRC) protocol specification".
[18] 3GPP TS 38.213: "NR; Physical layer procedures for control".
[19] 3GPP TS 37.340: "Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-
connectivity; Stage 2".
[20] 3GPP TS 38.300: "NR; NR and NG-RAN Overall Description; Stage 2".
[21] 3GPP TS 38.321: "NR; Medium Access Control (MAC) protocol specification".
[22] 3GPP TS 38.101-1: "NR; User Equipment (UE) radio transmission and reception; Part 1: Range 1
Standalone".
3 Definitions of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in TR 21.905 [1] and the following apply. A term defined in
the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
example: text used to clarify abstract rules by applying them literally.
3.2 Symbols
For the purposes of the present document, the following symbols apply:

3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
Where the same abbreviation is used for LTE V2X and NR V2X, which is meant can be derived from the clause within
which it appears, unless otherwise stated.
5GC Fifth Generation core network
AGC Automatic gain control
AMBR Aggregate maximum bit rate
BSM Basic safety message
BWP Bandwidth part
CA Carrier aggregation
CAM Cooperative awareness message
CBR Channel busy ratio
CR Channel usage ratio
DENM Decentralized environmental notification message
DMRS Demodulation reference signal
EPC Evolved packet core
MBSFN Multicast-broadcast single-frequency network
MNO Mobile network operator
PPPP ProSe per-packet priority
PPPR ProSe per-packet reliability
PSBCH Physical sidelink broadcast channel
PSCCH Physical sidelink control channel
PSSCH Physical sidelink shared channel
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 9 ETSI TR 137 985 V16.2.0 (2024-01)
PSSS, S-PSS Primary sidelink synchronization signal (LTE), sidelink primary synchronization signal (NR)
PT-RS Phase-tracking reference signal
P-UE Pedestrian UE
RSU Roadside unit
SA Scheduling assignment
SCI Sidelink control information
SC-PTM Single-cell point-to-multipoint
SL-BCH Sidelink broadcast channel
SLSS Sidelink synchronization signal
S-RSSI Sidelink received signal strength indicator
S-SSB Sidelink synchronization signal block
SSSS, S-SSS Secondary sidelink synchronization signal (LTE), sidelink secondary synchronization signal (NR)
V2I Vehicle-to-infrastructure
V2P Vehicle-to-pedestrian
V2V Vehicle-to-vehicle
V2X Vehicle-to-everything
4 Services and requirements
LTE-V2X is designed with BSM, CAM, and DENM particularly in mind. BSMs and CAMs have the characteristic of
generating periodic messages at intervals, whereas DENMs are event-triggered. As an illustration of the different
message types, in TR 36.885 [2], BSM/CAM were modelled, for evaluation purposes, as periodically occurring sets of
one 300-byte message followed by four 190-byte messages. These types of message regularly broadcast information
such as the vehicle's heading, speed, latitude/longitude, etc. ETSI EN 302 637-2 [3], SAE J2735 [4]. In TR 36.885 [2],
DENMs were modelled, for evaluation purposes, as Poisson distributed initiations of six 800-byte messages spaced by
100 ms. DENMs can contain various different messages depending on the cause for their transmission, such as
imminent collision, sudden braking, or detection of a traffic jam, amongst others ETSI EN 302 637-3 [5]. The
requirements relating to traffic size and pattern for LTE-V2X set in TS 22.185 [6] can be summarized as follows,
although they do not limit the usage of LTE-V2X. Other requirements relating to general system function are also
included in TS 22.185 [6].
- Support for periodic broadcast messages with payloads of 50-300 bytes.
- Support for event-triggered messages with payloads of up to 1200 bytes.
- Up to 10 messages per second transmitted by a UE.
- V2V and V2P latency of maximum 100 ms, or for V2V pre-crash sensing, maximum 20 ms.
- V2I latency, i.e. between a UE and RSU, of maximum 100 ms.
- V2N latency, i.e. when transferring messages via the cellular network, of maximum 1000 ms.
- Maximum relative velocity between two vehicles of 500 km/h, and maximum absolute velocity of 250 km/h for
V2V and V2P UEs, and of a UE communicating with an RSU.
- Requirements relating to security, integrity, authorization, and privacy.
NR V2X is designed with a broader set of more advanced V2X use cases in mind. These were specified in TS 22.18 [7],
and are broadly arranged into four use case groups: vehicular platooning, extended sensors, advanced driving, and
remote driving.
1) Vehicles Platooning enables the vehicles to dynamically form a platoon travelling together. All the vehicles in
the platoon obtain information from the leading vehicle to manage this platoon. These information allow the
vehicles to drive closer than normal in a coordinated manner, going to the same direction and travelling together.
2) Extended Sensors enables the exchange of raw or processed data gathered through local sensors or live video
images among vehicles, road site units, devices of pedestrian and V2X application servers. The vehicles can
increase the perception of their environment beyond of what their own sensors can detect and have a more broad
and holistic view of the local situation. High data rate is one of the key characteristics.
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 10 ETSI TR 137 985 V16.2.0 (2024-01)
3) Advanced Driving enables semi-automated or full-automated driving. Each vehicle and/or RSU shares its own
perception data obtained from its local sensors with vehicles in proximity and that allows vehicles to synchronize
and coordinate their trajectories or manoeuvres. Each vehicle shares its driving intention with vehicles in
proximity too.
4) Remote Driving enables a remote driver or a V2X application to operate a remote vehicle for those passengers
who cannot drive by themselves or remote vehicles located in dangerous environments. For a case where
variation is limited and routes are predictable, such as public transportation, driving based on cloud computing
can be used. High reliability and low latency are the main requirements.
The most demanding requirements set in TS 22.186 [7] are for a maximum sidelink range of 1000 m, a maximum
throughput of 1 Gbps, a shortest latency of 3 ms, a maximum reliability of 99.999%, and a maximum transmission rate
of 100 messages/second. However, there is not a use case which, on its own, demands all of these bounding
requirements. The communication scenarios described in TS 22.186 [7] include a mixture of periodic and aperiodic
services. Similar to LTE-V2X, there are also requirements relating to security, integrity, authorization, and privacy.
5 LTE V2X
5.1 V2X sidelink physical layer
The LTE V2X sidelink supports broadcast transmission of messages in the physical layer, since this is a suitable
approach for delivery BSM, CAM, DENM and similar traffic. In the MAC layer, a broadcast address can be mapped to
a single UE or a group of UEs by implementation. Such implementation techniques have no particular specification
support in LTE, and are transparent to the physical layer.
5.1.1 Physical sidelink channels and signals
The LTE V2X sidelink uses the following physical channels and signals:
- Physical sidelink broadcast channel (PSBCH), specified in TS 36.211 [8, clause 9.6]
- Physical sidelink control channel (PSCCH), specified in TS 36.211 [8, clause 9.4]
- Physical sidelink shared channel (PSSCH), specified in TS 36.211 [8, clause 9.3]
- Primary and secondary sidelink synchronization signals (PSSS and SSSS) specified in TS 36.211 [8, clause 9.7].
These can be referred to jointly as the sidelink synchronization signal (SLSS).
- A demodulation reference signal (DMRS) associated with each of the three physical channels, specified in
TS 36.211 [8, clause 9.8]
LTE-V2X sidelink physical channels are transmitted using SC-FDMA.
PSBCH transmits the SL-BCH transport channel, which carries the sidelink V2X Master Information Block (MIB-
V2X) from the RRC layer. When in use, PSBCH transmits MIB-V2X every 160 ms in the central 72 subcarriers of the
SL bandwidth. DMRS associated with PSBCH are transmitted in the 5th, 7th, and 10th symbols of the subframe.
PSSS and SSSS are transmitted to allow other UEs to achieve sidelink synchronization when they do not have another
source of synchronization available. They jointly convey the SLSS ID selected by the UE. For further details of SLSS
and synchronization, refer to Clause 5.1.2. PSSS/SSSS also allow UEs to detect the sidelink subframe boundary, with
subframe number and frame number signalled in MIB-V2X.
PSSCH transmits the SL-SCH transport channel, which carries the TBs of data for transmission over SL. The resources
in which PSSCH is transmitted can either be scheduled by an eNB and granted to the UE by a DCI (termed resource
allocation mode 3, see Clause 5.2.2.1) or determined through a sensing procedure conducted autonomously by the
transmitting UE (termed resource allocation mode 4, see Clause 5.2.2.2). A given TB can be transmitted once or twice,
with a second transmission occurring a time gap after the first which is indicated in the scheduling SCI.
PSCCH transmits physical layer sidelink control information (SCI), also known as a scheduling assignment (SA). For
V2X, PSCCH is transmitted in two frequency-adjacent PRBs, and always carries SCI format 1, defined in TS 36.212 [9,
clause 5.4.3.1.2]. To receive PSCCH, a UE has to monitor each defined pair of PRBs to determine whether PSCCH has
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 11 ETSI TR 137 985 V16.2.0 (2024-01)
been transmitted in them. PSCCH is transmitted in the same subframe(s) as the associated PSSCH, and can be
transmitted in PRBs that are either frequency adjacent or frequency non-adjacent to the PSSCH.
DMRS associated with PSSCH and PSCCH are transmitted in the 3rd, 6th, 9th, and 12th symbols of a subframe.
5.1.2 Sidelink synchronization
5.1.2.1 Synchronization references and priorities
There are four basic sources, or references, from which a V2X UE can derive its own synchronization: GNSS, its
serving eNB, another UE transmitting SLSS (a SyncRef UE), or its own internal clock. In general, GNSS or eNB are
regarded as the highest-quality sources. SyncRef UEs are distinguished between those which are directly synchronized
to GNSS or an eNB, those which are 1 further step away, and those which are ≥ 2 further steps away from GNSS/eNB.
As a last resort, a UE unable to find any other synchronization reference will use its own internal clock to transmit
SLSS. The V2X synchronization procedure defines a hierarchy or set of priorities among such synchronization
references and requires all UEs to continuously search the hierarchy to get to the highest-quality one they can find. The
general preference order is as follows, with details specified in TS 36.331 [10, clause 5.10.8]:
Level 1. Either GNSS or eNB, according to (pre-)configuration.
Level 2. A SyncRef UE directly synchronized to a Level 1 source.
Level 3. A SyncRef UE synchronized to a Level 2 source, i.e. indirectly synchronized to a Level 1 source.
- When the Level 1 preference is (pre-)configured as GNSS, in Level 2 and 3, SyncRef UEs in hierarchies
derived from GNSS and eNB are of equal preference as a synchronization source.
Level 4. Any other SyncRef UE.
Level 5. UE's internal clock.
Within a Level 2, or 3, or 4 set of SyncRef UEs, the one with the highest S-RSRP is selected. The hierarchy also allows
fallback between eNB-derived and GNSS-derived chains should the Level 1 type chosen by (pre-)configuration be
unsuitable.
5.1.2.2 SLSS
The transmission and reception of SLSS (and PSBCH) is an optional V2X UE capability, and they can be transmitted
on one or multiple synchronization carriers.
A UE which is deriving its own synchronization from eNB or GNSS can be configured by the network to transmit
SLSS on a synchronization carrier, or the network can permit it to do so if the RSRP of a reference cell falls below a
threshold. If the network is not available, and the UE is synchronized to GNSS, it will transmit SLSS if permitted by its
pre-configuration. When such a UE does not have GNSS synchronization, it will transmit SLSS, if permitted by its pre-
configuration, while it cannot find a SyncRef UE with sufficiently high S-RSRP. Full details of the conditions for SLSS
transmission are specified in TS 36.331 [10, clause 5.10.7.2].
In a V2X system, there can be a variety of UEs which are deriving synchronization from different sources, and since a
UE can transmit SLSS on multiple carriers, it can have different synchronization sources among them. SLSS is
therefore transmitted in different subframes depending on what synchronization source the UE is using. The system can
be configured with either two or three different offsets with respect to the start of the 160 ms PSBCH period can be
defined, which can allow different subframes for transmission according to whether the UE is synchronized to GNSS,
eNB, or another SyncRef UE.
PSSS and SSSS use the same sequences as PSS and SSS, respectively, with different root indices. When in use, both
sequences are transmitted in the central 62 subcarriers of the SL bandwidth, in the same subframe as PSBCH, i.e. every
160 ms. PSSS is in the 2nd and 3rd symbols of the subframe, and SSSS in the 12th and 13th symbols. The two symbols
of each signal are the same, which allows detectors to benefit from phase tracking between the two symbols. Figure
5.1.2.1-1 shows the relevant contents of a subframe which contain PSBCH, PSSS, and SSSS.
ETSI
3GPP TR 37.985 version 16.2.0 Release 16 12 ETSI TR 137 985 V16.2.0 (2024-01)

Figure 5.1.2.2-1: Contents of an LTE-V2X synchronization subframe.
5.1.2.2.1 SLSSID
The SLSSID itself conveys information about the synchronization source of the transmitting UE. In general, the further
a UE is away from a high-quality source of GNSS or eNB, the lower quality will be its own synchronization and thus
the quality of an SLSS it transmits. There are a series of association rules among SLSS IDs, designed to allow the
identification, and propagation through the system of, high-quality synchronization sources. Thus, for example, a UE
which is in-coverage and directly synchronized to an eNB (a Level 2 SyncRef UE) uses an SLSSID which is configured
by the network from 1-167, allowing SLSSID planning, and a UE using such a UE as a SyncRef UE (a Level 3 SyncRef
UE) uses the same SLSSID, but indicates in V2X MIB that it is not directly eNB-synchronized. Subsequent UEs in this
example hierarchy (Level 4 SyncRef UEs) use the SLSSID+168 to indicate their source is not directly synchronized to
an eNB. A similar propagation hierarchy is used starting with a UE which is directly synchronized to GNSS, whose
SLSSID is always 0, resulting in any UE which is more than one further step from GNSS using SLSSID 168 (or, in
some cases, 169) so that a synchronization hierarchy based on GNSS can always be identified. Finally, a UE which
cannot find GNSS, eNB, nor a SyncRef UE, selects an SLSSID randomly from 170-335, and UEs which synchronize to
it propagate the same SLSSID.
5.1.3 Concurrent operation and carrier aggregation
V2X operation is defined in band 47 in TS 36.101 [11, clause 5.5G], which supports single-carrier and multi-carrier
operation:
Table 5.1.3-1: V2X operating band
E-UTRA V2X UE transmit V2X UE receive Duplex Interface
E-UTRA
V2X Mode
Operating
Operating F  – F F – F
UL_low UL_high DL_low DL_high
Band
Band
5855 5925 5855 5925 HD PC5
47 47
MHz MHz MHz MHz
The V2X sidelink in band 47 can be operated concurrently with Uu FDD bands 3, 5, 7, 8, 20, 28, and Uu TDD bands
34, 39, 41, and 71.
Sidelink CA is defined for resource allocation modes 3 and 4. When operating in CA, a given (sidelink) MAC PDU is
transmitted, and if necessary re-transmitted, on a single sidelink carrier, and multiple MAC PDUs can be transmitted in
parallel on different carriers. This provides a throughput gain in a similar way as for Uu CA.
S
...