# Enhanced 5G V2X Services using Sidelink Device-to-Device Communications

Nestor Bonjorn, Fotis Foukalas, Paul Pop

► To cite this version:

Nestor Bonjorn, Fotis Foukalas, Paul Pop. Enhanced 5G V2X Services using Sidelink Device-to-Device Communications. 17th Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net 2018), Jun 2018, Capri Island, Italy. pp.116-122. [https://hal-01832538](https://hal-01832538)

HAL Id: hal-01832538

https://inria.hal.science/hal-01832538

Submitted on 8 Jul 2018

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Enhanced 5G V2X Services using Sidelink
## Device-to-Device Communications

Nestor Bonjorn *, Fotis Foukalas *, Member IEEE, Paul Pop *, Senior Member IEEE

*Technical University of Denmark, Lyngby, Denmark

Email: * s161328@student.dtu.dk * fotisf@dtu.dk * paupo@dtu.dk

***Abstract***—In this paper, we present advances of sidelink (SL) device-to-device (D2D) communications as a key-enabling technology for 5G enhanced vehicular-to-everything (eV2X) communications. We provide an overview about the resource allocation and scheduling of different SL D2D modes under in-coverage and out-of-coverage application scenarios. Moreover, we present the scheduling for SL D2D V2X communications, which relies on semi-persistent scheduling (SPS) as proposed within the 3GPP specification. Simulations were carried out to evaluate the performance in terms of collision probability assuming different values of the key parameters such as resource reselection interval (RRI) and resource selection window. We finally discuss about the open technical challenges for ultra-reliable and low-latency communications as distilled from the 5G V2X use cases introduced in 3GPP Rel.15. A cooperative resource allocation and scheduling solution is also given, where a more detailed version is considered our future work on this topic.

***Index Terms***—5G V2X services, sidelink device-to-device, resource allocation, scheduling, cooperative solution.

## I. INTRODUCTION

5G vehicular communication is considered one of the big challenges towards the next generation communication system. Several 5G vehicle-to-everything (V2X) use cases have been already proposed within 3GPP Rel.15 such as vehicle platooning, remote driving or cooperative collision avoidance [1]. In particular, in [2], the authors provided an overview of the open challenges towards supporting V2X services in high mobility environments and dense locations of UEs. Aiming to guarantee the V2X service requirements in such vehicular communication environment, new solutions are required to address requirements such as reliability and latency. The authors focused on different design requirements such as the air interface, cost-effective network deployment and the support of different communication types. However, they neither provided particular solutions for any of these challenges nor focused on any technical solutions. They referred, though, to the channel structure of the sidelink (SL) device-to-device (D2D) communications. They also mentioned the 3GPP specification work that is expected to provide a new air interface design for 5G communications in a broader way.

In [3], the author provided more details about the 3GPP specification initiatives to the vehicle-to-vehicle (V2V) communications. In particular, the PC5 interface, where the SL D2D communications relies on, and the recently introduced

modes 3 and 4 (mode 3-4) are described in detail. An additional reference is provided to the new resource allocation technique that takes into account the near-far effect. A white paper from 5G automotive association (5GAA) aims to promote the vision of connected mobility such as autonomous driving and intelligent transportation. 5GAA provides an end-to-end ecosystem through an industrial alliance paying attention to 5G V2X communications as well [4]. Moreover, the authors in [5] paid more attention to the PC5 interface for V2X communications providing a discussion on open challenges to provide efficient resource allocation, reliable and prioritized message type, power control and communication range enhancements. More recently, in [6], the authors also mention the need for an extension of the PC5 interface for V2X communications provided by the LTE D2D proximity service (ProSe). PC5 interface is actually the interface that will enable the V2V communications under in-coverage and out-of-coverage application scenarios [7]. In [8], they proposed a V2X communications solution to support better vehicle platooning towards the 5G V2X communications. The proposed solution relied on the LTE D2D technology addressing the low-latency requirement of messaging within the platoon. In [9], the authors provided an overview of the operation scenarios of LTE V2X solutions based on particular use cases.

It is obvious from the above discussion that V2X communications will play a role towards 5G. It is also evident that the SL D2D communication is considered as a key-enabling technology towards enhanced 5G V2X services. In this paper, we provide an overview of the new SL D2D modes 3 and 4, as well as details about the baseband processing and resource allocation. A link-level simulator was developed relying on [10] and simulation results are provided highlighting the different trade-offs in terms of BLER for different modulations, signal-to-noise ratios (SNRs) and payload sizes. Next, the scheduling for SL D2D V2X communications is analysed. A semi-persistent scheduling (SPS) was proposed within the 3GPP specification and, thus, we have developed a system-level simulator to evaluate the performance considering a number of vehicular UEs. It is observed from the simulation that the collision probability is affected by different design factors of the standardized SPS. Finally, a cooperative solution that improves the reliability of the system is devised, offering reliable 5G V2X services. Our future work on this topic will further develop the proposed cooperative resource allocation
and scheduling solution for future enhanced 5G V2X services.

The rest of this paper is organized as follows. Sec.II provides an overview of SL D2D communications with special focus on resource allocation for modes 3 and 4. Sec.III describes the semi-persistent-scheduling proposed for SL D2D modes 3 and 4 within the 3GPP standardization body. Sec.IV provides a short list of design requirements for ultra-reliable and low-latency 5G eV2X communications and a cooperative solution to address reliability requirements. Finally, Sec.V concludes this work.

## II. SIDELINK DEVICE-TO-DEVICE LTE V2X COMMUNICATIONS

In Mode 1, the UEs are assisted by the eNB and they use dedicated radio resources for data transmission. In Mode 2, the UEs randomly select the radio resources from a resource pool that was previously sent by the eNB. Both modes share the same resource allocation structure, in which the transmission of data is scheduled within the so-called physical SL control channel (PSCCH) period. Within this period, a set of subframes are determined for the PSCCH transmission (light blue region in Fig.1a) and a different set of subframes are determined for the physical SL shared channel (PSSCH) (yellow region in Fig.1a). The corresponding PSCCH for a given PSSCH is always sent before the PSSCH data. The PSCCH contains the sidelink control information (SCI), also called scheduling assignment (SA), which is used by the receiver to know the occupation of the PSSCH radio resources. In both modes, the SCI is configured in format 0 and it is transmitted identically in two different subframes. This retransmission is always necessary due to the lack of feedback channel in SL communication. The receiver blindly detects the SCI by trying out all possible PSCCH resources. The PSSCH transport block is transmitted four times in four consecutive subframes within the subframe pool, allowing the receiver UE to implement open loop hybrid automatic repeat request (HARQ) by combining the four redundancy versions of the PSSCH transport block.

Likewise, the difference between Mode 3 and Mode 4 is also that in Mode 3 the UEs resource allocation is assisted by the eNB while in Mode 4 the UEs choose the radio resources autonomously. However, mode 3-4 share a completely different structure than mode 1-2 described above in order to allocate the PSCCH and PSSCH. First, there is no PSCCH period in order to distribute the transmission of both physical channels into different temporal periods. In contrast, the PSCCH and PSSCH channels are separated in the frequency domain. The resource grid is divided into sub-bands or sub-channels in which the first resource blocks (lowest frequencies) of these sub-channels form the PSCCH pool (light blue region in Fig.1b) and, the other resource blocks, the PSSCH pool (yellow region in Fig.1b). Although PSCCH and PSSCH can be transmitted on non-adjacent resource blocks, in this work, we rely on the adjacent configuration (as illustrated in Fig.1b). Two identical SCIs (in format 1) to combat channel distortion and their corresponding PSSCH transport block are

sent in the same subframe. In mode 3-4, a transport block can be sent either once or twice. In case of two transmitting attempts, another subframe is used with the same structure: two SCIs and their corresponding PSSCH transport block. In this case, the receiver also implements HARQ.

Fig.1 illustrates different scenarios within the different communication modes and it enables to highlight the main differences between mode 1-2 and mode 3-4. In the example depicted in Fig.1, three packets with different sizes arrive from higher layers at different instants. The arrows within the grid show the PSSCH occupations that an SCI determines. One of the main drawbacks of mode 3-4 in comparison with mode 1-2 is the spectral efficiency since the sub-channels are not always full of data while being used. It is observed in Fig.1b that, in the second transport block transmission (7-bytes packet), the data (orange part) occupies only a short portion of the entire sub-channel. The other resource blocks of the sub-channel are not used in this transmission and cannot be used by other UEs with the same grid configuration without colliding, even though there was enough space for both UEs to transmit in the same sub-channel. This is because of the sub-channel granularity in the resource allocation in mode 3-4, in which the transmission of data always starts at the lowest frequencies of the sub-channel. This constrains the scheduling flexibility since different UEs can be allocated in fewer different positions than in mode 1-2, where the scheduling granularity is resource block. Therefore, there is not only a lower spectral efficiency in mode 3-4 than in mode 1-2, but there is also a higher collision probability when several nearby UEs are transmitting at the same time and the sub-channels are partially empty. The main advantage of mode 3-4 is the latency since a packet arrived from upper layers is immediately scheduled in any of the available following subframes within the subframe pool, as illustrated in Fig.1b. Instead, in mode 1-2 the packet transmission might have to wait for the next PSCCH period to start, as illustrated for the second packet in Fig.1a. Moreover, mode 3-4 introduce additional demodulation reference signal (DMRS) symbols in order to handle high-Doppler effects in high-mobility scenarios. For these reasons, Modes 3 and 4 were proposed in Rel.14 as the communication modes for V2X applications for in-coverage and out-of-coverage scenarios, respectively.

Fig.2 depicts the average block error rate (BLER) over SNR in dB for mode 3-4. The simulation is carried out for 1000 packet transmissions using different message payload sizes such as 200, 400 and 600 bytes and different types of modulation such as QPSK and 16-QAM. The results are achievable as long as there is no interference from other UEs transmissions. We can see that the higher the SNR is, the lower the BLER is, as expected. Moreover, using different modulation types (e.g., QPSK or 16-QAM) has a big impact on the performance in terms of BLER. As expected, a higher order modulation, i.e. 16-QAM, leads to a higher BLER due to a higher number of bits transmission per frequency channel. It is interesting though, that the message payload size does not contribute significantly to the performance results.
<figure><img src="image_2.png" /><figcaption>Fig. 1. Resource allocation structure: a) Mode 1-2, b) Mode 3-4.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Achievable BLER vs SNR for different payload sizes and modulations.</figcaption></figure>

### III. SIDELINK D2D SCHEDULING FOR V2X COMMUNICATIONS

#### A. Scheduling for V2X communications

Due to the periodic nature and predictable size of packets in V2X transmissions, a sensing-based semi-persistent scheduling (SPS) is proposed within 3GPP in order to optimize the use of the resource grid and minimize the transmission collisions between different UEs. The standardized SPS procedure is illustrated in Fig.3 and described below.

In the standardized SPS approach, the UE transmits in a certain resource every resource reservation interval (RRI). After each transmission, the UE's MAC entity decreases the value of a counter called SL_RESOURCES_RESELECTION_COUNTER by one. When this counter reaches zero, the UE either keeps its

<figure><img src="image_4.png" /><figcaption>Fig. 3. Semi-persistent scheduling (SPS) according to 3GPP Rel.14.</figcaption></figure>

current resources with probability $p_{RK}$ (probResourceKeep) or triggers resource reselection with probability $(1-p_{RK})$. In both cases, the UE randomly selects a new integer value for the counter within a specified range $[C1, C2]$ that depends on the RRI value [11] (see Table I).

<table><caption>TABLE I
SL资源 RESELECTION_COUNTER RANGE DEPENDING ON RRI VALUE [11]</caption><thead><tr><td>RRI</td><td>[C1, C2]</td></tr></thead><tbody><tr><td>≥ 100ms</td><td>[5, 15]</td></tr><tr><td>50ms</td><td>[10, 30]</td></tr><tr><td>20ms</td><td>[25, 75]</td></tr></tbody></table>

In case that resource reselection is triggered, the UE generates a set of resource candidates in the resource selection window, which corresponds to the range of subframes $[n+T1, n+T2]$, where n is the current subframe, T1 depends on the process delay of the UE ($T1 \le 4$) and T2 shall fulfill the latency requirements ($20 \le T2 \le 100$) [12]. The resource candidates are generated based on what is previously sensed in the sensing window (1000ms) and the UE randomly chooses one of these resource candidates. The UE continues transmitting in the selected frequency resource until resource reselection is triggered back again.

#### B. Simulation results and discussion

A system-level simulator was developed in order to evaluate the performance of the presented resource scheduling approach. This simulator allows us to discuss about the different parameters setting as well as to propose and test potential enhancements into the system. The simulated SPS algorithm that runs on each UE is given in Algorithm 1. The steps in lines 2 to 4 correspond to the initialization of the algorithm, in which random resources are assigned to each UE. The variable *subfr* is defined as the time consumed throughout the simulation. Next, the if-statement in line 7 is regarding the event "if the UE transmits in the current subframe", since *txSubfr* denotes the subframe where the UE transmits. The simulation parameters values are summarized in Table II. The simulation scenario, as well as some assumptions and simplifications, are described below.

The simulation setup consists of a group of 10 vUEs that communicate to each other using SL D2D modes 3-4. At the
<caption>**Algorithm 1** Pseudo code of the standardized SPS approach</caption>

1: **procedure** SPS(RRI,T1,T2,C1,C2, $N_{subCH}$, $L_{subCH}$)
2:     $txSubch$ ← a random set of $L_{subCH}$ contiguous sub-channels within $N_{subCH}$
3:     $txSubfr$ ← a random number between 1 and RRI
4:     $counter$ ← a random number between 1 and C2
5:     $subfr$ ← 0
6:     **while** True **do**
7:         **if** $subfr = txSubfr$ **then**
8:             Transmit packet in subchannels $txSubch$
9:             **if** $counter \neq 0$ **then**
10:             $txSubfr$ ← $txSubfr + RRI$
11:             $counter$ ← $counter - 1$
12:         **else**
13:             $counter$ ← a random number between C1 and C2
14:         **if** (random number between 0 and 1) $\le$ $p_{RK}$ **then**
15:             $txSubfr$ ← $txSubfr + RRI$
16:         **else**
17:             $txSubfr, txSubch$ ← Resource reselection within the interval [$subfr + T1, subfr + T2$] based on sensing
18:         **end if**
19:     **end if**
20:     **else**
21:         Perform sensing
22:     **end if**
23:     $subfr$ ← $subfr + 1$
24:     **end while**
25: **end procedure**

beginning of the simulation, the resources used by each UE are randomly initialized, as well as the current value of their counters. In order to simulate a dynamic scenario, we add a new UE into the system with random resources every 10 seconds. At the same time, one of the existent 10 vehicles leave the group so that we keep having 10 vehicles in the platooning scenario. Both the considered number of vUEs and the "join/leave" event frequency are reasonable parameters for a typical vehicle platoon example.

We assume that all vehicles transmit periodically with the same rate due to the periodic nature of V2X traffic. In other words, the different vehicles use the same RRI value and send packets of equal size. For the sake of simplicity, we also assume that all subframes may be used for SL operation. Regarding the generation of resource candidates when performing resource reselection, we consider that the resources used by any other vehicle are occupied while the others are available. To this end, we do not use any power threshold in order to consider a resource as available or not.

The simulation runs for 1.000.000 subframes, which represent 1000sec in the system. The average collision rate from the beginning of the simulation is calculated every 1sec. In this

<figure><img src="image_5.png" /><figcaption>Fig. 4. Average collision probability $p_c$ with different $p_{RK}$ values.</figcaption></figure>

way, the last obtained collision rate value represents the average collision rate along all the simulation. All the presented results represent the average of 10 different simulations.

<table><caption>TABLE II
SIMULATION PARAMETERS</caption><thead><tr><td>Parameter</td><td>Default value</td></tr></thead><tbody><tr><td>Number of vehicles</td><td>10</td></tr><tr><td>Retransmission</td><td>Off</td></tr><tr><td>Bandwidth (B)</td><td>20 MHz</td></tr><tr><td>Message payload size</td><td>400 Bytes</td></tr><tr><td>N<sub>subCH</sub></td><td>2</td></tr><tr><td>L<sub>subCH</sub></td><td>1</td></tr><tr><td>RRI</td><td>20 ms</td></tr><tr><td>T1</td><td>2 ms</td></tr><tr><td>T2</td><td>20 ms</td></tr><tr><td>C1</td><td>25</td></tr><tr><td>C2</td><td>75</td></tr><tr><td>p<sub>RK</sub></td><td>0</td></tr></tbody></table>

In Fig.4, we depict simulation results of the average collision probability with the 5 possible $p_{RK}$ values. We can see that the lowest average collision probability is obtained with $p_{RK} = 0.4$, while the highest average collision probability is obtained with $p_{RK} = 0.8$. With $p_{RK} = 0.4$ reselection is performed when the counter expires with a probability of 60%, while the resources are retained with a probability of 40%. For the following simulations, $p_{RK} = 0.4$ is used.

The rest of variable parameters within the standardized SPS approach are RRI and T2. These two parameters depend on the specific application requirements, mainly in the maximum end-to-end latency. While RRI can take the values 20, 50 and 100 [11] (also other higher values that are not considered in our use case), T2 can take any value between 20 and 100 [12]. In order to observe the system behaviour for different combinations of RRI and T2, we perform nine different simulations using all the combinations within the numbers 20, 50 and 100. We depict all the corresponding results in Fig.5. As expected, a higher RRI number gives a lower collision probability due
<figure><img src="image_6.png" /><figcaption>Fig. 5. Average collision probability $p_c$ with different combinations of RRI and T2.</figcaption></figure>

to a lower traffic density. We also observe that the lowest average collision probability is obtained with $RRI = 100ms$ and $T2 = 20ms$. In fact, given a specific RRI the lowest collision probability always seems to be given by the minimum $T2$ value. Nevertheless, the combination of $RRI = 100ms$ and $T2 = 20ms$ can only be used if the maximum end-to-end delay requirement is $100ms$ or higher. For example, if the latency requirement is $50ms$, the best combination is given by $RRI = 50ms$ and $T2 = 20ms$. Finally, if the latency requirement is 20 ms, only the combination of $RRI = 20ms$ and $T2 = 20ms$ can be used from all different considered solutions.

# IV. ULTRA-RELIABLE AND LOW-LATENCY DESIGN REQUIREMENTS AND SOLUTION FOR 5G V2X SERVICES

## A. Ultra-Reliable and Low-Latency Design Requirements

The requirements to enhance 3GPP support for 5G V2X service are described in [1], where design requirements for 25 different 5G V2X use cases are presented. A list of the most important use cases as specified in 3GPP Rel.15 is presented below:

* eV2X support for vehicle platooning: information exchange such as join and leave, announcement warning, etc.

* eV2X support for remote driving: remote driving differs from autonomous driving from the fact that the vehicle is controlled remotely.

* Automated cooperative driving for short-distance grouping: automated cooperative driving is considered a combination of vehicle platooning with high-demanding communication among the vehicles.

* Collective perception of the environment: vehicles can exchange real time information, collected by vehicle sensors, among each other.

* Cooperative collision avoidance: vehicles should be able to evaluate the probability of an accident by coordinating manoeuvres using cooperative awareness messages and data from sensors.

We would like to summarize the design requirements of the 5G V2X use cases mentioned above in terms of the payload size, payload message reliability and latency per use case. To this end, Table III summarizes the different use cases with the corresponding KPIs.

<table><caption>TABLE III PAYLOAD MESSAGE SIZE, RELIABILITY AND LATENCY REQUIREMENTS FOR 5G EV2X SERVICES PER USE CASE [1]</caption><thead><tr><td>5G Use Case</td><td>Size (B)</td><td>Reliability (%)</td><td>Latency (ms)</td></tr></thead><tbody><tr><td>Vehicle Platooning</td><td>300-400</td><td>90</td><td>25</td></tr><tr><td>Remote Driving</td><td>300-400</td><td>99.99</td><td>5</td></tr><tr><td>Auton. Coop. Driving</td><td>1200</td><td>99.99</td><td>10</td></tr><tr><td>Collective Perc. of Envir.</td><td>1600</td><td>99</td><td>100</td></tr><tr><td>Coop. Coll. Avoidance</td><td>2000</td><td>99.99</td><td>10</td></tr></tbody></table>

We can observe in Table III that both latency and reliability requirements are very stringent for 5G communications. In fact, latencies of 10ms as in the automated cooperative driving use case are unachievable within the described system since both RRI and T2 values are considered to be 20ms at least within 3GPP specifications in Rel.14. On the other hand, in order to guarantee message reliabilities of 99.99% in a real traffic scenario, new enhancements will need to be made for both resource allocation and scheduling.

## B. Cooperative Resource Allocation and Scheduling

In the standardized SPS approach, collisions among different vUEs occur while their resource selection windows overlap. In this section, we present a solution based on the standardized SPS approach that deals with this problem more efficiently in terms of reliability. The proposal consists of transmitting the counter values in each packet transmission so that the vUEs are aware of the current counters of their surrounding vUEs. Then, the vUEs will trigger counter reselection if any of the received counters in the last RRI coincide with their own current counter. In this way, we aim to avoid the fact that two UEs arrive to counter 0 and, thus, perform resource reselection close in time, leading to a free-of-collision resource selection window.

We present below the counter reselection procedure. The counters considered for counter reselection (set A, hereafter) consists of the counters lower than the current counter. The selection of lower counters aims to not delay the resource reselection triggering. In this way, if the UE transmission involved in the counter reselection is colliding with another transmission, we do not prolong the collision time. Then, considering the received counter values during the last RRI as $C_{RX} = [c_0, c_1, ..., c_{N-1}]$, where $c_i$ is the $i$-th received counter value and $N$ is the number of received counters, the non-available counters (set B, hereafter) consists of $C_{RX} \cup (C_{RX} - 1)$, where $(C_{RX} - 1) = [c_0 - 1, c_1 - 1, ..., c_{N-1} - 1]$. $(C_{RX} - 1)$ are also considered as non-available counters
because, in case one of them is chosen, it will coincide with some surrounding UE counter when this one has gone through another RRI. This is due to the fact that the collision event will be appeared that we are trying to avoid. Finally, when performing counter reselection, the UEs will randomly choose, with equal probability, one of the counters in the set $C = A \setminus B$.

<caption>**Algorithm 2** Pseudo code of the proposed cooperative SPS approach</caption>

1: **procedure** PROPOSAL(RRI,T1,T2,C2,$N_{subCH}$,$L_{subCH}$)
2:     txSubch ← a random set of $L_{subCH}$ contiguous sub-channels within $N_{subCH}$
3:     txSubfr ← a random number between 1 and RRI
4:     counter ← a random number between 1 and C2
5:     subfr ← 0
6:     **while** True **do**
7:         **if** subfr = txSubfr **then**
8:             **if** counter ≠ 0 **then**
9:                 rxCounters ← received counters in the last RRI
10:             **if** counter in rxCounters **then**
11:                 A ← {1, ..., counter − 1}
12:                 B ← rxCounters ∪ (rxCounters − 1)
13:                 C ← A \ B
14:                 counter ← a random number within C
15:             **else**
16:                 counter ← counter − 1
17:             **end if**
18:         Transmit packet and counter in subchannels txSubch
19:     txSubfr ← txSubfr + RRI
20:     **else**
21:         counter ← C2
22:     Transmit packet and counter in subchannels txSubch
23:     txSubfr, txSubch ← Resource reselection within the interval [subfr + T1, subfr + T2] based on sensing
24:     **end if**
25:     **else**
26:         Perform sensing
27:     **end if**
28:     subfr ← subfr + 1
29:     **end while**
30: **end procedure**

Another difference comparing to the standardized SPS approach is based on the counter value that is chosen when the current counter expires (i.e., reaches value 0). In the standardized approach, a counter range is specified so that the UEs randomly choose, with equal probability, one of the counters in the counter range defined as $[C1, C2]$. In our proposal, we fix the chosen counter to 50, i.e. $C1 = C2 = 50$. This is done because, since the counter values among close

<figure><img src="image_7.png" /><figcaption>Fig. 6. Average collision probability in dynamic scenario: standardized vs proposed approaches.</figcaption></figure>

UEs are separated by our counter reselection approach, they will remain so by choosing a fixed counter value when the counter expires. Instead, if they randomly chose a new counter each time it expires, the counters from different UEs could 'collide' again. Finally, the parameter $p_{RK}$ is removed from the system (or set to 0) since it no longer improves the performance of the algorithm. The operational procedure of the overall proposal running in each UE is given in Algorithm 2.

Fig.6 depicts the results obtained for the proposed approach using the parameter values from Table II (apart from $C1$ and $C2$), as well as the results obtained for the simulated standardized approach (in this case, using $p_{RK} = 0.4$). It is observed that the proposed approach clearly achieves lower collision probability (0.14% after 1000 seconds in the simulated scenario) than the standardized approach (0.64%). In fact, all the collisions in the system come from the new vUEs that eventually enter into the system. This is demonstrated in Fig.7, where a static scenario, i.e., without vUEs leaving and joining, is considered. In this case, we can see that the average collision probability decreases throughout all the simulation period. This is because after some collisions at the beginning of the simulation, which are caused by a random initialization of the UEs resources, there are no more collisions.

## V. SUMMARY AND FUTURE WORK

In this work, we present the advances within 3GPP standardization body regarding enhanced vehicular-to-everything (eV2X) communications services, which is actually a step towards 5G vehicular communications. First, the SL D2D communications technology for V2X services is presented known as modes 3 and 4 giving details about the baseband processing and the resource allocation. Simulation results of the link-level simulator are obtained in terms of achievable BLER for different payload sizes, SNRs and modulation types. In
<figure><img src="image_8.png" /><figcaption>Fig. 7. Average collision probability in static scenario: standardized vs proposed approaches.</figcaption></figure>

the sequel, a system-level simulator is presented assuming the semi-persistent scheduling (SPS) approach proposed within 3GPP. Performance evaluation in terms of collision probability is carried out showing the trade-offs using different parameters. Taking into account the 5G eV2X service requirements, we propose a cooperative ultra-reliable resource allocation and scheduling approach that will be presented in more detail for different 5G V2X use cases in our future work.

## ACKNOWLEDGEMENT

The research leading to these results has been performed in the SafeCOP project, that received funding from the ECSEL

Joint Undertaking under grant agreement no. 692529, and from National funding.

## REFERENCES

[1] 3GPP TR 22.886, "Study on enhancement of 3GPP Support for 5G V2X Services", v15.1.0, Mar. 2017.

[2] H. Seo, K-D. Lee, S. Yasukawa, Y. Peng and P. Sartori, "LTE Evolution for Vehicle-to-Everything Services", IEEE Communi. Magazine, vol. 54, no.6, pp. 22-28, Jun. 2016.

[3] E. Uhlemann, "Initial Steps Toward a Cellular Vehicle-to-Everything Standard", IEEE Veh. Technol. Magazine, vol. 12, no. 1, pp. 14-19, Mar. 2017.

[4] 5G Automotive Association, "5G Automotive Vision", White Paper, Oct. 2015.

[5] Y. Lan Tseng, "LTE-Advanced Enhancement for Vehicular Communication", IEEE Wirel. Communications, vol. 22, no. 6, pp. 4-7, Dec. 2015.

[6] S-Yu Lien, C-C. Chien, G Shu-Tsz Liu, H-L. Tsai, R. Li and Y. J. Wang, "Enhanced LTE Device-to-Device Proximity Services", IEEE Communi. Magazine, vol. 54, no. 12, pp. 174-182, Dec. 2016.

[7] 3GPP RP-161788, V2V Work Item Completion, Sept. 2016.

[8] C. Campolo, A. Molinaro, G. Araniti and A. O. Berthet, "Better Platoon-ing Control Toward Autonomous Driving: An LTE Device-to-Device Communications Strategy That Meets Ultralow Latency Requirements", IEEE Veh. Tech. Magazine, vol. 12, no. 1, pp. 30-38, Mar. 2017.

[9] S. H. Sun, J. L. Hu, Y. Peng, X. M. Pan, L. Zhao and J. Y. Fang, "Support for Vehicle-to-Everything Services Based on LTE", IEEE Wireless Communications, vol. 23, no. 3, pp. 4-8, Jun. 2016.

[10] Zarrinkoub, Houman. Understanding LTE with MATLAB: from mathematical modeling to simulation and prototyping. John Wiley & Sons, 2014.

[11] 3GPP, Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification (Release 14), TS 36.321 V14.4.0, Sept. 2017.

[12] 3GPP, Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 14), TS 36.213 V14.4.0, Sept. 2017.