Keywords

1 Introduction

In the 21st century century, we have witnessed the development and advancement of new astonishing technologies, which have deeply influenced human life in numerous ways by making it more convenient, comfortable, and easy. Intelligent Transportation System (ITS) have rapidly developed into a highly relevant field of its own, inspired and motivated by the constant development in wireless technologies such as cellular and ad hoc networks. Vehicular networking IEEE 802.11p (Direct Short Range Communication) and 3rd Generation Partnership Project (3GPP) Vehicle-to-Everything (C-V2X) have primarily focused on improving the vehicular and road safety and efficiency and they also support/enable entertainment services in vehicular networks. 3GPP introduced an initial version of C-V2X communication to use cellular communication in Release 14, where intelligent vehicles act as mobile devices. DSRC (Direct Short Range Communication) is normally used in a vehicular ad hoc network (VANET) and is particularly a kind of mobile ad hoc network (MANET). A potential alternative to DSRC could be to use cellular technology for vehicular communication. DSRC and cellular networks can be used together in a hybrid mode, as seen in Fig. 1. Vehicular communication provides an up-to-date road weather information, precollision warning, and improves the traffic management system, as seen in Fig. 1 [1, 2].

Fig. 1
figure 1

Vehicle to RWS and vehicle to cloud (DSRC communication)

Full size image

The growing importance of data in vehicular networks underline the necessity of understanding the impact of mobility protocols and the mobile environment on the performance of ITS applications. Certainly, this requirement is extensively acknowledged by the vehicular networking research community with a plethora of recent research dealing with numerous aspects of measuring, characterizing and improving data performance on VANET and cellular networks (e.g., C-V2X) using Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) [3].

Vehicular Communication can be categorized into three types: Vehicle-to-Infrastructure (V2I), Vehicle-to-Vehicle (V2V) and Vehicle-to-Broadband Cloud (V2B) [4].

  • V2V: It provides a platform for vehicles to exchange road weather information and warning messages for driver assistance.

  • V2I: It provides a communication link between vehicle and road weather station considering environmental sensing and monitoring. It provides real time weather information and traffic updates for drivers.

  • V2B: It provides a communication link between vehicles and management center via road weather stations. In V2B, vehicles may communicate via wireless broadband 4G/5G. The broadband cloud could include the traffic and monitoring data as well as infotainment data for vehicle tracking and real-time driver assistance.

In Fig. 1, we can see the architecture of the vehicular network; V2V and V2I scenarios as VANET and cellular networking. V2I and V2V communications are established by using DSRC (802.11p)/cellular network (5G), and V2B communication uses the cellular wireless broadband that offers high-speed wireless access [4]. This fusion of VANET and cellular networking is called hybrid communication; and in this case, we consider a cellular network (5G test network) and DSRC (IEEE 802.11p). We have implemented this approach in our test network in Sodankylä, Finland. In vehicular communication, the transmission protocols at the transport layer are used for end-to-end data transmission called UDP and TCP. TCP offers a connection-oriented communication with the mechanisms of rate adaptation and assisting end-to-end transfer of application data through numerous IP hops and requires bidirectional communication between hops for acknowledgments. Nevertheless, UDP does not have any error retrieval mechanism [5], and on the contrary the TCP, it uses the retransmission technique to recover the lost data making the communication reliable efficiently. TCP has a drawback compared to UDP that its reliability mechanism increases the transmission delay of the data in case of packet loss, which will be discussed later in this chapter [3, 4].

The Finnish Meteorological Institute (FMI) has devised and implemented a large set of pilot use-cases for this purpose for both IEEE 802.11p and 5G test networks. In this chapter, we have compared the transport layer in vehicular communications (V2V & V2I) by exploiting the road traffic information. Our pilot measurements evaluated and compared UDP and TCP to choose, which could be the most suitable and adequate mode of vehicular communication using IEEE-802.11p and 5G test network [5]. Multiple performance evaluation metrics are used in this work such as throughput, packet loss percentage, average packet/s, average packet size, latency, data rate and jitter. The rest of the chapter is organized as follows. In Sect. 2, we present the ITS-related work with DSRC and cellular network. Section 3 demonstrates an overview of ITS protocol architecture i.e., UDP and TCP. In Sect. 4, we present the pilot scenarios for the IEEE 802.11p and 5G test network considering TCP and UDP at the transport layer in vehicular networking. Section 5 presents the analysis of the results, while Sect. 6 ends up with the conclusion of this chapter.

2 Intelligent Transportation System (ITS) with Cellular (5G) and DSRC (IEEE 802.11p)

The term Intelligent Traffic System (ITS) refers to the idea of incorporating transport infrastructure and vehicles with the latest communications technology. This combination plays an important role in better management of the current transport systems so that they function and operate more efficiently and effectively, as presented in Fig. 2.

Fig. 2
figure 2

Future Intelligent Transportation System (ITS)

Full size image

Currently, new technological advancement in traffic management systems includes different control instruments and sensors. These instruments, extensively deployed on the roads and highways, provide road weather information, traffic jam alerts, speed limit, traffic signals, and accident warnings. Among other things, ITS aims at providing assistance in the design and development of the latest traffic monitoring framework, being able to make run-time decisions about the traffic modeling structure with best available substitute route, to illustrate the control system [4, 5]. Within the framework, traffic devices and sensors can be demonstrated as intelligent agents connected to centralized data base with communication to the external traffic environment. Developing techniques in machine learning (ML) and artificial intelligence (AI) have assisted the latest advances in an intelligent control by optimal decision-making through intelligent agents that can adapt their behavior conferring to a developed information base.

In ITS, the vehicular communication system delivers cooperative services related to road weather and road safety alerts, etc., as the ITS service alerts illustrated in Fig. 3 [6]. Vehicles equipped with advanced instruments like telematics, sensors, and cameras are typically the evolving smart vehicles. These intelligent vehicles have the capability to sense the current nearby environment and road weather situation, paving the way to the state-of the-art ITS with great safety and efficiency. Constant research and efforts are being done by numerous governing bodies, which will allow V2V, V2I, and V2B communications in new automobiles as a part of future ITS, as seen in Fig. 2.

Fig. 3
figure 3

Examples of typical ITS service alerts

Full size image

It is critical to design and develop cooperative applications making full use of vehicular networking infrastructure, which requires seamless communication in mobile environments, that is, VANET (vehicular ad hoc networking). In VANET, cooperative applications require seamless communication links among V2V, V2I, and V2B. The IEEE 802.11p standard with the licensed ITS band 5.9 GHz (5.85–5.925 GHz) has been developed and launched in 2012 for vehicular communication system. In Europe, 802.11p is used as a source for the ITS-G5 standard, providing support to the Geo-Networking protocol by European Telecommunications Standards Institute (ETSI) for European frequency bands and channels [6]. In vehicular networking, cellular communication systems offer a far better coverage by default, in contrast to VANET. 5G test network with LTE-A (Long Term Evolution—Advanced) is a foundation for vehicular cloud services in vehicular environments provided by several vehicle manufacturers. The 5G test network does not natively support direct V2V communications and particularly in the high-density vehicular environment, the network can be overloaded by beaconing signals of the vehicles. Additionally, the response time for safety hazards and required instant messaging in V2V is also a crucial issue. The most feasible solution to resolve this issue is to combine cellular network and VANET collectively to make a hybrid communication system [7, 8].

Having a hybrid vehicular network solution with the road weather infrastructure and road safety amenities would allow drivers, road management companies and the automated mechanism of vehicles having better road traffic management and to avoid accidents.

3 ITS Protocol Architecture

Every communication system has some particular considerations during the process of the designing standards. By taking into account these considerations, industry, academia and research institutions can design the standards to study and evaluate their performance for their communication system. Similarly, for ITS, we need to have some specific considerations when designing the standards for the ITS. So, that a network architecture which defines how the vehicles participating in vehicular networking and communication with the other vehicles and infrastructure (RWS).

For vehicular networking architecture, we have available ITS protocol stack structure with ETSI specifications having six layers, shown in Fig. 4. This ITS protocol model is structured by four upright layers with two parallel layers [9].

Fig. 4
figure 4

ITS protocol stack

Full size image

Based on Fig. 4 above, we present a structure of three protocol architectures: ETSI, OSI, and IEEE, as seen in Fig. 5. The ETSI and IEEE 802.11p protocol architecture is compared in reference to the OSI model. The ETSI protocol model is built on the idea to allow the use of various protocols on intermediary and lower layers. Generally, the structure of the ETSI-ITS protocol stack is introduced by Next Generation Protocol group, where the Physical and Media Access Control (MAC) layers are defined by the ITS-G5 Protocol (see ETSI ES 202 663), which is largely based on IEEE 802.11p [8]. Therefore, several possibilities for the user application requirements might be approachable to the applications of the upper layer. As an individual, the user application may need different requirements for communication, that is, reliability, delay, etc. It is generally a good idea to have a protocol like IEEE 802.11p supporting multiple protocols to satisfy the requirements of different user applications. IEEE 802.11p is built on the base of the OSI model, but IEEE 802.11p is more concentrated on the two lower layers: the network and transport layer as well as the access layer (Physical and MAC). The IEEE 802.11p permits to work outside of the Basic Service Set (BSS), providing the opportunity to have a medium access in vehicular networking with fast variability of the network because of high-speed vehicles. The IEEE 802.11p provides the advantage that the ITS node saves time in the search and selection process, but the frequency channel should be predefined in the ITS infrastructure [10].

Fig. 5
figure 5

Comparison between the ETSI/ISO, the OSI model, and the IEEE architectures. (Source: IEEE, ETSI & OSI)

Full size image

In 802.11p, the physical layer uses OFDM modulation and has a bandwidth range of 10–20 MHz. The IEEE 802.11p bit rates are available between 27/54 Mbps, but three commonly available bit rates for all the ITS-scenarios are 3, 6, and 12 Mbps. In IEEE 802.11p, the MAC layer uses the Enhanced Distributed Coordination Access (EDCA) technique, which describes four queues depending on the information priority (from high-low), AC_VI (Video), AC_BK (Background), AC_BE (Best Effort), and AC_VO (Voice). Lastly, the Decentralized Congestion Control (DCC) is used in DSRC for channel saturation [9, 10].

The below mentioned Fig. 6 illustrates the 5G test network radio protocol architecture, which is divided into two main parts, namely, the radio access and the core network. The core network, also known as nonaccess stratum (NAS), involves all the functionality required to establish the connection between external IP networks and cell towers. Each element is a distinct server that executes a particular set of functionalities. The 5G test network protocol architecture entities are mentioned below.

  • PDN-GW: The Packet Data Networks (PDN) Gateway facilitates the communication with external IP networks.

  • S-GW: The serving gateway is the mobility anchor and performs as a router by transferring data among PDN-GW and base stations.

  • MME: MEE stands for the Mobility Management Entity Controlling high-level mobile functions through handover and signaling commands. The radio access network also stated as access stratum (AS), is the module responsible for the radio connection set-up between a mobile device and Base Station (BS), called User Equipment (UE) [10, 11].

Fig. 6
figure 6

5G test network framework with protocol architecture

Full size image

The most significant layers in the 5G test network protocol stack are Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY). To maintain a connection between UE and MME using the signaling system, it has an additional layer between UE and eNodeB called Radio Resource Control (RRC). RRC is the layer that exists between eNodeB and UE that exist at the IP level (Network Layer). The relative 5G test network Framework with Protocol Architecture is shown in Fig. 6.

In IEEE 802.11p and 5G, the packets are encapsulated and transferred through the network, using the transport layer for providing a host-to-host application environment. The most common transport layer protocols are UDP and TCP. The major difference between UDP and TCP is the assurance of communication reliability; TCP is a connection-oriented protocol, while UDP is connection-less protocol. TCP is used for connection-oriented communications as it can provide acknowledgment and retransmission capabilities. To establish a connection in TCP, the protocol uses a three-way handshake (SYN, SYN-ACK, and ACK, respectively). Before a client attempts to connect with a server, the server must first bind to and listen at a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. TCP has three additional packets to establish a connection between peers and then transmits the actual data. This results in a packet header size of 20–60 bytes with TCP segment header size is 4 bytes, as illustrated in Fig. 7. The TCP has a maximum packet size of 1500 bytes and minimum packet size of 20 bytes. Furthermore, TCP also offers the benefit of a systematic transfer of data packets with error correction capability. TCP is typically used for applications that are not time-critical because of its comparative slow speed due to retransmission of lost packets [11, 12]. To terminate a TCP, four-way handshake (FIN, ACK, FIN, and ACK) is used, with each side of the connection terminating independently.

Fig. 7
figure 7

TCP and UDP segment header

Full size image

In TCP, the Nagle’s algorithm approach is used to enhance the data transfer efficiency by combining numerous small request bytes into a single TCP segment so that the ratio between header data to payload is more proficient. TCP headers take up 40 bytes and there are plenty of applications that can emit a single byte of payload. There is a combination of four algorithms, namely TCP uses to offer congestion control, congestion avoidance, fast recovery, fast retransmit and slow start. In these algorithms, the packet loss indicates the congestion and TCP will send the all change number of packets before waiting for acknowledgments for packets. These changes affect the available bandwidth, as well as alter the delays by providing source of jitter.

With the use of UDP protocol, messages/datagrams are transmitted without any prior communication setup, and UDP data packets are normally broadcast over a network to everyone who is listening on the particular UDP port. On IP-based networks, distinct network addresses are used to support UDP broadcast messages. There is not any inherited acknowledgment functionality in UDP and that is one of the reasons that UDP provides unreliable communication service. In UDP, some datagrams may be lost or arrive in an out-of-order fashion. On the other hand, it decreases the overhead with eight bytes of packet header size and the UDP segment header consists of 32 bits, as seen in the Fig. 8. UDP is comparatively fast, hence used for applications that require fast data transmissions, such as games. The above mentioned Table 1 illustrates the difference between transport layer TCP and UDP [12, 13]. In contrast of UDP, TCP has the Nagle algorithm feature that escalates the network latency, so in TCP Nagle’s algorithm approach is not beneficial for real-time applications.

Fig. 8
figure 8

Measurement scenario V2I (Vehicle-to-RWS) using TCP/UDP

Full size image
Table 1 Comparison between TCP and UDP
Full size table

4 Demonstration of Pilot Scenarios for IEEE 802.11p and 5G Test Network Using TCP and UDP

In this section, we demonstrate the operational pilot scenarios for IEEE 802.11p and 5G test network using TCP and UDP in V2V and V2I scenarios. For these pilot measurements, shown in Figs. 8 and 9, we present the two different process structures to demonstrate the detailed operational work for each V2I and V2V scenario. The Fig. 8 illustrates the V2I communication structure.

Fig. 9
figure 9

Measurement scenario V2V (Vehicle-to-Vehicle) using TCP7UDP

Full size image

The information exchange process between RWS and the vehicle system functionalities are presented as separate process structures supplemented with gray arrows representing different V2I communication functionalities. Figure 9 illustrates the V2V communication structure, the information exchange process between vehicular systems functionalities are presented as separate process structures.

Figures 8 and 9 illustrate the information process structure that is comprised of two-way communication, V2V and V2I, with a complete interaction process presented in detail. Our main objective is to fragment the vehicular communication (V2V, V2I) process structures into distinct phases, providing thus an opportunity to analyze and investigate the communication procedure. In the V2V and V2I communication process, the insertion-points enabling the communication transport layer protocols UDP/TCP in VANET or 5G test network were implemented. To get the safe, reliable, and heterogeneous vehicular networking, it is tempting to consider the use of the TCP/IP family of protocols to support ITS applications in pilot scenarios. These protocols are employed in order to select the transmission protocol with better performance at the transport layer to exchange road weather information using IEEE802.11p/5G test network.

IEEE 802.11p TCP and UDP packet captures can be seen in yellow color in Figs. 10 and 11, respectively, indicating captured packet locations from either RWS1 or RWS2. The IEEE 802.11p vehicular networking has been provided by Cohda MK5 radio transceivers. Vehicles used SUNIT-F-series vehicle PC for User Interface (UI) to investigate and evaluate the performance of IEEE 802.11p considering TCP and UDP. For the 5G test network measurements, a Samsung S7 smartphone with the SUNIT F-series vehicle user interface is used for pilot measurements.

Fig. 10
figure 10

IEEE 802.11p (V2I) TCP vs UDP packet capture in the Sodankylä test track

Full size image
Fig. 11
figure 11

IEEE 802.11p (V2I) TCP 13 pilot measurements

Full size image

Tables 2 and 3 show the used parameter settings for IEEE 802.11p and 5G test network pilot measurements for V2I and V2V scenarios at the transport layer.

Table 2 802.11p Parameter settings
Full size table
Table 3 5G test network parameter settings
Full size table

For pilot measurements, we used two road weather stations and two vehicles on the FMI test track while driving and collecting data in V2V and V2RWS modes. For all test measurements, we used Python program and Iperf software for sending TCP and UDP packets to RWS and for the analysis of the IEEE 802.11p and 5G test networks. The collected data from pilot measurements were analyzed by using Wireshark and Origin 2019b programs. The road weather data are collected from different road friction instruments like Teconer RCM 411 and WCM 411 installed in vehicles and road weather station sensors on the vicinity area. The road weather station sensor data, presented in Table 4, were collected during IEEE 802.11p and 5G test network measurements operating in V2I and V2V modes.

Table 4 Road weather station collected data
Full size table

4.1 IEEE 802.11p (V2I) TCP vs UDP Packet Capture

In the first stage of IEEE 802.11p pilot scenario, the vehicles exchanged data with RWS in V2I communication mode while driving on the test track. For V2I (V2RWS) communication, the RWS delivered up-to-date road weather data to the vehicles while passing the RWS. The resulting connectivity is presented in Fig. 10 by showing the yellow marks and pointing the locations where the packets were received by a vehicle in the V2I scenario. The packet capture in V2I (V2RWS) communication scenario has been done in 13 drives on the 1.7 km test track and the measured throughput is shown in Fig. 11 (TCP) and Fig. 12 (UDP). The pilot measurements fluctuate abruptly due to the vehicle distance from the RWS, the line-of-sight network availability, periodically shadowed by the tall trees on test track, as well as the used program for pilot measurements.

Fig. 12
figure 12

IEEE 802.11p (V2I) UDP pilot measurements

Full size image

In the second stage of the IEEE 802.11p pilot scenario, the vehicles exchanged the collected data from RWS in V2V communication mode while driving on the test track. The encountering vehicles exchanged the latest road weather data received from RWS through the ad hoc network. The resulting connectivity is presented in Fig. 13 by showing the yellow marks and pointing the locations where the TCP and UDP packets were received in the V2V scenario.

Fig. 13
figure 13

IEEE 802.11p ((V2V)) TCP vs UDP packet capture in the Sodankylä test track

Full size image

The packets capture in the V2V communication scenario was performed in 13 drives each for TCP and UDP packet capture; Figs. 14 and 15 show throughput measurements for TCP and UDP respectively. Test vehicles were driving in the same lane, as well as traveling across each other on the test rack. It can be noticed as in the previous cases that the data throughput in the pilot measurements varies abruptly due to similar reasons as previously explained. The UDP measurements in the Fig. 15 illustrate that the continuous transmission of packets during pilot drives.

Fig. 14
figure 14

IEEE 802.11p (V2V) TCP 13 pilot measurements

Full size image
Fig. 15
figure 15

IEEE 802.11p (V2I) UDP pilot measurements

Full size image

4.2 5G Test Network Pilot Measurements

At this stage of pilot measurements, we performed V2I 5G measurements considering TCP and UDP. The vehicle encountering another vehicle transfers the RWS information (V2RWS) to other vehicle (V2V). Thus, distributing real-time RWS information, extending RWS range in an ad hoc network and getting updated warnings alerts from RWS and vehicles will help to avoid accidents. TCP and UDP connectivity by using 5G test network is presented in Fig. 16 by showing the yellow marks and pointing the locations of packet capture in the V2I scenario. The packet capture using the 5G test network in V2I communication scenario has been performed in a total of 13 drives for both TCP and UDP cases. The corresponding packet captures showing the throughput are displayed in the Figs. 17 and 18 respectively. The Fig. 17 shows the rapidly fluctuating TCP throughput measurements. As mentioned before, these fluctuations can be attributed to the varying vehicle’s distance with RWS, as the line-of-light network availability shadowed by the tall trees on test track. The limitations of the used program also affects the measurement of throughput for the pilot. The UDP pilot measurements in the Fig. 18 suggests more consistent spikes and continuous packet transmission for test drives on a test track.

Fig. 16
figure 16

5G test network TCP vs UDP packet capture at Sodankylä, Finland

Full size image
Fig. 17
figure 17

5G test network (V2I) TCP pilot measurements

Full size image
Fig. 18
figure 18

5G test network (V2I) UDP pilot measurements

Full size image

5 Performance Evaluation of DSRC & Cellular Network Using TCP and UDP

5.1 IEEE 802.11p Performance Analysis Using TCP and UDP

In this section, we analyze the performance of IEEE 802.11p in vehicular ad hoc networks (V2V and V2I). We evaluated the performance of the IEEE 802.11p-based V2V and V2I scenarios on the transport layer (TCP/UDP). Table 5 illustrates the performance evaluation for V2I (V2RWS) while Table 6 shows the V2V performance considering TCP and UDP.

Table 5 IEEE 802.11p: V2I
Full size table
Table 6 IEEE 802.11p: V2V
Full size table

In vehicular pilot measurements, Nagel’s algorithm was turned on in TCP measurements, as TCP is more appropriate for reliable data transmission. Although UDP measurements with IEEE 802.11p architecture could be able to produce fast data transmission with a bit more probability of packet loss. It can be seen in Table 5 (V2I/V2RWS) and Table 6 (V2V) that the average packet size of TCP and UDP differs, and this have an impact on network latency, data rate and packet loss. The large sizes of the TCP packets require longer times to transfer, resulting in more collisions and data loss at the transport layer [14]. For that reason, network latency is quite high in TCP in contrast to UDP, which ultimately effects the data rate and throughput in TCP. We used Tahoe and Reno packet loss and delay strategy in this case, if an ACK times out retransmission time-out (RTO) slow start is used and both algorithms decrease congestion window to one maximum segment size (MSS). TCP waits for 200 ms for a full packet of data to send it again.

It can also be noticed in Tables 5 and 6 that the packet loss probability in UDP is high compared to that of TCP, and this is due to the continuous transmission of packets and lack of acknowledgment feature in UDP. The throughput analysis of IEEE 802.11p is presented in the Fig. 19 considering V2I and V2V scenarios using TCP and UDP. In this performance analysis, the UDP (V2I and V2V) is best in terms of throughput compared to TCP (V2I and V2V). It is important to notice that V2I (TCP) throughput was quite low and did not perform well in our test measurements due to packet loss and network latency (Windowing). The network latency is quite high with V2I (TCP) because TCP is very sensitive to network latency and packet loss depending on congestion control mechanism. Basically, IEEE 802.11p is a narrowband communication that performs well with UDP continuous transmission of packets; that is why it performs well in our pilot measurements [14, 15].

Fig. 19
figure 19

Throughput analysis of IEEE 802.11p in V2V and V2I

Full size image

5.2 5G Test Network Performance Analysis Using TCP and UDP

In this section, we analyze the performance of the 5G test network. We evaluate the performance of the 5G test network on the transport layer (TCP/UDP) in terms of the V2I scenario. Table 7 illustrates the performance evaluation for cellular communications considering TCP and UDP in the 5G test network.

Table 7 Performance analysis of 5G test network
Full size table

It can be seen in the abovementioned Table 7 that the average packet size of TCP and UDP differs, as it was in IEEE 802.11p case, affecting network latency, throughput and packet loss. The large packet size in TCP means longer transfer times, resulting in more collisions and data loss. This explains the quite high network latency in TCP that ultimately affects throughput in TCP in contrast to UDP. The packet loss probability in UDP is high compared to the TCP case, due to the lack of acknowledgments and continuous transmission of packets. As compared to UDP, the blockage time in TCP (>1 s) causes packet drop (%) and ultimately affects the throughput. Nonetheless, the large buffer size can provide some compensation for packet loss in TCP, but it will increase the communication period (latency) in contrast to UDP [14, 15]. In the 5G test network, TCP offers some features such as retransmission of lost packets and reordering of packets, but generates network latency and jitter. Jitter is the delay between data transmission and receiving, that the reason that jitter is calculated in UDP but not in TCP. Because of TCP features. It has an unacceptable level of jitter for real-time applications.

In Fig. 20, the performance analysis of TCP and UDP is presented. UDP performed well in our pilot measurements with continuous transmission of packets. The delay handling and congestion control mechanism of TCP are very important in the 5G test network because of high frequencies and channel sensitivity to a wide range of factors that affect the throughput, that is, delay, attenuation, outage, etc.

Fig. 20
figure 20

Throughput analysis of 5G test network in V2V and V2I

Full size image

6 Conclusion

In this chapter, we have studied the feasibility of using TCP and UDP with IEEE 802.11p and 5G test network in real vehicular environments (V2V and V2I). Our results indicate that TCP provides quality of service (QoS) in modern vehicular networks by predicting and optimizing their performance in different automotive environments and applications. On the contrary, UDP in IEEE 802.11p performed well for V2V and V2I scenarios with connectionless packet transmission and avoiding the overhead of processing delay in the network. In the 5G test network, the network performance was significantly reduced when using TCP in V2V and V2I scenario instead of UDP. UDP performance was adequate in the 5G test network because packet loss is tolerated in UDP rather than waiting for acknowledgments and retransmitted packets, which may not be the best choice for real-time applications.

Our pilot measurements show some interesting results that offers end-to-end delays less than 200 ms and throughputs of up to 5Mbps, accomplishing the active road safety, as well as cooperative traffic efficiency applications requirements.