A Blockchain-Empowered Platoon Communication
Scheme for Vehicular Safety Applications
Liu Cao, Hao Yin
Abstract—The integration of blockchain in vehicular net-
works is becoming the backbone for securing intelligent and
autonomous vehicles. Besides security, vehicles are also able to
enhance their communication performances by expanding the
services with blockchain technology. In this paper, we propose
2021 IEEE 94th Vehicular Technology Conference (VTC2021-Fall) | 978-1-6654-1368-8/21/$31.00 ©2021 IEEE | DOI: 10.1109/VTC2021-FALL52928.2021.9625342
a novel blockchain-empowered platoon communication scheme
for vehicular safety applications. Decentralized vehicles first
form into a platoon assisted by a pre-established blockchain-
based security system. The platoon communication is then
utilized to update the resource scheduling scheme enabled by
the blockchain on the attending vehicles. In addition, to reduce
the communication overhead, we further propose an adaptive
block generation period (ABGP) algorithm based on the esti-
mated resource occupancy percentage. Monte Carlo simulation
is employed to compare the results between the proposed scheme
and the semi-persistent scheduling (SPS) scheme specified by
the current standard. Numerical results show that the proposed
scheme outperforms the SPS scheme by decreasing the collision
probability at least 40% while reducing the average scheduling
delay by at least 30%.
Index Terms—blockchain, platoon communication, 5G NR
V2X, resource scheduling.
I. I NTRODUCTION
With the rapid evolution in wireless communications and au-
tonomous vehicles, Vehicle to Everything (V2X) has evolved
by integrating cellular 5G New Radio (NR) technology in V2X
communication (i.e., 5G NR V2X) [1]. However, the existing
V2X communications are vulnerable due to the sensitive data
sharing between the intelligent vehicles [2], [3], which is
thereby hard to satisfy the security requirements of intelligent
vehicular systems such as traceability, transparency, resilience,
and immutability [4].
To cope with the data safety and security under V2X
communications, decentralized methods catch great attention
recently. Blockchain, a promising technique that originated
from Bitcoin [5], contributes to fulfilling the above require-
ments by building trust among the peer vehicular nodes in a
trustless environment without the presence of a central author-
ity. The participating vehicles can use the event information
stored in the blockchain and act accordingly, by treating the
information stored in the blockchain as the ground truth.
Various research has been done on integrating blockchain
into intelligent vehicles for security purposes, especially for
establishing trustworthy vehicular networks. Yang et al. in
[6], [7] proposed a decentralized trust management system
in vehicular networks with blockchain, and Literature [8]
investigated blockchain-enabled Internet of vehicles for secure
Liu Cao, and Hao Yin are with Department of Electrical & Computer
Engineering, University of Washington, Seattle, WA, USA (e-mail:{liucao,
haoyin}@uw.edu).
978-1-6654-1368-8/21/$31.00 ©2021 IEEE
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on March 17,2024 at 11:39:45 UTC from IEEE Xplore. Restrictions apply.
Peer-To-Peer (P2P) vehicle data sharing. A practical and
reliable security scheme for 5G-VANETs was presented in [9]
to handle the trust management while preserving user privacy
at the same time. In [10], the authors formulated an efficient
decentralized key management mechanism to build a security
framework in VANET with blockchain technology.
With the services of blockchain technology in the vehicular
networks, it is possible for decentralized vehicles to form into
a group together to increase the capacity of roads via an
automated highway system, i.e., vehicle platooning, which is
one of the V2X advanced services specified by 3GPP Release
16 (5G phase) [11]. Generally speaking, a vehicle platoon
system consists of a platoon leader (PL) taking control of
the group and other platoon members (PMs) following the
PL. All vehicles in a platoon are able to exchange driving
information and communicate by means of groupcast mode. In
traditional ways, a platoon is formed in advance and a vehicle
intending to join the platoon has to obtain permission from the
PL. Besides, vehicles from different manufacturers may not
have permissions to join the platoon. However, with support
of blockchain technology, vehicles can form into a platoon in
a decentralized way without previous limitations. Moreover,
intelligent connected vehicles are normally equipped with
large computing power, which has a considerable amount of
spare resources in the platoon for using blockchain technology.
Safety-related applications of future connected vehicles are
based on the periodic exchange of vehicular status called the
Basic Safety Messages (BSMs) [12], [13]. These messages aim
to assess potential road hazards by announcing the presence
of a vehicle to other surrounding vehicles. To avoid packet1
collisions, the NR-V2X sidelink Mode 2 [1] is deployed in
the out-of-coverage scenario. However, the current resource
scheduling scheme - sensing-based semi-persistent schedul-
ing (SPS) scheme that sidelink Mode 2 adopts, cannot still
effectively decrease packet collisions within a decentralized
vehicular network. Enabled by the blockchain technology,
the decentralized vehicles are able to exchange the BSMs
after joining a platoon, which improves their communication
performances by taking advantage of the transactions that
happened in the blockchain system. In this paper, we propose
a novel resource scheduling algorithm empowered by the
blockchain system to improve the communication performance
of NR sidelink. The major contributions of this paper are
summarized as follows:
• We investigate a blockchain-empowered platoon com-
munication scheme for the vehicular safety applications
in the out-of-coverage scenario. With the assistance of
1 In this paper, BSM is also referred to as ’packet’.
 blockchain technology, decentralized vehicles can form Blockchain
into a platoon, meanwhile, the communication perfor-
Header
mance of whole platoon system can also improve con- Prev- Hash Merkle root
siderably. GMT time Signature
• We propose an adaptive block generation period (ABGP) Overall bitmap
1
algorithm which is based on the estimated resource 1
0
occupancy percentage, to effectively reduce the commu- Block 3

...
Block 1
1
nication overhead.
Block 2
Algorithm 1
The rest of this paper is organized as follows. Section
Sensing result from a platoon vehicle
II introduces the SPS scheme and the blockchain structure Freq. (Hz)
used in our proposed scheme. The detailed designs of our
subchannel 1 Occupied VRB
proposed scheme are presented in Section III, which includes 1
the main procedures and related algorithms. In Section IV, we 0
... Idle VRB
Lbm bits

...

...
0
conduct Monte Carlo simulations to verify the effectiveness of

...
1
our proposed scheme by comparing the SPS scheme. Finally, nr Lb m
Individual bitmap for one
section V draws the conclusions for this paper. transmi ssion period
1 slot Time (ms)
One transmiss ion period (Ttr )

II. S YSTEM A RCHITECTURE Fig. 1: Blockchain structure.

A. Overview of SPS
Algorithm 1: Overall bitmap Ok with its occupancy
Each vehicle adopts the sensing-based SPS scheme [14], percentage POk in the k th block generation period.
[15] to exchange BSMs in NR-V2X sidelink. The channel is
Data: A bitmapnlist
divided into ts ms slot and nr sub-channels with a set of o
resource blocks (RBs) comprised of a group of orthogonal BM k = bmk1 , bmk2 , bmk3 , ..., bmkNp consists
frequency division multiple access (OFDM) tones [16]. Each of bitmaps generated by Np platoon vehicles in
vehicle periodically generates BSMs every Ttr ms, denoted the k th block generation period.
as one transmission period. Each transmission period contains Result: Ok and POk
Nr virtual resource blocks (VRBs), and each VRB contains idx = 1;
consecutive RBs for supporting one BSM transmission within Ntx>0 = 0;
a slot. In the same slot, we assume that the resources can Ok = {};
support a fixed number of BSM transmissions, i.e., we can while idx ≤ Lbm do
view the resources in one slot can be divided into nr VRBs. A PNp
if m=1 bmkm (idx) > 0 then
vehicle reserves the resources for a SPS period containing Ts
consecutive transmission periods. When a SPS period ends, a OV RB = 1
new idle VRB must be selected and reserved with probability else
OV RB = 0
1 − p, where p is the resource-keeping probability. In other
words, each vehicle keeps the previous VRB with probability Ntx>0 = Ntx>0 + OV RB ;
p in the next SPS period, even if a collision occurs, since Ok = {Ok , OV RB };
there is no ACK/NACK when broadcasting BSMs. Suppose idx = idx + 1;
that a vehicle needs to select a new VRB at time T . It can POk = Ntx>0 /Lbm ;
reserve subchannels between T and the established maximum
latency Ttr . This period is referred to as the selection window.
Accordingly, the total number of VRBs that each vehicle can B. Blockchain with DPoS
select within the selection window with the size equal to W
is given by Among all consensus schemes, Delegated Proof-of-Stake
W nr (DPoS), a non-computational intensive, scalable, and high-
Nr = , (1) efficiency algorithm, is particularly desirable for establishing
ts
blockchain-enabled Internet of Vehicles (BIoVs) [17], [18].
where W ≤ Ttr − T . T is assumed to be 0, i.e., the vehicle Notably, the mechanism of DPoS enables the PL to acquire
can select a VRB right after the packet generation. information from attending vehicles with different locations.
Each time when a vehicle wants to select a new idle VRB, We thus design a blockchain with DPoS for the proposed
it will randomly select one of idle VRBs with the lowest 20% scheme. As shown in Fig. 1, each block is of the same format
of transmit power within the selection window, sensed from and consists of a header and a body. In accordance with the
the last transmission period. In the MAC-layer perspective, all traditional DPoS consensus scheme, the header contains the
vehicles only sense whether each VRB is occupied over the reference to its previous block, the current GMT time, the
last transmission period, and are synchronized in terms of the Merkle root, and a signature that uses the private key of
transmission period. the miner. For a block to be valid, its signature has to be

Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on March 17,2024 at 11:39:45 UTC from IEEE Xplore. Restrictions apply.
 1. Platoon Initialization 2. Block Generation
Platoon group Platoon group
Miner group Miner group
Store of Miner d: Miner b: Miner d: Miner b:
reputation values

Miner a: Miner c: Miner a: Miner c:

PM PL Denied Vehicle RSU Block generation period k Block generation period k+1
V2I communication Platoon communication Block generator Block verifier Unverified block

3. Block Verification 4. Scheduling Scheme Update

Miner group
Miner d: Miner b: VRB 12
... ... Algorithm 2 VRB 64
Unverified Local overall VRB 100
P VRB 113
overall bitmap bitmap P Download the latest
1 1 overall bitmap VRB 187
1 1 S
...
...

S 1 2 3
1 1 S Platoon group
...
...

Miner a: P Miner c:
0 0 4 5
1 1
P Pos itive reply S Signature
Block generation period k New scheduling scheme

Fig. 2: The procedures of proposed scheme.

valid. The body contains a transaction list which is an overall
bitmap reflecting the recent VRB occupancy of platoon. The
overall bitmap, based on the bitmaps generated by all Np
platoon vehicles in the platoon, is obtained through Algorithm
1, where each individual bitmap is the sensing result from
each platoon vehicle over the last transmission period. Each
bit in the bitmap indicates the occupancy of one VRB, and
the bit order in the bitmap aligns with the VRB index in a
transmission period, e.g., if one VRB, denoted as V RBn , is
occupied, the nth bit in the bitmap is set to 1, otherwise, it is 0.
Therefore, the number of bits in a bitmap, Lbm , should be the
total number of VRBs that one transmission period contains,
which can be expressed as
Ttr nr
Lbm = . (2)
ts
Ensuring that each platoon vehicle generates a bitmap in
a block generation period, the platoon size should not be
greater than the number of transmission periods that one block
BGP
generation period contains, i.e., Np ≤ Ntr . Note that, the
Np bitmaps are required to be generated in turn in the first
Np transmission periods in each block generation period, in
BGP
particular, if Np < Ntr , no bitmap will be generated in the
following Ntr BGP
− Np transmission periods.
III. D ETAILED D ESIGN OF THE P ROPOSED S CHEME
As illustrated in Fig. 2, the proposed scheme includes the
following procedures.
Procedure 1. Platoon Initialization: Vehicles that plan to
join a platoon first initialize the connection with each other.
During the initialization process, Road-Side Units (RSUs) are
employed as the pre-established blockchain-based reputation
management system [6], [7], where vehicles generated ratings
for others and uploaded these ratings into the nearby RSU in
the past. Each vehicle can send request to an RSU to query
the historical reputation values of other vehicles during the
initialization process. To avoid the malicious vehicles joining
the platoon, vehicles with reputation values below a threshold,
are not allowed to join the platoon. After forming a platoon,
the vehicle with the highest reputation value in the platoon is
automatically selected as the PL while the remaining vehicles
in the platoon serve as the PMs. The SPS scheme is no longer
to be applied for platoon vehicles to exchange the BSMs,
instead, the proposed scheduling scheme is then deployed for
vehicular safety applications.
Procedure 2. Block Generation: Each platoon vehicle, as
a stakeholder, votes for M candidates (M ≤ Np ) as the
miners according to its ranking (the reputation values) for
the candidates. All the stakeholders have the same weight in
miner voting. After summarizing all the voting results, the
top M miner candidates with the highest reputation values
are selected to be the miners. Since the reputation value of
PL is the highest in the platoon, PL must be one of the
selected miners. Each miner is then responsible to serve as a
block generator in turn, i.e., each miner is required to generate
BGP
a block every M Ntr transmission periods. In a block
generation period, only one miner generates an unverified
block and then broadcasts this block to other block verifiers.
In the next block generation period, this miner becomes a
verifier, and one of the other miners takes over to generate a
new block. For instance, as shown in Fig. 2, the current miner
group is composed of miner a, b, c and d. In the k th block

Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on March 17,2024 at 11:39:45 UTC from IEEE Xplore. Restrictions apply.
generation period, miner a generates block B1 while miners Algorithm 2: Update for the scheduling information
b, c and d act as the verifiers. Next, in the (k + 1)th block V k in the k th block generation period.
generation period, miner b generates block B2 while a, c and Data: Ok , TP Gn= t1 , t2 , ..., tNp , o

d act as the verifiers.
V k−1 = v1k−1 , v2k−1 , ..., vN k−1
,
Procedure 3. Block Verification: After receiving an unver- n o p
N
ified block, each verifier has to compare the overall bitmap ck(Np ) = 11c , 12c , ..., 1c p
in the block with its local overall bitmap. As Fig. 2 shows, Result: The updated VRB index set V k
after miner a generates block Bk including the overall bitmap
in the k th block generation period, the verifier d will check idx = 1;
whether each bit in its own overall bitmap corresponds with while idx ≤ Np do
the bit in the overall bitmap in the block. If the overall bitmap if ck(Np ) (idx) == 0 then
k k−1
is correct and complete, the verifier d will send a positive vidx = vidx ;
reply with its signature to miner a. Otherwise, it will send else
∗
a negative reply. Next, miner a analyzes the received replies k
vidx = arg min{⌈ nv r ⌉ − tidx }
v∗
from all verifiers. If more than two-third of them are positive, ( ∗
miner a will send the audited block with the corresponding ⌈ nv r ⌉ − tidx ≥ 0,
s.t. ;
signature to all verifiers for storage after checking. This block Ok (v ∗ ) == 0
is then formally chained to the blockchain. However, if miner
a fails to generate a valid block in its turn, this unverified Ok (vidx
k
) = 1;
block will be discarded, and a new block will be generated idx = idx + 1;
by the next miner in the next block generation period. In the
next round, the block can be still chained to the blockchain if
miner a generates a valid block in its turn.
Procedure 4. Resource Scheduling Scheme Update: The estimated VRB occupancy can be, which thus leads to a lower
BGP
resource scheduling scheme includes two sections: (a) the collision probability. However, a small Ntr will increase the
scheduling information for each platoon vehicle, and (b) unnecessary overhead for the whole platoon system. To tackle
the number of transmission periods, Ntr BGP
, that a block with this problem as well as take the advantage of bitmap
generation period contains. After a new block is chained to the information, we propose an adaptive block generation period
blockchain in the current block generation period, as shown in (ABGP) algorithm, i.e., the number of transmission periods
ABGP
Fig. 2, PL is then able to see a valid overall bitmap that reflects Ntr that an ABGP contains in the k th block generation
the recent VRB occupancy. Subsequently, PL updates the period is expressed in Eq (3), where POk ∈ [0, 1] is the VRB
resource scheduling of each platoon vehicle by analyzing the occupancy percentage obtained in Algorithm 1, α and β are
recent VRB occupancy in the (Np )th transmission period, and the correction terms (here α ≥ 10 and β ∈ (0, 1)), controlling
the scheduling information is then updated through platoon the shape of curve in the range of POk . NLB is the lower
ABGP
communication. The scheduling information update rule is bound of Ntr , and NOS is the offset to determine the
ABGP
shown in Algorithm 2, where Ok is the valid overall bitmap upper bound, i.e., a large POk should lead Ntr to be NLB
ABGP
in the k th block generation period, TP G is the set of the while Ntr should be NOS +NLB with a small POk . With
ABGP
known packet generation time of each platoon vehicle, with possible traffic load change at sometime, Ntr should be
each falling into a slot in a transmission period, ranging from also updated every K block generation periods. In addition, to
1 to Ttr . V k−1 is the set of VRB indexes that each platoon align with the sensing time being 1000ts from a prospective of
vehicle selects in the (k − 1)th block generation period, and PHY-layer specified by the standard [14], NLB should satisfy
ck(Np ) is a set of collision indicators of platoon vehicles in the NLB ≥ ⌈ 1000t
Ttr ⌉.
s

(Np )th transmission period during the k th block generation

period. In Algorithm 2, we consider improving the freshness
of the transmitted BSMs. During the k th block generation
period, PL schedules the closest idle VRB right after the
packet generation time of each platoon vehicle only if a
packet collision happens for this platoon vehicle in the (Np )th
transmission period, otherwise, PL will stick with the same
VRB as the (k − 1)th block generation period for this platoon
vehicle.
BGP
In general, the smaller Ntr is, the more accurate the
IV. S IMULATION
In this section, we conduct Monte Carlo simulation under
static vehicle distribution to compare the performance of the
SPS scheme and our proposed scheme. In each experiment,
the location of each vehicle is determined by a uniformly
distributed random variable with the maximum value of road
length. In addition, the target vehicles are located near the
middle of the road, to avoid the edge effect of hidden termi-
nals. Next, we conduct 50 different experiments to average the

  
 1− 1
ABGP
· NOS + NLB , mod(k, K) = 1
Ntr (POk ) = 1 + exp {−α · (POk − β)} (3)
 ABGP
Ntr (POk−1 ), else

Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on March 17,2024 at 11:39:45 UTC from IEEE Xplore. Restrictions apply.
results. Table I articulates the simulation parameters for both 0.6

schemes while Table II provides the parameters of ABGP used analysis - SPS
in the simulation of our proposed scheduling scheme. 0.5
simulation - SPS
simulation - minimal collision based
simulation - ABGP

TABLE I: Simulation Parameters 0.4

Collision probability
Parameters Value
0.3
Platoon size, Np 10
Number of miners, M 10 0.2

Road length (km) 4

Resource keeping probability, p 0.8 0.1

Communication range (km) 0.4

0
Vehicle density, ρ (vehicles/km) {50,100,...,250} 50 100 150
Vehicle density (vehicles/km)
200 250

Transmission periodicity, Ttr (ms) 100

Number of sub-channels, nr 4 Fig. 3: Collision probability.
Duration of one slot, ts (ms) 1
Selection window size, W (ms) 2
0.6
Number of transmission periods
10
in each SPS period, Ts
0.5
Number of one simulation run,
4000

Average scheduling delay (ms)

transmission periods 0.4
simulation - SPS
simulation - minimal collision based
simulation - ABGP
0.3

TABLE II: Parameters of ABGP

0.2
Parameters Value
α 8 0.1

β 0.4
N1 100 0
50 100 150 200 250
Vehicle density (vehicles/km)
N2 10
K 600
Fig. 4: Average scheduling delay.

A. Collision probability comparison

We first compare the collision probability between the SPS
scheme and our proposed scheme with the ABGP algorithm
in different traffic loads. We also provide a minimal collision-
BGP
based case where Ntr is set to be 10 (equal to Np ) in the
proposed scheme. Moreover, to validate the simulation results
of SPS scheme, an analytical model in [19] is referenced. As
Fig. 3 shows, the simulation result of SPS scheme matches
quite well with its analytical result. Among them, the collision
probability in the SPS scheme is the highest while being
the lowest in the minimal collision-based case. As mentioned
BGP
in procedure 4, since Ntr in the minimal collision-based
case is always less than that with the ABGP algorithm, the
corresponding collision probability should be lower than the
ABGP algorithm.
Unlike the SPS scheme where each vehicle can only acquire
its own sensing information over one transmission period, the
proposed scheme periodically collects the sensing information
of platoon vehicles, which lasts up to Np consecutive trans-
mission periods, letting PL not only see some hidden terminals
of platoon vehicles but also acquire more information about
the recent VRB occupancy. Therefore, the collision probability
in the proposed scheme with the ABGP algorithm can be
significantly lower than the SPS scheme, which at least lowers
the collision probability by 40% and 50% in low and high
traffic loads, respectively.
B. Average scheduling delay comparison
Afterward, we analyze the average scheduling delay be-
tween the two schemes. The scheduling delay is defined as the
queuing time at the transmitter before a packets is sent. Note
the delay not only comes from the queuing time but also comes
from the slot the scheduler decided to send the packet. As is
seen in Fig. 4, the average scheduling delay in the SPS scheme
is quite stable in each vehicle density while becoming larger
as the vehicle density increases in the proposed scheme. In the
SPS scheme, we also consider reducing the average scheduling
delay by shortening the selection window, i.e., each vehicle
randomly chooses one of the idle VRBs within the selection
window with W = 1 ms right after the packet generation.
Therefore, the estimated average scheduling delay should be
around 0.5 ms no matter what the traffic load is. By contrast,
since each platoon vehicle selects the closest idle VRB after
the packet generation, the average scheduling delay goes to 0
in low traffic loads while getting larger in high traffic loads.
Nevertheless, the average scheduling delays in both cases in
the proposed scheme are still lower than the SPS scheme. This
is because the closest VRBs are more likely to be selected
in the proposed scheme. Moreover, the average scheduling
delay with the ABGP algorithm is lower than that with the
minimal collision-based case in high vehicle densities. Since
the collision probability with the ABGP algorithm is higher

Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on March 17,2024 at 11:39:45 UTC from IEEE Xplore. Restrictions apply.
 TABLE III: Communication overhead comparison.
BGP
Ntr Number of sensing per minute Average added overhead (Bytes)
Vehicle density
Minimal collision ABGP SPS Minimal collision ABGP SPS Minimal collision ABGP
50 vehicles/km 10 97 60 60 6 0 5.6 0.58
100 vehicles/km 10 77 60 60 7 0 5.6 0.73
150 vehicles/km 10 53 60 60 11 0 5.6 1.06
200 vehicles/km 10 31 60 60 19 0 5.6 1.81
250 vehicles/km 10 21 60 60 28 0 5.6 2.67

compared with the minimal collision-based case, each platoon R EFERENCES

vehicle with the ABGP algorithm is more frequently scheduled
to select the closest idle VRB.
C. Communication overhead comparison
Furthermore, we compare the communication overhead. As
BGP
the Table III shows, Ntr with ABGP algorithm is almost
BGP
ten times as large as Ntr in 50 vehicles/km while being
BGP
twice of Ntr in 250 vehicles/km in the minimal collision-
BGP
based case. Therefore, with a larger Ntr , the number of
sensing of each platoon vehicle with the ABGP algorithm
will be reduced accordingly. On the other hand, the number
of sensing of each vehicle in the SPS scheme should be the
same as the minimal collision-based case as Ts = 10 in the
simulation. In addition, the average added overhead 2 is also
BGP
compared. Since Ntr is fixed in each vehicle density in
the minimal collision-based case, the average added overhead
is also fixed. Meanwhile, the average added overhead with
the ABPG algorithm is significantly reduced, particularly, the
average added overhead with the ABPG algorithm is only
one-half of that in the minimal collision-based case in high
vehicle density. Note that a vehicle does not generate any
added overhead in the SPS scheme, i.e., the average added
overhead is 0 in each vehicle density.
V. C ONCLUSION
In this paper, we proposed a blockchain-empowered pla-
toon communication scheme to improve the communication
performance of vehicular safety applications in NR sidelink
mode. With the assistance of a pre-established blockchain-
based vehicular reputation management system, decentralized
vehicles first form into a platoon system, and the platoon
communication is adopted to periodically update the resource
scheduling scheme enabled by the blockchain on the attending
vehicles. Moreover, to effectively reduce the communication
overhead, we thereby proposed an adaptive block generation
period (ABGP) algorithm based on the estimated resource
occupancy percentage. Simulation results have demonstrated
that the proposed scheme outperforms the SPS scheme by
decreasing the collision probability as well as reducing the
average scheduling delay.
2 If the block size is n
bk bytes while the bitmap size is nbm bytes, the
n +(M −1)nbm
average added overhead is calculated by bk BGP . In the simulation,
M Ntr
the block size is assumed to be 110 bytes, and the bitmap size is 50 bytes.
[1] 3GPP, “Study on NR Vehicle-to-Everything (V2X),” The 3rd Generation
Partnership Project (3GPP), Tech. Rep. TR38.885, Mar 2019.
[2] J. H. Park and J. H. Park, “Blockchain security in cloud computing: Use
cases, challenges, and solutions,” Symmetry, vol. 9, no. 8, p. 164, 2017.
[3] S. Kim, “Blockchain for a trust network among intelligent vehicles,” in
Advances in Computers. Elsevier, 2018, vol. 111, pp. 43–68.
[4] R. Shrestha, S. Y. Nam, R. Bajracharya, and S. Kim, “Evolution of
V2X communication and integration of blockchain for security enhance-
ments,” Electronics, vol. 9, no. 9, p. 1338, 2020.
[5] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”
Manubot, Tech. Rep., 2019.
[6] Z. Yang, K. Zheng, K. Yang, and V. C. Leung, “A blockchain-based
reputation system for data credibility assessment in vehicular networks,”
in 2017 IEEE 28th annual international symposium on personal, indoor,
and mobile radio communications (PIMRC). IEEE, 2017, pp. 1–5.
[7] Z. Yang, K. Yang, L. Lei, K. Zheng, and V. C. Leung, “Blockchain-based
decentralized trust management in vehicular networks,” IEEE Internet
of Things Journal, vol. 6, no. 2, pp. 1495–1505, 2018.
[8] J. Kang, Z. Xiong, D. Niyato, D. Ye, D. I. Kim, and J. Zhao, “Toward
secure blockchain-enabled internet of vehicles: Optimizing consensus
management using reputation and contract theory,” IEEE Transactions
on Vehicular Technology, vol. 68, no. 3, pp. 2906–2920, 2019.
[9] L. Xie, Y. Ding, H. Yang, and X. Wang, “Blockchain-based secure
and trustworthy Internet of Things in SDN-enabled 5G-VANETs,” IEEE
Access, vol. 7, pp. 56 656–56 666, 2019.
[10] Z. Ma, J. Zhang, Y. Guo, Y. Liu, X. Liu, and W. He, “An efficient de-
centralized key management mechanism for VANET with blockchain,”
IEEE Transactions on Vehicular Technology, vol. 69, no. 6, pp. 5836–
5849, 2020.
[11] 3GPP, “Study on enhancement of 3GPP support for 5G V2X services,”
The 3rd Generation Partnership Project (3GPP), Tech. Rep. TR22.886,
Dec 2018.
[12] X. Wang and R. A. Berry, “MAC trade-offs between age and reachability
of information in vehicular safety applications,” in IEEE INFOCOM
2020-IEEE Conference on Computer Communications Workshops (IN-
FOCOM WKSHPS). IEEE, 2020, pp. 689–695.
[13] L. Cao, H. Yin, J. Hu, and L. Zhang, “Performance analysis and
improvement on DSRC application for V2V communication,” in 2020
IEEE 92nd Vehicular Technology Conference (VTC2020-Fall). IEEE,
2020, pp. 1–6.
[14] 3GPP, “Evolved universal terrestrial radio access (E-UTRA); physical
layer procedures,” The 3rd Generation Partnership Project (3GPP), Tech.
Rep. TR36.213, Dec 2020.
[15] ——, “Evolved universal terrestrial radio access (E-UTRA); medium
access control (MAC) protocol specification,” The 3rd Generation Part-
nership Project (3GPP), Tech. Rep. TR36.321, Dec 2020.
[16] H. Yin, L. Zhang, and S. Roy, “Multiplexing URLLC traffic within
eMBB services in 5G NR: Fair scheduling,” IEEE Transactions on
Communications, vol. 69, no. 2, pp. 1080–1093, 2020.
[17] Y. Ji, R. Hou, K.-S. Lui, and H. Li, “A blockchain-based vehicle
platoon leader updating scheme,” in ICC 2020-2020 IEEE International
Conference on Communications (ICC). IEEE, 2020, pp. 1–6.
[18] Y. Yuan and F.-Y. Wang, “Towards blockchain-based intelligent trans-
portation systems,” in 2016 IEEE 19th International Conference on
Intelligent Transportation Systems (ITSC). IEEE, 2016, pp. 2663–2668.
[19] X. Wang, R. A. Berry, I. Vukovic, and J. Rao, “A fixed-point model for
semi-persistent scheduling of vehicular safety messages,” in 2018 IEEE
88th Vehicular Technology Conference (VTC-Fall). IEEE, 2018, pp.
1–5.

Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on March 17,2024 at 11:39:45 UTC from IEEE Xplore. Restrictions apply.