©rohde & schwarz; introduction to the vehicle-to …...rohde & schwarz white paper |...

Whi

te p

aper

| Ve

rsio

n 01

.00

Introduction to the vehicle-to-everything communications service V2X feature in 3GPP release 14White paper

22

Engineers and scientists are seeking processes and technologies to enhance the traffic flow and safety through sophisticated traffic management. Technological progress in the automotive industry towards automated driving and development of advanced driver-assistance systems are propelling a fully digital transportation system.The cooperative intelligent transportation system, a transportation system where all road users, including pedestrians, interact with each other wirelessly, promises to increase efficiency even further and to additionally reduce road traffic fatalities and serious injuries. 3GPP Long Term Evolution, in release 14, introduces and specifies the vehicle-to-everything communications service. This feature sets the starting point for the evolution of applications that up to now have not been provided by mobile communications technology and paves the way for ubiquitous connectivity in the automotive domain. After a brief overview, this paper introduces the V2X feature in release 14 in some detail, and provides hints for more in-depth reading in the References section. A link to the complementary paper on the earlier IEEE 802.11p based intelligent transportation system may also be found there.

Table of contents1 Introduction ............................................................................................................3

2 C-ITS use cases and applications ........................................................................32.1 Road safety2.2 Traffic efficiency2.3 Others2.4 Technical requirements

3 System architecture...............................................................................................5

4 LTE V2X protocol stack for out-of-coverage communications .........................94.1 User plane 4.2 Control plane 4.3 Communications channels

5 Synchronization in out-of-coverage V2X scenarios ........................................125.1 Synchronization source5.2 Synchronization signals and information

6 Physical resources and resource assignment ................................................146.1 Resource pool (RP)6.2 Subchannels6.3 Resource assignment6.4 Slot structure

7 Medium access control (MAC) layer ................................................................207.1 Semi-persistent scheduling (SPS)7.2 Candidate single subframe resource 7.3 Subchannel allocation7.4 The zone concept

9 Abbreviations ........................................................................................................24

10 References ..........................................................................................................26

Rohde & Schwarz White paper | Introduction to the vehicle-to-everything communications service V2X feature in 3GPP release 14 3

One pillar of modern society is mobility. Conveyance of goods and passengers is essential for a prospering economy. The growing affluence in many developing as well as indus-trialized countries is becoming apparent through the increase in individual mobility. The increase in the efficiency of transportation systems achieved through conventional road building often reaches its limits in terms of land consumption and lack of public accep-tance. Engineers and scientists are seeking processes and technologies to enhance traf-fic flow through sophisticated traffic management. The expectation with the established system, commonly known as the intelligent transportation system (ITS), is to avoid traffic congestion and increase overall traffic efficiency. End-to-end digitization, starting from the single vehicle through all elements of the transportation system from road infrastructure to backend server, provides the general basis for continuous control and management of traffic flow. Technological progress in the automotive industry towards automated driv-ing and development of advanced driver-assistance systems (ADAS) is propelling the fully digital transportation system. Cooperative-ITS (C-ITS), a transportation system in which all road users, including pedestrians, cooperate with each other, promises to increase ef-ficiency even further and additionally reduce road traffic fatalities and serious injuries. Re-ducing the severity of injuries in road traffic accidents is an ambitious intention declared by several government agencies around the globe. A mobile communications system is required that supports the reliable exchange of road traffic related data even in scenarios where road users are traveling at high speed. 3GPP Long Term Evolution (LTE) specifies in release 14 the vehicle-to-everything (V2X) communications service. This feature sets the starting point for the evolution of applications not previously supported by mobile com-munications technology and paves the way for ubiquitous and future-proof connectivity in the automotive domain.

2 C-ITS use cases and applicationsThe 3GPP technical specification group (TSG) responsible for service and system aspects (SA) conducted a study to identify and develop use cases and to derive technical require-ments [1]. These technical requirements for LTE to support V2X services were consoli-dated afterwards as part of the stage 1 normative work. The study refers to external stan-dardization organizations (SDO) such as the European Telecommunications Standards Institute (ETSI) and Society of Automotive Engineers (SAE), which confirms the substan-tial work already done for C-ITS in the last decade. The 3GPP TSG SA work group (WG) 1 follows the definition of ETSI to distinguish three classes of applications: ❙ Road safety: applications that focus on mitigating and avoiding road traffic accidents. Use cases with the objective to reduce the risk of serious injuries are covered

❙ Traffic efficiency: applications to avoid traffic congestion as well as traffic jams and to generally increase the traffic flow rate

❙ Other: applications related to the driver’s convenience, additional services associated with travel and all remaining aspects of automotive topics

The intention of the study is not to provide an exhaustive definition of C-ITS applications, since this has been accomplished by many other SDOs [2] and is not within the scope of 3GPP; instead, the purpose is to determine prominent use cases that impose new techni-cal requirements on LTE communications services. Twenty-seven use cases are specified in the referenced document [1]; a few are selected and described in Tables 2-1, 2-2 and 2-3.

2.1 Road safetyUse cases related to road safety, as opposed to non-safety, have in common the need for higher communications service availability, higher transmission reliability and lower laten-cy. Information about road traffic incidents has to be delivered successfully to the driver at the proper time, leaving ample time to react.

1 Introduction

4

Table 2-1: Road safety use cases [1]Use case Description

Forward collision warning Information on velocity, direction and location, periodically sent to avoid rear-end collision

Emergency vehicle warning An emergency vehicle (e.g. ambulance) requests other vehicles to clear the way

Emergency stop Vehicle sends information that it is not moving any longer

Queue Warning Vehicles send information about traffic jams and traffic congestion

Road safety service Vehicles are informed about general road traffic situations by mobile network infrastructure

Wrong way driver warning Vehicles are informed about wrong way drivers

Precrash sensing warning Vehicle informs other vehicles about an unavoidable road traffic accident and warns them to prepare for a collision

Curve speed warning Mobile network infrastructure exchanges information to give speed advisory

Vulnerable road user (VRU) safety

Vulnerable road users are informed about potential risk of collision with vehicles

2.2 Traffic efficiencyThis class of use cases refers typically to reducing the amount of pollution and saving fuel. The technical requirements for the communications service in terms of reliability and delay are less demanding as compared with traffic safety relevant applications.

Table 2-2: Traffic efficiency use cases [1]Use case Description

Cooperative adaptive cruise control

Vehicles temporarily establish groups and perform longitudinal and lateral control corrections to keep vehicles centered in the lane and to follow each other

Traffic flow optimization Vehicles periodically send travel-related information, mobile network infra-structure receives information and gives recommendation to vehicles about velocity e.g. with objective to increase traffic flow (at intersections). Green light optimal speed advisory (GLOSA) is an example of an application based on this use case

2.3 OthersThis class of use cases provides a placeholder for a nearly unlimited selection of applica-tions related to the vehicle in some way. In essence, many of the conceivable use cases are operated nowadays with a standardized mobile communications system.

Table 2-3: Other use cases [1]Use case Description

Automated parking Vehicles request realtime information on parking spaces, make reservations, are guided to a parking lots and make electronic payments

Enhancing positional precision for traffic participants

Mobile communications networks used to increase position accuracy to the range of centimeters

Remote diagnosis and just-in-time repair notification

Information exchange between vehicle and service station for purpose of monitoring and repair notification

2.4 Technical requirementsMobility is the common attribute in road traffic scenarios. The number of road users in close proximity varies over time. Their relative position to one another changes likewise, while the absolute as well as the relative speed differs between road users. Mobility makes it necessary to update information regularly and to analyze the traffic situation continuously. Exceptional situations such as road traffic incidents may cause travel delays and pose a risk to other road users. Detecting these incidents and informing road users are preliminary steps to keep the traffic flow stable. Once detected, information about the


road incident is strictly time- and location-dependent. A distinctive feature of C-ITS appli-cations is therefore the overlay of: ❙ event-based data transmissions with ❙ recurring and permanent periodic data transmissions

Event-based data transmissions address temporary hazardous road situations, while per-manent transmissions provide the usual route and vehicle status updates. The C-ITS facil-ity layer [3], for instance of the European C-ITS standard, known as ITS-G5 [4], specifies two application message types reflecting this general feature 1): ❙ Cooperative awareness message (CAM) [5] ❙ Decentralized environment notification message (DENM) [6]

The repetition frequency of C-ITS application messages depends on the importance of the information content 2) carried. One critical goal of C-ITS is to prevent any single point of failure from a system design perspective. At least a basic set of applications must be operated without any centralized mobile communications infrastructure. 3GPP TSG SA WG1 identifies 33 requirements [7]. An explanation of some of the requirements is sub-sequently provided. The user equipment (UE) is given greater autonomy in terms of e.g. message prioritization, transmission rate and transmission range 3). It emphasizes the need for V2X communications to become at least partially independent of the central-ized mobile network control. The mobile communications system must be able to operate V2X communications in coverage as well as out of coverage. Information shall be dis-tributed in a resource efficient way because it is relevant to multiple users as opposed to just a single user. The end-to-end latency is measured from one UE to the other UE and is specified in the range from 20 ms to 100 ms. It corresponds to the requirements imposed by C-ITS technical specifications from other SDOs. The application layer, if a message is not decoded successfully at the receiver, does not perform any message retransmis-sion. Retransmissions following the standard automatic repeat request (ARQ) protocol are subject to error detection and require feedback messages, which might undermine V2X latency and efficiency requirements. The V2X message size is in the range from 50 bytes to 300 bytes in case of periodic transmissions with a limit of 1200 bytes for event-based information exchange. The supported message repetition frequency is maximum 10 Hz. The system is able to operate the V2X communications service in scenarios with speeds of 250 km/h absolute and 500 km/h relative.

3 System architectureThe V2X system reference architecture design [8] refers to the system model specified for 3GPP proximity-based services (ProSe) [9]. New standardized interfaces, reference points and functions supplement the previous architecture to offer UEs communications services to carry user data from the V2X application and V2X application server. The 3GPP LTE V2X specification is strongly motivated by the assumption that V2X applications are at least in part replicated from the existing C-ITS dedicated short-range communications (DSRC), WAVE [10] and ITS-G5 [11]. It implies that security and privacy services are sup-ported according to non-3GPP C-ITS specifications. Furthermore, 3GPP LTE V2X is able to carry IP data traffic as well as other data traffic. The V2X application server is envisioned to provide a variety of applications such as a delay-tolerant route guiding service with in-formation about the road traffic situation and weather conditions. The information offered may be relevant only to users traveling through a certain geographic area. Road authori-ties, mobile network operators, government bodies and third parties such as automotive

1) Unlike separate CAM and DENM specified in EU ITS-G5, the US ITS standard, i.e. wireless access in vehicular environments (WAVE), specifies the basic safety message (BSM) carrying both event-based messages as well as regular status updates.

2) C-ITS application standards allow for reduction of the repetition frequency depending on the data traffic load in the network to avoid network saturation.

3) 3GPP TSG SA WG1: “A UE supporting V2X application shall be able to transmit and receive messages when served or not served by E-UTRAN supporting V2X communications”.

V2V V2N

V2IV2P

Pedestrian RSU

Application server

Vehicle

Vehicle

6

companies may have an interest in operating a V2X application server in order to maintain value added services. Use cases related to road safety are supported by a V2X application server if the established mobile network system deploys localized routing through e.g. lo-cal gateways (L-GW) to reduce end-to-end latency.

Four types of communications services are defined as shown in Fig. 3-1 [7]: ❙ Vehicle-to-vehicle (V2V): both peers are UEs integrated in vehicles ❙ Vehicle-to-pedestrian (V2P): one peer is a UE integrated in a vehicle, the other peer is a UE used by an individual. This service type covers use cases where an individual legacy UE might also be used by a driver or a passenger in the vehicle, or by cyclists, motorcyclists and pedestrians

❙ Vehicle-to-infrastructure (V2I): one peer is a UE integrated in a vehicle, the other peer is stationary infrastructure known as a road side unit (RSU)

❙ Vehicle-to-network (V2N): one peer is a UE integrated in a vehicle, the other peer is an application server

Fig. 3-1: Standard LTE V2X communications services defined in [7]

The V2X communications service exploits two interfaces: ❙ PC5 for evolved universal terrestrial radio access (E-UTRA) direct V2V, V2I, V2P ❙ Uu for evolved universal terrestrial radio access network (E-UTRAN) to operate wide-range communications V2I and V2N

Reference documents distinguish direct ad hoc from indirect V2X communications 4) to emphasize the 3GPP mobile network system’s capability to deliver messages from a ve-hicle to another vehicle either on a direct path, exploiting the service provided by PC5, or through core network infrastructure related services provided by the Uu reference point. The latter option is then known as V2N2V.

3GPP TSG SA WG2 [8] adopts the C-ITS concept of road side units (RSU) [12], which is an implementation option rather than a new network entity. RSUs are known from non-3GPP-based C-ITS systems such as WAVE and ITS-G5. What these two systems have in common is that they are not familiar with the concept of base stations and centralized co-ordinated channel access. In non-3GPP C-ITS standards, an RSU is a stationary infrastruc-ture entity that is able to receive and send C-ITS messages, providing communications services related to wireless relaying, which means to span a multi-hop network where the message traverses from one user to another via intermediate network nodes and addi-tional routing services to backend systems. Although from a functional perspective this is not strictly needed, 3GPP adopts this RSU concept without support of relaying to adhere to similar architectural terminology and to serve the C-ITS stakeholder requirement.

4) 3GPP does not introduce this definition.


Two types of RSUs are defined: ❙ Evolved NodeB (eNB)-type RSU: stationary infrastructure providing V2X message transmission to UEs through the Uu reference point. This type of RSU can be physically collocated with a common eNB

❙ UE-type RSU: stationary infrastructure providing V2X message transmission to UEs through the PC5 reference point. This type of UE can also be connected through the Uu reference point to an eNB or have access to wide area networks through an implemented SGi interface

Before the UE is allowed to invoke the V2X communications service, configuration and authorization are needed. Parameter values are either preconfigured in the mobile equip-ment (ME), configured in the universal subscriber identity module (USIM) or provided by the V2X control function of the home public land mobile network (HPLMN) when as-signed to the network. These three configuration options, where precedence is given in the inverse order, ensure that V2X communications is possible even without any valid public land mobile network (PLMN) subscription. Then, the operated V2X applications might be limited to the basic set of road safety services. Parameter values provided to the UE for service configuration cover: ❙ Information on PLMNs where the UE is authorized to operate V2X communications ❙ PC5 radio related information, valid in specific geographical regions ❙ Destination addresses to identify the V2X application server and the V2X control function

❙ Expiration timer ❙ Additional information regarding ProSe per-packet priority (PPPP) and packet delay budget 5)

The source layer 2 identifier (ID) and source IP address of a UE are changed to a random number if the corresponding expiration timer has elapsed. Re-assignment of the address identifier is intended to protect user privacy and prevent tracking.

The reference system architecture shown in Fig. 3-2 assumes UEs are subscribed to their HPLMN and relates to the nonroaming scenario introduced in [8].

5) V2X messages carry information of varying importance. Message prioritization is achieved through the ProSe per-packet priority (PPPP) [25]. The application assigns one value out of eight to the packet data unit (PDU) for the purpose of prioritization. The instruction to translate the packet delay budget (PDB) to PPPP is provided to the UE as part of the V2X communications service configuration.

V2Xapplication

V2Xapplicationserver

V2Xapplication

V2Xapplication

V2Xapplication

V5

V5

V1

UE C(pedestrian)

UE B(vehicle)

UE A(vehicle)

UE D(stationary)

V5 PC5

PC5

PC5LTE-Uu

LTE-Uu

V3

V3

V2 SGi

V2X controlfunction

S/P-GWS6aV4

HSS

V3V3 S1

MME

E-UTRAN

8

Fig. 3-2: Nonroaming reference system architecture standardized in [8]

Reference points V1 and V5 between V2X applications and the V2X application server are out of scope and therefore not defined in the 3GPP architecture specification. V2 is the reference point where the V2X application server is connected to the mobile network operator. The V2X application server provides its address information to the network through services this reference point offers, then known to the network and further adver-tised to the UEs through the V3 reference point as part of the common configuration. The V2X control function located in the HPLMN is at all times the entity that grants permis-sion to use the V2X communications service. It uses the home subscriber server (HSS) in the first instance through the V4 reference point to obtain general information about the UE subscription. While roaming in the visited public land mobile network (VPLMN), a scenario not covered in Fig. 3-2, reference point V6 allows the V2X control function of the HPLMN to request V2X permission rights in the VPLMN. The stationary UE D represents the UE-type RSU that exploits communications services provided at the LTE-Uu refer-ence point while at the same time being connected through the PC5 interface to further UEs. The distinguishing feature between a V2X capable UE and an RSU is mobility, which is obvious from Fig. 3-3 [8]. The eNB-type RSU is introduced in Fig. 3-4, where localized routing is performed through the L-GW to offer V2X services operated by the V2X appli-cation server.

V2X application

UE B (stationary)

RSU

UE A (vehicle)

V2X application

PC5

V5

L-GW

RSU

UE A (vehicle)

V2X application

LTE-Uu

V1 V2X applicationserver

eNB

UE A UE BPC5-U

Application

IP, ARP, Non-IP

PDCP

RLC

MAC

PHY

Application

IP, ARP, Non-IP

PDCP

RLC

MAC

PHY


Fig. 3-3: Stationary UE-type road side unit (RSU) offering the V2X communica-tions service through the PC5 interface [8]

Fig. 3-4: Stationary eNB-type road side unit (RSU) with local gateway (L-GW) to offer V2X services requiring lower delay packet transmission [8]

The following sections focus solely on V2X communications aspects that concern PC5 operation assuming out-of-coverage scenarios. The data source and destination are UEs, meaning that logical connections terminate on both endpoints in UEs. The protocol stack related to the user plane (UPL) of the V2X communications through interface PC5 is shown in Fig. 4-1.

Fig. 4-1: Communications protocol stack related to the user plane (UPL) [13]

Additionally, Fig. 4-2 refers to the control plane (CPL) communications protocol stack.

4 LTE V2X protocol stack for out-of-coverage communications

PC5 signaling protocol


PDCP

RLC

MAC

PHY


PDCP

RLC

MAC

PHY

UE A UE B

10

Fig. 4-2: Communications protocol stack related to the control plane (CPL) [13]

Both protocol stacks are derived from feature [13] of the ProSe standard, release 12, and then adapted to meet the specific V2X requirements in release 14 [14].

In general, each protocol layer offers specific services to the preceding protocol layer. Service data units (SDU) are processed, layer-specific protocol control information (PCI) is added and the resulting protocol data unit (PDU) is delivered to the following protocol layer.

4.1 User plane 4.1.1 Physical layer (PHY)The PHY layer [15] handles e.g. signal processing, data modulation and demodulation, applies adaptive channel coding to the data in the process of transmission, adjusts the output power, adapts the radio frequency and performs time synchronization [15]. Data is transmitted on physical sidelink channels. V2X communications, in terms of out-of-coverage operation, exploits a 10 MHz or 20 MHz frequency bandwidth at 5.9 GHz in ra-dio frequency band 47. Regulation bodies in some countries, e.g. in Europe and the USA, permit license-exempt C-ITS communications in the 5.9 GHz frequency spectrum. Access permission to this frequency spectrum is limited in some cases to one specific technol-ogy. In the USA, for instance, only DSRC is permitted.

4.1.2 Medium access control (MAC) sublayerThe MAC sublayer [16] operates the hybrid automatic repeat request (HARQ) protocol, performs packet scheduling and resource selection with regard to packet prioritization, and applies packet filtering to further process PDUs intended for this particular UE. SDUs are multiplexed to the transport channels as well as demultiplexed when operating data reception (RX).

4.1.3 Radio link control (RLC) sublayer The RLC sublayer [17] takes care of in-sequence delivery of SDUs and offers SDU seg-mentation and reassembly protocol services in addition to SDU concatenation. Service from the ARQ protocol, usually provided by the RLC sublayer to the preceding sublayer, is not supported in the case of V2X communications. Data is transmitted on logical channels.

4.1.4 Packet data convergence protocol (PDCP) sublayerThe PDCP sublayer [18] separates communications protocol layers related to non-3GPP applications from the ones offering the standard 3GPP data transmission service. It offers header compression and provides an application protocol specific transmission service. The PDCP sublayer has supported transmission of non-IP data since release 14, which in particular is important for operating C-ITS applications.


4.2 Control plane The communications protocol stack specified for the CPL differs from UPL in the radio re-source control (RRC) sublayer. The protocol service offered from the PDCP sublayer is not required for control data transmission.

4.2.1 Radio resource control (RRC) sublayer The RRC sublayer [19] offers the broadcast communications service. Specified RRC mes-sages carry system information to manage communications, configure protocol services and adapt the radio parameters to the specific requirements.

4.3 Communications channels4.3.1 Logical channelsThe following two logical channels are provided by the MAC to the RLC sublayer for V2X communications [17]: ❙ Sidelink broadcast control channel (SBCCH) to carry CPL-related messages ❙ Sidelink traffic channel (STCH) to carry UPL-related messages

4.3.2 Transport channelsThe SBCCH and STCH are mapped to the subsequently defined point-to-multipoint trans-port channels provided by the PHY layer [15] [20]: ❙ Sidelink broadcast channel (SL-BCH) to carry higher layer control data ❙ Sidelink shared channel (SL-SCH) to carry user data

Transmissions on these transport channels may experience high interference power from parallel data transmission by nearby UEs when using autonomous resource selection, which is known as transmission mode 4 (TM4). SL-SCH only supports HARQ soft-com-bining with a maximum of one retransmission. HARQ is not applied to data carried on SL-BCH.

4.3.3 Physical channelsThe transport channels are then mapped to physical channels on the PHY layer [15] [20]: ❙ Physical sidelink broadcast channel (PSBCH) to carry higher layer control data ❙ Physical sidelink shared channel (PSSCH) to carry user data

Control information to announce the time and frequency physical resource allocation is transmitted on the following channel: ❙ Physical sidelink control channel (PSCCH)

The transmission service to carry data on physical sidelink channels exploits single carrier frequency division multiple access (SC-FDMA) and applies quadrature phase shift keying (QPSK) and quadrature amplitude modulation (QAM) with a maximum order of 16 [15]. The PHY layer protocol entity applies robust QPSK at all times to transmit data related to control information on the PSCCH and PSBCH [21]. In contrast, user data transmit-ted on the PSSCH exploits QPSK and 16QAM [21]. The UE operates SC-FDMA because V2X communications through the PC5 interface are permitted in-coverage as well. When frequency division duplexing (FDD) or time division duplexing (TDD) is used for commu-nications through the Uu interface, then communications through the PC5 interface oc-curs in the uplink (UL) part of the frequency spectrum. Communications through the PC5 interface exploit TDD. The eNB is presumed to cope better with additional signal interfer-ence exhibited when performing UL data transmission at same time that data is carried through interface PC5.

The discovery function known from ProSe release 12 is not used for V2X communications [8] 6).

6) Providing the discovery function is not mandatory, but it is implementation dependent.

UE C

SyncRefUE to UE CUE A

SLSS / MIB-SL-V2X

SLSS

/ M

IB-S

L-V2

X

Sync.

UE Bindirect eNB synchronization

12

5 Synchronization in out-of-coverage V2X scenariosAccurate frequency and time synchronization is essential especially in time division mul-tiple access (TDMA) and frequency division multiple access (FDMA) systems. Misalign-ment may result in intersymbol interference (ISI) and intercarrier interference (ICI), which can degrade system performance. Timing advance, applied to data transmission in the UL direction to ensure signal orthogonality in mobile networks at the eNB, cannot be oper-ated in out-of-coverage scenarios. When a UE is permitted to access the wireless channel from the distributed MAC for point-to-multipoint data transmission, the signal propaga-tion time to every receiver remains unknown. This makes it even more important to align signal transmission to the slot and subframe (SF) boundary. The maximum time differ-ence before ISI may occur is limited to the length of the cyclic prefix (CP). The CP is in-serted in orthogonal frequency division multiplex (OFDM) symbol transmission to achieve signal orthogonality even if the transmitter and receiver are not very well synchronized. Correction of the carrier frequency compensates for imperfect oscillator calibration and additional frequency offset due to temperature drift.

LTE V2X exploits sidelink synchronization signals (SLSS) on the PHY layer [21] and the master information block SL-V2X (MIB-SL-V2X) [19] message on the RLC sublayer to achieve time and frequency synchronization.

5.1 Synchronization sourceA UE obtains information on time and frequency synchronization from signals received from global navigation satellite systems (GNSS), an eNB or from a nearby UE. The stan-dard distinguishes direct from indirect synchronization [19]: ❙ GNSS: the UE is synchronized to GNSS (direct) or to a nearby UE that achieves time and frequency synchronization from GNSS (indirect)

❙ eNB: the UE is synchronized to an eNB (direct) or to a nearby UE that is synchronized to an eNB (indirect)

❙ UE: the UE is synchronized to a nearby UE that obtains no synchronization information either directly or indirectly from eNB or GNSS

The synchronization sources and preference order are preconfigured to the UE or tempo-rarily configured through control messages delivered by the eNB.

Fig. 5-1: Direct and indirect eNB synchronization as well as synchronization reference UE (SyncRefUE) established in V2X scenarios with partial coverage

GNSS direct synchronization Local out-of-coverage synchronization


Fig. 5-1 shows the partial coverage scenario. UE A, assumed in network coverage, re-ceives synchronization information provided by the eNB. This UE is directly synchronized to an eNB and configured 7) to forward synchronization information to nearby UEs, possi-bly not in network coverage.

UE B, not in signal detection range from eNB and out of coverage, receives an SLSS and MIB-SL-V2X message from UE A, provided for indirect eNB synchronization. UE C, out of coverage, detects the SLSS sent by UE B 8) and is permitted to use UE B as the synchroni-zation reference UE (SyncRefUE).

The scenario where all UEs are out of coverage is depicted in Fig. 5-2.

Fig. 5-2: Direct GNSS synchronization and local out-of-coverage synchronization in scenarios without network coverage

UEs obtain time and frequency information either from the configured synchronization source GNSS 9) or define superframe, subframe and slot boundaries in a self-coordinated manner known as “local out-of-coverage synchronization”.

5.2 Synchronization signals and informationThe SLSS is a sidelink specific sequence consisting of two signals: ❙ Primary sidelink synchronization signal (PSSS) established from the Zadoff-Chu sequence 10)

❙ Secondary sidelink synchronization signal (SSSS) (maximum length sequence) 11)

PSSS and SSSS carry implicit information about the synchronization source considered for time and frequency adjustment. Specified values are assigned to the sidelink synchro-nization signal identifier (SLSSID) that decodes the specific synchronization source: ❙ GNSS: 0, 168, 169 ❙ eNB: 1 to 167 ❙ Out of coverage: 170 to 335

7) The parameter networkControlledSyncTx is used to control SLSS and MIB-SL-V2X transmission by the eNB. If the UE is camped on or connected to the cell and not configured to send any synchronization signals, the UE still sends SLSS and MIB-SL-V2X if the measured RSRP level is below the threshold. The threshold value is obtained from the parameter syncTxThreshIC.

8) A UE out of coverage sends SLSS and MIB-SL-V2X if either no SyncRefUE is selected or the measured S-RSRP of a SyncRefUE is below the threshold. The threshold value is obtained from the parameter syncTxThreshOoC.

9) Synchronization information obtained from GNSS signals is only considered for time and frequency offset adjustment when the GNSS signal is assumed to be reliable. Information provided by the GNSS receiver module, such as the signal power level, horizontal dilution of precision (HDOP) and number of satellites, is evaluated.

10) Distinctive characteristics of the Zadoff-Chu sequence are e.g. low peak-to-average power ratio (PAPR) and zero autocorrelation.

11) Obtained from a mathematical operation, e.g. applying a cyclic shift operation to a shift register.

14

A UE offering synchronization information to nearby UEs is supposed to serve as a syn-chronization reference. In addition to the SLSS, this UE provides further parameter values by carrying RLC messages on the SL-BCH. Information provided relates to the standard-ized MIB-SL-V2X [19] and includes the SF number, whether the UE is in coverage or out of coverage, and the operated frequency bandwidth. This information supports UEs in se-lecting the reference source according to the configured prioritization when seeking syn-chronization. The following priority groups are specified:

Table 5-1: Priority groupPreferred synchronization source

1 2 3 4 5 6

Direct Indirect Others Direct Indirect Others

eNB eNB eNB GNSS GNSS GNSS Remaining UEs

GNSS GNSS or eNB GNSS or eNB Remaining UEs

– – –

SyncRefUE SyncRefUE SyncRefUE SyncRefUE SyncRefUE

Candidate SyncRefUEs in each priority group are ordered according to the measured sidelink reference signal received power (S-RSRP). GNSS is the preferred source for time and frequency synchronization when operating V2V communications through the PC5 interface [22]. Frame and SF numbers are obtained from the coordinated universal time (UTC) provided by GNSS 12).

6 Physical resources and resource assignment 6.1 Resource pool (RP)A UE that intends to operate PC5 sidelink communications allocates specific time and frequency resources in terms of physical resource blocks (PRB) to carry control and user data. PC5 sidelink communications is permitted in PRBs either configured through con-trol messages provided by an eNB or preconfigured to the UE. All subframes (SF) offering PRBs intended for PC5 sidelink communications constitute the subframe pool (SP) [23]. The subframe indicator bitmap introduced in Fig. 6-1 specifies the SP. The indicated SFs in the SP re- occur periodically at an interval equal to the length of the subframe indicator bitmap [23]. 13)

12) When GNSS is the synchronization source, the direct frame number (DFN) is used instead of the system frame number (SFN) [22]. The subframe number is derived from UTC according to [22].

13) The bitmap length specified when the sidelink is operated in the UL of the FDD configuration: 16 bit, 20 bit or 100 bit. In case of TDD: 10 bit to a maximum of 60 bit with a 10-bit step size.

Subframe indicator bitmap

●●●

●●●

Physical resource block (PRB)

Subframe pool (SP) Slot Subframe

0 1 0 0 1 0 1 0 1 1 0 1

Reso

urce

blo

ck p

ool (

RBP)


Fig. 6-1: Resource pool (RP) and subframe indicator bitmap

PRBs offering time and frequency resources for PC5 sidelink communications are stated in the resource block pool (RBP). The RBP is assigned to UEs through sidelink control in-formation 1 (SCI 1) [24], [23] obtained from decoded control data received on the PSCCH. SCI 1 indicates PRBs allocated for user data transmission in that SF. RBP and SP consti-tute the resource pool (RP). Several RPs are provided to the UE specifically assigned for data transmission (TX) and data reception (RX) 14) to maintain half-duplex operation.

6.2 SubchannelsPRBs from the RBP that cover adjacent radio frequencies establish subchannels (SCH). The UE identifies SCHs from control information provided as part of the network configu-ration. The specific SCH allocation is further notified by SCI 1; see Fig. 6-2.

14) UE is provided with maximum 8 TX RPs and 16 RX RPs [22].


●●●

●●●

Physical resource block (PRB) Resource pool (RP)


Subchannel (SCH)

Physical sidelink control channel (PSCCH) Physical sidelink shared channel (PSSCH)

Size sub-channel

Start RB

subchannel

●●●

Start

RBPSCCH pool

SCH 1

SCH 0

m = 1

m = 0

PSSC

H RP

PSCC

H RP

1 0 1 1 0 10 1 0 0 1 0

16

Fig. 6-2: SCHs provide time and frequency resources to carry data on the PSSCH. SCI1 is carried on the PSCCH in nonadjacent PRBs

The parameter specified in [23] and [19] defines the PSSCH RP: ❙ StartRBSubChannel: Addresses the first PRB of the SCH ❙ SizeSubChannel: number of PRBs within the SCH ❙ NumberofSubChannels: number of SCHs established in the subframe specified in the SP

6.3 Resource assignment6.3.1 PSCCHPRBs from the RP are specifically assigned to carry control data related to the PSCCH. Four constant and contiguous PRBs are provided per SF to carry one SCI 1 message. These PRBs are allocated either adjacently or nonadjacently to the corresponding notified PRBs carrying user data on the PSSCH. When the UE is configured to operate nonadja-cent PSCCH transmission, depicted in Fig. 6-2, the additional parameter provided to the UE specifies the following [19]: ❙ StartRBPSCCHPool: Addresses the first PRB of the PSCCH RP

If control data is transmitted adjacent to PRBs intended to carry user data on the PSSCH, shown in Fig. 6-3, information about PRBs is directly obtained from the introduced pa-rameter StartRBSubChannel.


●●●

●●●

Physical resource block (PRB)


Subchannel (SCH)

Physical sidelink control channel (PSCCH ) Physical sidelink shared channel (PSSCH)

PSCCH RP

SCH 1

m = 1

SCH 0

m = 0

PSSCH RP

1 0 1 1 0 10 1 0 0 1 0

SCH

0 +

SCH

1 u

sed


Fig. 6-3: PSSCH subchannels (SCH) for adjacent PSCCH configuration

6.3.2 PSSCHA UE having V2X user data ready to send allocates PRBs from the PSSCH RP in terms of one SCH. There is always a direct relationship between the SCI 1 transmitted on the PSCCH and the allocation for PSSCH operation. Granting access permission to multiple (but contiguous) SCHs is feasible. SCHs as well as PRBs offering time and frequency re-sources adequate to carry control data are indexed in ascending order. As a result, the UE implicitly knows the SCH from the corresponding PSSCH transmission.

6.3.3 PSBCHSpecific subframes are continuously allocated in recurring synchronization periods every 160 ms. These subframes, known as synchronization subframes, are not notified by any RP; they are indicated through an additional parameter set: ❙ SyncOffsetIndicator: parameter set either provided by the eNB or preconfigured to the UE to identify time and frequency resources related to the synchronization subframe

Radio signals received on the PSBCH are subject to signal interference if nearby UEs intend to serve at the same time as SyncRefUE. The SyncRefUE selects one SyncOffsetIndicator 15) from the set of three to decrease the probability of continuously re-curring signal interference.

15) The specific SyncOffsetIndicator selected for MIB-SL-V2X transmission depends on the configured preferred synchronization source and the synchronization subframe carrying the received MIB-SL-V2X message from the nearby SyncRefUE.


●●●

●●●

Physical sidelink control channel (PSCCH) Subchannel (SCH)

Resource pool (RP) Sidelink control information (SCI)

Start RB

subchannel

SCH 1

SCH 0

m = 1

m = 0

1 0 1 1 0 10 1 0 0 1 0

SCH

0 +

SCH

1 u

sed

Retransmission Slot SubframeInitial transmission

SCI 1

SCI 1 SCI 1

SCI 1

SCI 1 SCI 1

SCI 1

Size subchannel

Start

RBPSCCH pool

●●●PSCCH RP

PSSCH RP

Physical sidelink shared channel (PSSCH)

SFGap = 3

18

6.3.4 Hybrid automatic repeat request (HARQ)A UE configured to support HARQ soft-combining on the SL-SCH selects PRBs from the RBP for message retransmission on the PSSCH 16). The number of subframes between initial and retransmission shown in Fig. 6-4 is indicated by the parameter Subframe Gap ( SFGap) carried in the SCI1 on the PSCCH. The HARQ protocol service is not provided for data transmission on the PSBCH.

Fig. 6-4: HARQ initial transmission and retransmission, assuming nonadjacent PSCCH configuration

6.4 Slot structurePC5 sidelink communications adopts the general LTE 1 ms subframe structure. 14 SC-FDMA symbols per subframe, 7 per 0.5 ms slot, are modulated to subcarriers. The normal CP with length 4.7 µs is applied to every SC-FDMA symbol [21]. No distinction is made between the channels PSSCH, PSCCH and PSBCH. Two additional demodulation reference symbols (DMRS), compared with 3GPP release 12, are inserted into subframes in order to compensate for radio signal interference caused by Doppler shifts that is ex-pected particularly in V2X scenarios. With reference to Fig. 6-5, SC-FDMA symbols 2, 5, 8 and 11 carry DMRS when radio signal transmission relates to PSCCH and PSSCH opera-tion [21].

16) No feedback for operated single point-to-multipoint transmission in terms of NACK/ACK is provided to the transmitter. The UE performs HARQ soft-combining with maximum one retransmission to increase the probability of decoding the V2X user data successfully. It is especially important for out-of-coverage communications where UEs are exposed to signal interference on the PSSCH when access permission to PRBs is granted through distributed MAC.

Guard time Demodulation reference symbol (DMRS)

Cyclic prefix (CP)

CP SC-FDMA symbol

Slot

Subframe

2 310 4 5 6 7 8 9 10 11 12 13

6 PRBs

Primary sidelink synchronization symbol (PSSS)

Secondary sidelink synchronization symbol (SSSS)

Slot

Subframe

2 310 4 5 6 7 8 9 10 11 12 1313

Guard time

Physical sidelink broadcast channel (PSBCH)

Demodulation reference symbol (DMRS)


Fig. 6-5: Slot structure for PSSCH and PSCCH

When radio signal transmission refers to the PSBCH, depicted in Fig. 6-6, then three DMRSs are carried in SC-FDMA symbols 4, 6 and 9 [21]. The last SC-FDMA symbol re-mains unused in all cases, to leave ample time to turn the radio transmitter from operated radio signal transmission to radio signal reception. SLSSs are modulated to subcarriers associated with the central six PRBs of the synchronization subframe. More specifically, PSSS is carried in SC-FDMA symbols 1 and 2, while SSSS is carried in SC FDMA symbols 11 and 12.

Fig. 6-6: Slot structure for the synchronization subframe

Parameter values provided by higher layers:Resource reservation interval = 100 msSL_RESOURCE_RESELECTION_COUNTER = 6

Permission expiredTxOPTxOP TxOP TxOPTxOP

SL_R

ESOU

RCE_

RESE

LECT

ION

_COU

NTE

R =

5Cr

esel

= 5

8

SL_R

ESOU

RCE_

RESE

LECT

ION

_COU

NTE

R =

4Cr

esel

= 5

7

SL_R

ESOU

RCE_

RESE

LECT

ION

_COU

NTE

R =

3Cr

esel

= 5

6

SL_R

ESOU

RCE_

RESE

LECT

ION

_COU

NTE

R =

0

Resource

reservation interval

SPS interval

Semi-persistent scheduling (SPS) Transmission opportunity (TxOP)

●●●

●●● ●●●

SL_R

ESOU

RCE_

RESE

LECT

ION

_COU

NTE

R =

6Cr

esel

= 5

9

SCH SCH

SCI 1SCI 1

SCH

SCI 1

SCH

SCI 1

Resource reservation interval (RRI)

20

7 Medium access control (MAC) layer 7.1 Semi-persistent scheduling (SPS)C-V2X applications related to road safety services generate data traffic with an almost constant interpacket arrival time. Data packets are ready to send every 20 ms to 100 ms per vehicle [7]. The data generation frequency depends on the carried information impor-tance, e.g. hazardous road situations, emergency braking and additionally on the radio channel load, which is derived from the signal power sensed while monitoring the radio channel. The UE, which has been granted permission to transfer data in a single SCH, is instantaneously permitted the right to transfer multiple MAC PDUs in periodically recur-ring SCHs [16]. The time between two successive transmission opportunities (TxOP), shown in Fig. 7-1, spans the resource reservation interval (RRI) provided by the applica-tion layer. The applied value reflects the delay requirement of the specific operated C-V2X service. The UE decrements a randomly selected value when a MAC PDU has been trans-mitted. The permission granted expires as soon as the value reaches zero or the maxi-mum SPS duration elapses 17) [16] [23].

Fig. 7-1: Semi-persistent scheduling (SPS) and resource allocation with nonadjacent PSCCH

17) The parameters SL_Resource_Reselection_Counter and Cresel define the SPS. SL_Resource_Reselection_Counter states the number of maximum MAC PDUs per SPS [16] and Cresel the maximum SPS duration [24]. Considering the parameter Resource Reservation Interval, then SL_Resource_Reselection_Counter translates to a random time from interval 500 ms to 1500 ms. Cresel increases every time by a factor of ten.

n Request to select or reselect resources 20 ≤ T2 ≤ 100

Sensing period Prediction period

Candidate resource Subframe not part of resource pool (RP)

Retrospective Prospective

T1 ≤ 4

n-10

00

n-99

9

n-4

n-3

n-2

n-1

n n+1

n+2●●● ●●●

n+T 1

n+T 2


7.2 Candidate single subframe resource The RP holds PRBs assigned for PC5 sidelink communications. The MAC sublayer might limit the set of PRBs intended to carry C-V2X data according to the radio signal power sensed in the SCHs from subsequently stated services the PHY layer offers 18) [23]: ❙ Spectrum sensing: radio signal power observed in SCHs corresponding to PSSCH data transmission in the most recent 1000 SFs

❙ Partial sensing: radio signal power observed in specific SCHs during the most recent 1000 SFs

The UE excludes SCHs that carry its C-V2X data while sensing the radio signal in the sensing period. The RRI, exemplified in Fig. 7-1, is configured to keep the required packet delay below the intended limit. The SCH stated in the RP and within the RRI is considered the candidate resource [23].

Fig. 7-2: Sensing period and candidate resource to carry C-V2X data

The length of the prediction period shown in Fig. 7-2 is useful when it is equal to the re-source reservation interval. The SCH identified for PC5 sidelink data transmission from the candidate resources shall periodically recur in each RRI. The UE, referring to Fig. 7-2, for the time of subframe n intends to select or reselect PRBs to transmit data through the PC5 interface. PRB reselection is necessary if either the SPS interval has elapsed or no further TxOPs remain.

7.3 Subchannel allocationA UE having C-V2X data ready to send excludes SCHs from the candidate resources ac-cording to the following requirements: ❙ Candidate resources that have already been granted to this specific UE ❙ Candidate resources that provide TxOPs that are occasionally overlapping with TxOPs that a previously established SPS offers to this specific UE; see Fig. 7-3

❙ Candidate resources additionally detected from the decoded SCI1 received in the PSCCH where the sensed radio signal power of the corresponding PSSCH exceeds the configured threshold

❙ Candidate resources notified by SCI1 that are occasionally overlapping with TxOPs of the SPS interval that the UE intends to establish; see Fig. 7-3

The introduced procedure is repeatedly applied with an additional 3 dB assigned to the threshold value until more than 20 % of candidate resources remain.

18) TS 36.213 [23] specifies the parameter Pstep to adapt the RRI and the sensing period to a specific TDD and FDD superframe con-figuration. In the operated FDD, and in particular for PC5 sidelink communications in the C-ITS frequency band at 5.9 GHz, the value 100 is applied to the parameter Pstep that lead to the stated values in this white paper.

●●●

Request to select or reselect resources

Resource reservation interval AT1 ≤ 420 ≤ T2 ≤ 100

Prediction period

Candidate resource to be excluded Subframe not part of resource pool (RP)

n+1

n+2

n n+T 1

n+T 2

n Candidate resource

Transmission opportunity (TxOP)

TxOP

TxOP

Resource reservation interval B

22

Fig. 7-3: Candidate resource interferes with transmission opportunity (TxOP) of a semi-persistent schedule (SPS)

The remaining candidate resources are ordered in relation to the measured sidelink re-ceived signal strength indicator (S-RSSI). From the lowest 20 %, the UE randomly selects one SCH to carry V2X data. An additional SCH from the remaining candidate resources is allocated for HARQ retransmission. The SCH is to be allocated a maximum of 15 SFs prior to the already selected SCH or a maximum of 15 SFs thereafter.

7.4 The zone concept UEs allocate PRBs to operate PC5 sidelink communications from RPs configured to spe-cific geographic regions. The RPs hold a unique zone identifier (ZoneId) that is derived from the geographic longitude and latitude coordinate 19). The zone concept, shown in Fig. 7-4, was introduced to keep the received radio signal power within a specified limit. In mobile communications systems, power control is essential to protect the receiver against saturation, which is known as the near-far effect, and to achieve a signal to inter-ference plus noise ratio (SINR) sufficient to properly decode the radio signal. Without cen-tralized, coordinated channel access, mitigating the performance impact due to the near-far effect through power adjustment is difficult to achieve. The zone concept restricts the use of the same RP to the specific location and keeps the distance between the transmit-ter and receiver within the limit.

19) The zone identifier calculation refers to: ZoneId = Y1 * Nx + X1 With X1 = Floor(X/L) mod Nx and Y1 = Floor (Y/W) mod Ny. X1 and Y1 are geographic coordinates. Parameters L and W are the configured length and width of the zone. Parameter values Nx and Ny are applied to achieve a reuse distance.

RP 4RP 3 RP 5 RP 3 RP 4 RP 5




Y1

X1

Length

Width

Resource pool (RP)

Ny =

2

Nx = 3


Fig. 7-4: Zone concept, exemplified for Ny = 2 and Nx = 3

How to sustain mobility in industrial countries is one key question of our modern society. C-ITS, with wireless connectivity as building block to enable full end-to-end digitization, is one auspicious approach to reduce road fatalities and to increase road traffic efficiency. With LTE-V2X, specified in release 14, 3GPP empowers the automotive industry to deploy these C-ITS services based on mobile communications technology. Introducing new tech-nology concepts to mobile communications networks were essential to meet the specific demands of automotive applications, mainly network availability and latency. Ad hoc communications without central coordinated access to the wireless channel even with-out a valid network subscription is one distinctive feature of LTE-V2X. It represents, from a 3GPP perspective, a further step into new and emerging vertical markets, the business expansion that will lay the foundation for creating novel ecosystems. This progress will be continued and expedited with the introduction of the 5th generation of mobile networks (5G). Providing ultra-reliable low latency communications (URLLC) service is the decisive attribute to support applications beyond those used in consumer electronics (CE). 3GPP still makes progress in adapting mobile communications technology to the remarkable development in automated driving. LTE-V2X, termed phase I, is mainly designed to carry vehicle status and environment information. Phase II, enhanced V2X (eV2X) introduced in release 15, is intended to support applications such as cooperative perception. Phase III, expected to be standardized in release 16, will introduce the New Radio (NR) concept to V2X, while phase II still remains the LTE technology.

Both industries, namely automotive and telecommunications, first and foremost, have to develop sustainable concepts closely together to transform the transportation system with its independent entities exhibited today into a system in which all entities harmoni-ously cooperate. Their common goal is to increase road traffic efficiency and ultimately improve quality of life.

Holger Rosier, Rohde & Schwarz GmbH & Co. KG

8 Summary

24

9 Abbreviations

Abbreviations3 O

3GPP 3rd Generation Partnership Project OFDM orthogonal frequency division multiplex

A P

ADAS advanced driver-assistance system PCI protocol control information

ARP address resolution protocol PDCP packet data convergence protocol

ARQ automatic repeat request PDU protocol data unit

B PHY physical layer

BSM basic safety message PLMN public land mobile network

C PPPP proximity-based services per packet priority

CAM cooperative awareness message PRB physical resource block

CE consumer electronics ProSe proximity-based services

C-ITS cooperative intelligent transportation system PSBCH physical sidelink broadcast channel

CP cyclic prefix PSSCH physical sidelink shared channel

CPL control plane PSCCH physical sidelink control channel

D PSSS primary sidelink synchronization signal

DENM decentralized environment notification message Q

DMRS demodulation reference symbol QAM quadrature amplitude modulation

DSRC dedicated short-range communications QPSK quadrature phase shift keying

E R

eNB evolved NodeB RBP resource block pool

ETSI European Telecommunications Standards Institute RLC radio link control

E-UTRA evolved universal terrestrial radio access RP resource pool

E-UTRAN evolved universal terrestrial radio access network RRC radio resource control

eV2X enhanced vehicle-to-everything RRI resource reservation interval

F RSU road side unit

FDD frequency division duplex RX reception

FDMA frequency division multiple access S

G SA service and system aspects

GLOSA green light optimal speed advisory SAE Society of Automotive Engineers

GNSS global navigation satellite systems SF subframe

H SBCCH sidelink broadcast control channel

HARQ hybrid automatic repeat request SCI sidelink control information

HPLMN home public land mobile network SC-FDMA single carrier frequency division multiple access

HSS home subscriber server SCH subchannel

I SDO standardization organization

ICI intercarrier interference SDU service data unit

ID identifier SINR signal to interference plus noise ratio

IP Internet protocol SL-BCH sidelink broadcast channel

ISI intersymbol interference SL-SCH sidelink shared channel

ITS intelligent transportation system SLSS sidelink synchronization signal

ITS-G5 intelligent transportation system at 5 GHz SLSSID sidelink synchronization signal identifier

L SP subframe pool

L-GW local gateway SPS semi-persistent scheduling

LTE Long Term Evolution S-RSRP sidelink reference signal received power

M S-RSSI sidelink received signal strength indicator

MAC medium access control SSSS secondary sidelink synchronization signal

ME mobile equipment STCH sidelink traffic channel

MIB master information block SyncRefUE synchronization reference user equipment

N

NR New Radio


AbbreviationsT V

TDD time division duplex VPLM visited public land mobile network

TDMA time division multiple access V2I vehicle-to-infrastructure

TM transmission mode V2V vehicle-to-vehicle

TSG technical specification group V2N vehicle-to-network

TX transmission V2P vehicle-to-pedestrian

TxOP transmission opportunity V2X vehicle-to-everything

U VRU vulnerable road user

UE user equipment W

UL uplink WAVE wireless access in vehicular environments

UPL user plane WG work group

URLLC ultra-reliable low latency communications Z

USA United States of America ZoneID zone identifier

USIM universal subscriber identity module

UTC coordinated universal time

26

10 References

Number Reference[1] 3rd Generation Partnership Project, 3GPP TR 22.885: Study on LTE support for Vehicle to Everything (V2X) Services, Technical

Specification Group Service and System Aspects, Release 14, 2015.

[2] European Telecommunications Standards Institute, ETSI TR 102638: Intelligent Transport Systems (ITS), Vehicular Communications, Basic Set of Applications, Definitions, Version 1.1.1, 2009.

[3] European Telecommunications Standards Institute (ETSI), TS 102894-1: Intelligent Transport Systems (ITS); Users and applications requirements; Part 1: Facility layer structure, functional requirements and specifications, Version: 1.1.1, 2013.

[4] L. Ward, Dr. M. Simon: Intelligent Transportation Systems Using IEEE 802.11p, Application Note 1MA152, Rohde & Schwarz, 2015

[5] European Telecommunications Standards Institute (ETSI), EN 302637-2: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service, Version 1.3.2, 2014.

[6] European Telecommunications Standards Institute (ETSI), EN 302637-3: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service, Version: 1.2.2, 2014.

[7] 3rd Generation Partnership Project (3GPP), TS 22.185: Service Requirements for V2X Services, Technical Specification Group Service and System Aspects, Release 14, 2017.

[8] 3rd Generation Partnership Project, TS 23.285: Architecture enhancements for V2X Services, Technical Specification Group Service and System Aspects, Release 14, 2017.

[9] 3rd Generation Partnership Project (3GPP), TS 23.303, Proximity-based Services (ProSe), Technical Specification Group Services and System Aspects, Release 14, 2016.

[10] IEEE, Std 1609.0-2013: Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture, 2014.

[11] European Telecommunications Standards Institute (ETSI), EN 302663: Intelligent Transport Systems (ITS); Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band, 2013.

[12] European Telecommunications Standards Institute (ETSI), EN 302665: Intelligent Transport Systems (ITS); Communications Architecture, Version: 1.1.1, 2010.

[13] 3rd Generation Partnership Project (3GPP), TS 23.303 Proximity-based Services Stage 2, Technical Specification Group Services and System Aspects, Release 12, 2016.

[14] 3rd Generation Partnership Project (3GPP), TS 23.303, Proximity-based Services (ProSe) Stage 2, Technical Specification Group Services and System Aspects, Release 14, 2016.

[15] 3rd Generation Partnership Project (3GPP), TS 36.201: Evolved Universal Terrestrial Radio Access (E-UTRA); LTE Physical Layer; General Description, Technical Specification Group Radio Access Network, Release 14, 2017.

[16] 3rd Generation Partnership Project (3GPP), TS 36.321: Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) Protocol Specification, Technical Specification Group Radio Access Network, Release 14, 2018.

[17] 3rd Generation Partnership Project (3GPP), TS 36.322: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) Protocol Specification, Technical Specification Group Radio Access Network, Release 14, 2017.

[18] 3rd Generation Partnership Project (3GPP), TS 36.323: Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) Specification, Technical Specification Group Radio Access Network, Release 14, 2017.

[19] 3rd Generation Partnership Project, TS 36.331: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC) Protocol Specification, Technical Specification Group Radio Access Network, Release 14, 2018.

[20] 3rd Generation Partnership Project (3GPP), TS 36.300: Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Network (E-UTRAN); Overall Description; Stage 2, Technical Specification Group Radio Access Network, Release 14, 2017.

[21] 3rd Generation Partnership Project, (3GPP), TS 36.211: Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation, Technical Specification Group Radio Access Network, Release 14, 2017.

[22] 3rd Generation Partnership Project (3GPP), RP-161504: V2V Work Item Completion, Qualcomm Incorporated, LGE, CATT, III, Panasonic, Huawei, HiSilicon, Kyocera, Ericsson, Vodafone, Sony, Release 14, 2016.

[23] 3rd Generation Partnership Project (3GPP), TS 36.213: Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Layer Procedures, Technical Specification Group Radio Access Network, Release 14, 2017.

[24] 3rd Generation Partnership Project, TS 36.212: Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and Channel Coding, Technical Specification Group Radio Access Network, Release 14, 2018.

[25] 3rd Generation Partnership Project (3GPP), TS 36.322: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RLC) Protocol Specification, Technical Specification Group Radio Access Network, Release 14, 2018.

R&S® is a registered trademark of Rohde & Schwarz GmbH & Co. KG

Trade names are trademarks of the owners

PD 3607.7970.52 | Version 01.00 | July 2018 (sk)

White paper | Introduction to the vehicle-to-everything communications service V2X

feature in 3GPP release 14

Data without tolerance limits is not binding | Subject to change

© 2018 Rohde & Schwarz GmbH & Co. KG | 81671 Munich, Germany 3607

.797

0.52

01.

00 P

DP

1 e

n

Rohde & SchwarzThe Rohde & Schwarz electronics group offers innovative solutions in the following business fields: test and mea-surement, broadcast and media, secure communications, cybersecurity, monitoring and network testing. Founded more than 80 years ago, the independent company which is headquartered in Munich, Germany, has an extensive sales and service network with locations in more than 70 countries.

www.rohde-schwarz.com

Regional contact ❙ Europe, Africa, Middle East | +49 89 4129 12345 [email protected]

❙ North America | 1 888 TEST RSA (1 888 837 87 72) [email protected]

❙ Latin America | +1 410 910 79 88 [email protected]

❙ Asia Pacific | +65 65 13 04 88 [email protected]

❙ China | +86 800 810 82 28 | +86 400 650 58 96 [email protected]

3607797052

http://www.rohde-schwarz.com

©rohde & schwarz; introduction to the vehicle-to …...rohde & schwarz white paper |...

Documents