Pakketverlies op het 802.11p-controlekanaal bij mmWave-scheduling

V2X, kort voor vehicle to everything, omvat de communicatie tussen een voertuig en andere voertuigen, infrastructuur langs de weg en overige weggebruikers. Dit project richt zich voornamelijk op de communicatie tussen voertuigen. Door informatie direct te delen, krijgen voertuigen zicht op verkeer en mogelijke gevaren die hun eigen sensoren nog niet kunnen zien.

IEEE 802.11p is een van de technologieën die voor dit soort communicatie zijn ontwikkeld. Het werkt rond 5,9 GHz en valt daarmee in de bredere categorie van sub-6 GHz-technologieën. Voertuigen gebruiken het om Cooperative Awareness Messages uit te zenden, kortweg CAM's. Dat zijn korte beacons die een voertuig tot tien keer per seconde verstuurt. Ze bevatten de positie, snelheid, rijrichting en versnelling van het voertuig, en een aantal vaste gegevens zoals de afmetingen en het voertuigtype. Elk voertuig binnen bereik ontvangt ze, waardoor ieder voertuig een actueel beeld heeft van het verkeer om zich heen zonder dat er eerst een verbinding opgezet hoeft te worden.

Dit werkt goed omdat 5,9 GHz een relatief lage frequentie is. Het signaal reikt enkele honderden meters ver, heeft relatief weinig last van obstakels en wordt in alle richtingen uitgezonden. Eén transmissie bereikt daardoor elk voertuig in de buurt. Het nadeel is dat het kanaal smal is. Er is niet veel bandbreedte beschikbaar en alle voertuigen in het gebied moeten die delen. Bij druk verkeer raakt het kanaal overbelast. Er ontstaan collisions en beacons gaan verloren, waardoor het kanaal minder betrouwbaar wordt naarmate meer voertuigen het gebruiken, terwijl de informatie juist bij druk verkeer het belangrijkst is.

Dat is genoeg voor awareness-berichten, maar niet voor camerabeelden, LiDAR-scans of andere sensordata waarmee een voertuig verder zou kunnen kijken dan zijn eigen sensoren. Zulke data delen vraagt veel meer bandbreedte dan het 5,9 GHz-kanaal kan bieden.

Een 60 GHz mmWave-verbinding is het alternatief. Op 60 GHz is veel meer spectrum beschikbaar, dus de datasnelheid is hoog genoeg voor ruwe sensordata. Zo'n verbinding werkt wel heel anders dan 802.11p. Op deze frequentie wordt het signaal snel gedempt en is een onbelemmerde zichtlijn (line of sight, LoS) nodig, dus een voertuig kan niet in alle richtingen tegelijk zenden. In plaats daarvan concentreert het zijn energie in een smalle bundel die op één ontvanger is gericht. Doordat de bundels smal zijn, hebben twee paren voertuigen die vlak bij elkaar rijden nauwelijks last van elkaar, waardoor er in hetzelfde gebied veel verbindingen tegelijk actief kunnen zijn. Congestie is daardoor veel minder een probleem dan op 802.11p.

Het lastige is om de bundels in de goede richting te krijgen. Voordat twee voertuigen iets kunnen versturen, moeten ze elkaar eerst vinden en hun antennes uitlijnen. Een voertuig doet dat door met zijn bundel richting voor richting de omgeving af te tasten, en het vindt het andere voertuig alleen als dat op datzelfde moment toevallig in de bijbehorende richting luistert. Een controlebericht dat over één bundel wordt verstuurd, is makkelijk te missen. Voertuigen blijven bovendien ten opzichte van elkaar bewegen, dus dit moet regelmatig worden herhaald. Als dit allemaal over mmWave verloopt, gaat een groot deel van de beschikbare tijd op aan het opzetten van verbindingen in plaats van aan het gebruiken ervan, en moeten de twee voertuigen daarna nog steeds een vrij tijdslot afspreken voordat ze kunnen zenden.

Het artikel Sub-6GHz Assisted MAC for Millimeter Wave Vehicular Communications [1] verplaatst deze coördinatie naar 802.11p en gebruikt het kanaal waarover de CAM's toch al verstuurd worden als controlekanaal voor de mmWave-verbinding. Het voorstel voegt een kleine hoeveelheid schedulinginformatie toe aan die bestaande beacons. Een voertuig kan aankondigen dat het data wil versturen, de ontvanger kan de reservering bevestigen en andere voertuigen binnen bereik horen hetzelfde plan. De daadwerkelijke sensordata gaat nog steeds over de veel snellere mmWave-verbinding.

Hierdoor blijft een groter deel van het mmWave-kanaal beschikbaar voor data en krijgen voertuigen in de buurt een gedeeld beeld van de geplande transmissies. In de simulaties uit het artikel verkortte het protocol met 802.11p-ondersteuning de tijd die nodig was om een transmissie af te spreken en konden er meer mmWave-verbindingen tegelijk actief zijn.

De evaluatie van de scheduling gaat ervan uit dat de toegevoegde controle-informatie via 802.11p succesvol wordt ontvangen. Dat is van belang, want een verloren verzoek, bevestiging of schema-update kan een transmissie vertragen of ervoor zorgen dat voertuigen een verschillend beeld van het schema hebben. Mijn project onderzoekt wat er gebeurt wanneer die aanname wordt losgelaten.

Ik heb een Python-simulator gebouwd voor het schedulingprotocol met 802.11p-ondersteuning en daarin eerst de packet delivery ratio gevarieerd van 0 tot 1. Vervolgens heb ik de vaste delivery ratio vervangen door het analytische 802.11p-model van Sepulcre et al. [2]. Dit model houdt rekening met verliezen door propagatie, sensing, collisions en een bezette ontvanger. Daarmee kon ik het protocol onder verwachte 802.11p-omstandigheden vergelijken met dezelfde opstelling waarin alle controlepakketten aankomen.

Resultaten

De simulaties gebruiken een circulaire weg van 2 km met vier rijstroken en 250 voertuigen. RTX bepaalt hoeveel van die voertuigen data proberen te versturen. Een RTX van 0,40 selecteert 100 zenders en een RTX van 0,80 selecteert er 200. Voor de eerste reeks resultaten heb ik de packet delivery ratio gevarieerd van 0 tot 1 in stappen van 0,05. Elk punt combineert vijf simulatieseeds met een meetvenster van 236 seconden.

Variëren van de packet delivery ratio

Figuur 1 laat zien dat de throughput over de volledige sweep toeneemt, al gaat dat niet overal even snel. De curves groeien langzamer rond een delivery ratio van 0,5 tot 0,7 en buigen daarna weer omhoog naarmate de delivery ratio 1 nadert. De run met 200 zenders levert meer throughput op dan de run met 100 zenders, maar creëert ook meer kansen op overlappende reserveringen.

De conflicterende reserveringen in Figuur 2 verklaren de verandering in de throughputcurves. Wanneer er heel weinig controlepakketten aankomen, kunnen er sowieso maar weinig reserveringen worden afgerond. Zodra er meer verzoeken en bevestigingen doorkomen, kunnen voertuigen mmWave-slots gaan reserveren terwijl ze nog steeds een deel van de omliggende schema-updates missen. Verschillende voertuigen kunnen dan een verschillend beeld hebben van welke slots vrij zijn. Het aantal conflicten stijgt daardoor eerst, bereikt zijn hoogste punt bij een tussenliggende delivery ratio en daalt naar nul wanneer elk controlepakket wordt ontvangen.

De fractie in Figuur 3 laat dit duidelijker zien dan het absolute aantal. Bij RTX 0,40 bereikt de conflictfractie 57,2% bij een delivery ratio van 0,65. Bij RTX 0,80 is dat 56,4% bij 0,60. Dit is ook het deel van de sweep waar de throughput het langzaamst groeit. Een betere delivery ratio zorgt er niet alleen voor dat er meer reserveringen gemaakt kunnen worden, maar maakt de schema's van voertuigen in de buurt ook consistenter.

Figuur 4 laat zien dat pakketverlies het duidelijkst merkbaar is in de vertraging onder een delivery ratio van ongeveer 0,2. Bij een verloren verzoek of bevestiging moet er op een latere beacon gewacht worden voordat de scheduling verder kan. Dit speelt sterker bij targets die later in het verzoek worden voltooid, wat de spreiding tussen de curves veroorzaakt. Zodra de delivery ratio hoger wordt, zijn de eerste targets binnen een fractie van een seconde klaar, terwijl latere targets nog steeds op de eerdere reserveringen moeten wachten.

Figuur 5 laat hetzelfde idee van ruimtelijk hergebruik zien als in het oorspronkelijke artikel, maar dan over de volledige sweep van de packet delivery ratio. Bij een delivery ratio van 1 is de mediaan 60 gelijktijdige transmissies voor RTX 0,40 en 91 voor RTX 0,80. Gedurende de middelste 80% van de waargenomen tijd liggen deze waarden tussen 54 en 66, respectievelijk tussen 84 en 97. Naarmate de delivery ratio daalt, kunnen er minder verbindingen tegelijk succesvol worden ingepland.

Het 802.11p-model gebruiken

Figuur 6 laat zien dat alle mmWave-buren op de gesimuleerde weg tussen 3 m en 60 m van elkaar liggen, met een mediane afstand van 25,8 m. Over dat hele bereik blijft de gemodelleerde delivery ratio van 802.11p hoog. Deze is 96,84% op 3 m afstand, ongeveer 96,05% op de mediane afstand en 92,85% op 60 m. Het controlekanaal verliest dus pakketten, maar de voertuigen die relevant zijn voor een mmWave-reservering bevinden zich in het sterkere deel van de 802.11p-curve.

Figuur 7 vergelijkt het gemodelleerde 802.11p-resultaat met het ideale geval over de volledige RTX-sweep. Bij RTX 0,40 komt het uit op 35,72 Gbit/s in plaats van 41,58 Gbit/s, een verschil van 14,1%. Bij RTX 0,80 is het verschil 6,8%, met 58,54 Gbit/s in plaats van 62,79 Gbit/s. Bij RTX 1 daalt het naar 3,75%, met 67,25 Gbit/s in plaats van 69,87 Gbit/s.

Conclusie

Pakketverlies op het 802.11p-controlekanaal heeft wel degelijk invloed op mmWave-scheduling met 802.11p-ondersteuning. Het verhoogt de voltooiingsvertraging, vermindert het aantal verbindingen dat tegelijk kan zenden en kan ervoor zorgen dat voertuigen een verschillend beeld van het schema hebben. De conflictpiek bij tussenliggende delivery ratios is hierbij belangrijk. Er komen genoeg berichten aan om veel reserveringen te maken, maar niet genoeg om alle schema's consistent te houden.

Onder het analytische 802.11p-model is het effect kleiner dan de sweep met een vaste delivery ratio in eerste instantie doet vermoeden. De mmWave-verbindingen overbruggen maar 60 m en de gemodelleerde delivery ratio blijft over dat hele bereik boven de 92%. De prestaties blijven daardoor redelijk dicht bij het ideale geval, al is het resterende verschil bij elke RTX-waarde nog steeds zichtbaar.

Referenties

[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