802.11p Packet Loss in mmWave V2X Scheduling

V2X, short for vehicle to everything, covers communication between a vehicle and other vehicles, roadside infrastructure and other road users. This project is mainly concerned with communication between vehicles. By sharing information directly, vehicles can become aware of traffic and possible hazards that their own sensors cannot yet see.

IEEE 802.11p is one of the technologies made for this kind of communication. It operates around 5.9 GHz, which makes it part of the broader category of sub-6 GHz technologies. Vehicles use it to broadcast Cooperative Awareness Messages, or CAMs. These are short beacons that a vehicle sends up to ten times per second. They contain its position, speed, heading and acceleration, and some fixed details such as its dimensions and vehicle type. Every vehicle in range receives them, so each vehicle has a recent picture of the traffic around it without having to set up a connection first.

This works well because 5.9 GHz is a relatively low frequency. The signal reaches several hundred metres, it deals with obstacles reasonably well, and it is sent in all directions, so one transmission reaches every vehicle nearby. The downside is that the channel is narrow. There is not much bandwidth to go around and every vehicle in the area has to share it. When traffic gets dense the channel becomes congested. Transmissions start to collide and beacons get lost, so the channel becomes less reliable as more vehicles use it, while dense traffic is also where the information matters most.

That is enough for awareness messages, but not for camera images, LiDAR scans or other sensor data that could help a vehicle see beyond its own sensors. Sharing that kind of data needs far more bandwidth than the 5.9 GHz channel can offer.

A 60 GHz mmWave link is the other option. There is much more spectrum available at 60 GHz, so the data rate is high enough for raw sensor data. It does work very differently from 802.11p. The signal attenuates quickly at this frequency and needs line of sight (LoS), so a vehicle cannot just broadcast to everything around it. Instead it puts its energy into a narrow beam aimed at one receiver. Because the beams are narrow, two pairs of vehicles close to each other barely interfere, so a lot of links can be active in the same area at once. Congestion is therefore much less of a problem than on 802.11p.

The difficulty is getting the beams pointed in the right direction. Before two vehicles can send anything, they first have to find each other and line up their antennas. A vehicle does this by sweeping its beam through its surroundings one direction at a time, and it only finds the other vehicle if that vehicle happens to be listening in the matching direction at that moment. A control message sent over a single beam is easily missed. Vehicles also keep moving relative to each other, so this has to be repeated regularly. If all of it is done over mmWave, a large part of the available time goes into setting up links instead of using them, and the two vehicles still have to agree on a free time slot before they can transmit.

The paper Sub-6GHz Assisted MAC for Millimeter Wave Vehicular Communications [1] moves this coordination to 802.11p, using the channel that already carries the CAMs as a control channel for the mmWave link. The proposal adds a small amount of scheduling information to those existing beacons. A vehicle can announce that it wants to send data, the receiver can confirm the reservation and other vehicles in range can hear the same plan. The actual sensor data still travels over the much faster mmWave link.

This leaves more of the mmWave channel available for data and gives nearby vehicles a shared view of the planned transmissions. In the simulations from the paper, the assisted protocol reduced the time needed to arrange a transmission and allowed more mmWave links to be active at once.

The scheduling evaluation assumes that the added 802.11p control information is received successfully. That matters because a lost request, confirmation or schedule update can delay a transmission or leave vehicles with different views of the schedule. My project looks at what happens when that assumption is removed.

I built a Python simulator for the assisted scheduling protocol and first varied the packet delivery ratio from 0 to 1. I then replaced the fixed delivery ratio with the analytical 802.11p model by Sepulcre et al. [2]. This model accounts for losses caused by propagation, sensing, collisions and a busy receiver. It let me compare the protocol under expected 802.11p conditions with the same setup under ideal control packet delivery.

Results

The simulations use a 2 km circular road with four lanes and 250 vehicles. RTX controls how many of those vehicles try to send data. An RTX of 0.40 selects 100 senders, while 0.80 selects 200. For the first set of results I varied the packet delivery ratio from 0 to 1 in steps of 0.05. Each point combines five simulation seeds with a 236 second measurement window.

Varying the packet delivery ratio

Figure 1 shows that throughput rises across the full sweep, although not at the same rate everywhere. The curves grow more slowly around a delivery ratio of 0.5 to 0.7, then turn upwards again as delivery approaches 1. The run with 200 senders produces more throughput than the run with 100 senders, but it also creates more opportunities for reservations to overlap.

The conflicting reservations in Figure 2 explain the change in the throughput curves. When very few control packets arrive, only a small number of reservations can be completed in the first place. Once more requests and confirmations get through, vehicles can start reserving mmWave slots while still missing some of the surrounding schedule updates. Different vehicles can then have different views of which slots are free. The conflict count therefore rises at first, reaches its highest point at an intermediate delivery ratio and falls to zero when every control packet is delivered.

The fraction in Figure 3 shows this more clearly than the raw count does. For RTX 0.40 the conflict fraction reaches 57.2% at a delivery ratio of 0.65. For RTX 0.80 it reaches 56.4% at 0.60. This is also the part of the sweep where throughput grows most slowly. Better packet delivery does not only allow more reservations to be made. It also makes the schedules held by nearby vehicles more consistent.

Figure 4 shows that packet loss is most noticeable in the delay below a delivery ratio of about 0.2. A lost request or confirmation means waiting for a later beacon before scheduling can continue. This is felt more strongly by targets that complete later in the request, which creates the spread between the curves. Once delivery becomes more reliable the first targets finish in a fraction of a second, while later targets still have to wait for the earlier reservations.

Figure 5 shows the same spatial sharing idea used in the original paper, but over the complete packet delivery sweep. At a delivery ratio of 1, the median is 60 simultaneous transmissions for RTX 0.40 and 91 for RTX 0.80. During the middle 80% of the observed time these values range from 54 to 66 and from 84 to 97 respectively. As packet delivery falls, fewer links can be scheduled successfully at the same time.

Using the 802.11p model

Figure 6 shows that all mmWave neighbours in the simulated road are between 3 m and 60 m apart, with a median distance of 25.8 m. Across that range the modeled 802.11p delivery ratio remains high. It is 96.84% at 3 m, about 96.05% at the median distance and 92.85% at 60 m. The control channel therefore loses packets, but the vehicles relevant to a mmWave reservation remain in the stronger part of the 802.11p curve.

Figure 7 compares the modeled 802.11p result with ideal delivery across the complete RTX sweep. At RTX 0.40 it reaches 35.72 Gbit/s instead of 41.58 Gbit/s, a difference of 14.1%. At RTX 0.80 the difference is 6.8%, with 58.54 Gbit/s instead of 62.79 Gbit/s. At RTX 1 it falls to 3.75%, with 67.25 Gbit/s instead of 69.87 Gbit/s.

Conclusion

Packet loss on the 802.11p control channel does affect assisted mmWave scheduling. It increases completion delay, reduces the number of links that can transmit at the same time and can leave vehicles with different views of the schedule. The conflict peak at intermediate delivery ratios is important here. Enough messages arrive to create many reservations, but not enough arrive to keep every schedule consistent.

Under the analytical 802.11p model the effect is smaller than the fixed delivery sweep might initially suggest. The mmWave links only cover 60 m and the modeled delivery ratio remains above 92% throughout that range. Performance therefore stays reasonably close to ideal delivery, although the remaining difference is still visible at every RTX value.

References

[1] R. Coll-Perales, J. Gozalvez and M. Gruteser, “Sub-6GHz Assisted MAC for Millimeter Wave Vehicular Communications,” IEEE Communications Magazine, vol. 57, no. 3, pp. 125–131, Mar. 2019. https://doi.org/10.1109/MCOM.2019.1800509

[2] M. Sepulcre, M. Gonzalez-Martín, J. Gozalvez, R. Molina-Masegosa and B. Coll-Perales, “Analytical Models of the Performance of IEEE 802.11p Vehicle to Vehicle Communications,” IEEE Transactions on Vehicular Technology, vol. 71, no. 1, pp. 713–724, Jan. 2022. https://doi.org/10.1109/TVT.2021.3124708