Skip to content

Overzicht

Ter samenvatting van mijn masterproef, volgend overzicht van de gebruikte technologieën en hun toepasbaarheid voor het realiseren van een ITS toepassing op Android:

  • Ad-hoc broadcasting
    Niet mogelijk in de huidige versie van het Android besturingssysteem

  • Ad-hoc netwerken
    Kunnen waargenomen worden door het uitvoeren van een netwerkscan op Android, maar connecties kunnen niet gerealiseerd worden.

  • Click Modular Router via Linux executable
    De Click broncode kon succesvol gecompileerd worden tot een executable voor het Android besturingssysteem met behulp van de in de Android NDK voorziene crosscompiler. Het uitvoeren van deze executable op een Android toestel stuit echter op een permissieprobleem, dat we niet willen omzeilen door het toestel te rooten. Een op dergelijke werkwijze gebaseerde toepassing zou immers niet verspreidbaar zijn via een app-store, gezien we niet kunnen verwachten van de gebruiker om ook zijn toestel te rooten. Dit was een uitgangspunt van de masterproef.

  • Click Modular Router via Android applicatie (.apk)
    De Click broncode werd gecompileerd in een static library (libclick.a), maar in tegenstelling tot een Hello World-library, functioneerde deze niet in een Android applicatie. Definitief uitsluitsel over de mogelijkheden van deze werkwijze is er niet, maar naar alle waarschijnlijkheid is de vereiste netwerkfunctionaliteit op deze manier niet realiseerbaar. Verdere pogingen zijn niet ondernomen gezien de Wifi-Direct technologie een aantrekkelijkere kans op slagen leek te bieden.

  • Wifi-Direct via connect-methode
    Uit het ontwikkelen van een applicatie op de Android Wifi-Direct API en het uitgebreid loggen van het opstellen van een connectie werden de volgende zaken geconcludeerd:
    Het opzetten van een Wifi-Direct connectie via de connect-methode tussen twee toestellen duurt onacceptabel lang en maakt deze werkwijze onbruikbaar voor het realiseren van V2V communicatie:

    tgem = (11,8 ± 1,7) s

    Er lijken geen gelijktijdige connecties mogelijk met meerdere peers.
    Een verbinding, aangevraagd vanop een ander Wifi-Direct toestel, kan niet automatisch geaccepteerd worden, maar vereist manuele bevestiging van de gebruiker.

  • Wifi-Direct voor legacy devices (createGroup-methode)
    Het opzetten van een access point via de Wifi-Direct API en het connecteren hieraan door een Android toestel lijkt wel voldoende snel te verlopen. Uit herhaalde metingen resulteert hier een connectie tijd van:

    tgem = (2,83 ± 0,15) s

    Met de op deze werkwijze ontwikkelde applicaties werden praktische voertuigtesten uitgevoerd, waarbij in de meeste scenario’s communicatie kon gerealiseerd worden tussen onderling bewegende wagens. 

    Er zijn echter nog enkele aspecten van de huidige API die het ontwikkelen van een ITS toepassing onmogelijk maken: het is bijvoorbeeld nog niet mogelijk om de preshared key voor het Wifi-Direct access point in te stellen of programmatisch om te schakelen tussen klassieke wifi- en Wifi-Direct-functionaliteit, wat noodzakelijk zou zijn voor het propageren van ITS informatie. De nodige aanpassingen lijken ons in de toekomst echter behoorlijk plausibel.

Voertuigtesten

De voertuigtesten

Uit de uitgevoerde labtesten bleek Wifi-Direct qua connectiesnelheid mogelijkheden te bieden voor het praktisch realiseren van vehicle-to-vehicle communicatie. De ontwikkelde applicaties werden aangepast zodat beide toestellen automatisch connectie zouden maken, waarna enkele scenario’s getest werden tussen al dan niet bewegende voertuigen.

Testen A tot en met D bestaan uit een stationair voertuig dat gekruist wordt door een bewegend voertuig aan de volgende snelheden:

Test A: 40 km/h, zelfde oriëntatie als stationair voertuig.
Test B: 40 km/h, tegengestelde oriëntatie als stationair voertuig.
Test C: 90 km/h, zelfde oriëntatie als stationair voertuig.
Test D: 90 km/h, tegengestelde oriëntatie als stationair voertuig.

waarbij met zelfde oriëntatie bedoeld wordt dat het stationaire voertuig in de rijrichting van andere voertuig geparkeerd staat. Bij tegengestelde oriëntatie staat het voertuig uiteraard in tegengestelde richting:

Gewone oriëntatie:

Tegengestelde oriëntatie:

Testen E en F gebeurden tussen twee bewegende voertuigen:

Test E: Voertuigen kruisen elkaar aan 40 km/h.
Test F: Voertuigen kruisen elkaar aan 90 km/h.

De testen werden uitgevoerd op rechte wegen buiten de bebouwde kom, om interferentie met andere access points zoveel mogelijk te beperken.

De testomgeving:

     

De resultaten

Concreet werd in testen A tot en met E succesvolle communicatie gerealiseerd:

Uit het logbestand van test F kon worden vastgesteld dat er kort sprake was van een connectie, maar er werden geen ontvang berichten geregistreerd op de ontvanger.

Uit de resultaten van proef A werd ook de straal van het bereik van het Wifi-Direct access point bepaald:

d = 61m


                                Voertuigtest A

Op bovenstaande figuur is de locatie van het eerste ontvangen bericht aangeduid als locatie A, de locatie van de stationaire zender: locatie B en de locatie van het laatst ontvangen pakket: Locatie C. We stellen hier naar de verwachting een asymmetrisch patroon vast, gezien tijdens het naderen van het stationaire voertuig eerst de connectie dient opgezet te worden.

De berekening van de straal van het bereik staaft ons vermoeden dat deze technologie effectief toepasbaar zou zijn op een snelweg. Immers, een voertuig dat aan 120 km/h voorbij een stationaire zender rijdt, legt tijdens de gemiddelde connectietijd van 2,83 seconden minder dan 100 meter af:

Δs = v . Δt => Δs = 120 km/h . 2,83s

      = 120000m . 2,83s / 3600 s

      = 94,3 m

Een voertuig dat net naast een stationaire zender voorbij rijdt zal dus bij benadering 122 meter binnen bereik zijn. Er lijkt dus voldoende tijd over om nog effectief te communiceren.

Tegenliggers die aan een snelheid van 120 km/h elkaar kruisen zullen dus helaas niet via deze technologie kunnen communiceren. Het voorzien van road side units die de communicatie tussen beide rijrichtingen coördineren zouden dit probleem echter kunnen oplossen. Communicatie tussen voertuigen met dezelfde rijrichting kan dus zeker wel. Het snelheidsverschil is namelijk kleiner dan de snelheid van het snelste voertuig, in principe 120 km/h. De voertuigtesten tonen duidelijk aan dat het realiseren en in stand houden van een connectie met een access point in beweging geen probleem is.

De berichten die via de Wifi-Direct connectie tussen de toestellen uitgewisseld werden tijdens de testen werden overgens via het TCP protocol verstuurd. Dit blijkt ook uit de logbestanden van de testen: onderstaande grafiek toont hoe het onderliggende TCP protocol lichte communicatiestoornissen oplost en de aflevervolgorde van de berichten garandeert:

Labtesten

Met de labtesten werd door uitgebreide logging de connectietijd bepaald van de Wifi-Direct technologie, gebruik makende van de connect-methode en de createGroup-(Wifi-Direct voor legacy devices) methode.

Connectietijd connect-methode

Geen enkele meetwaarde verschilt meer dan tweemaal de standaarddeviatie van het gemiddelde, er zijn dus geen statistische uitschieters. De gemiddelde connectietijd bedraagt:

 tgem = (11,8 ± 1,7) s

 Als we dit resultaat in een praktische context plaatsen, zien we snel dat deze methode niet bruikbaar zal zijn voor het realiseren van V2V communicatie: een voertuig dat op een autostrade aan een snelheid van 120 km/h een stilstaande peer zou naderen, zal na het verlopen van de gemiddelde connectietijd een afstand van bijna 400 meter afgelegd hebben:

 Δs = v . Δt => Δs = 120 km/h . 11,8s

      = 120000m . 11,8s / 3600 s

      = 393,3 m

 Indien beide voertuigen in beweging zijn in tegengestelde richting is deze methode dus al helemaal onbruikbaar. Dit werd bevestigd door de resultaten van de voertuigtesten.

Connectietijd createGroup-methode

De gemiddelde connectietijd met de createGroup-methode is dus:

tgem = (2,83 ± 0,15) s

Dit lijkt al veel bruikbaarder dan de connect-methode. We berekenen opnieuw de afstand die een voertuig aan 120 km/h aflegt in deze tijdspanne:

Δs = v . Δt => Δs = 120 km/h . 2,83s

     = 120000m . 2,83s / 3600 s

     = 94,3 m

Deze methode zal een voertuig zeker in staat stellen met een stilstaande peer te communiceren, wat ook werd bevestigd door de voertuigtesten. Ook communiceren met tegenliggers kan eventueel tot de mogelijkheden behoren. 

Wifi-Direct

Tijdens het onderzoek naar de netwerkmogelijkheden van de Android API, kwam de Wifi-Direct functionaliteit van het besturingssysteem onder de aandacht en de mogelijkheid om deze techniek te benutten in een ITS toepassing werd al snel beschouwd als veelbelovend alternatief voor ad-hoc broadcasting. Wifi-Direct verschilt cruciaal met de vorige aanpak doordat het connectiegerichte communicatie betreft. Ad-hoc broadcasting verloopt bij definitie connectieloos, waarbij een device zonder netwerkverbinding als het ware lukraak netwerkpakketten uitzendt, die door elke mogelijke (ad-hoc) ontvanger kunnen verwerkt worden. Toestellen die een Wifi-Direct implementatie gebruiken om netwerkcommunicatie te realiseren daarentegen, zijn werkelijk met elkaar verbonden en krijgen ook werkelijk een ip-adres toegekend, analoog aan de verbinding tussen een klassiek access point en een willekeurig toestel met draadloze netwerkkaart.

Het realiseren van zo’n connectie tussen peers neemt dus een zekere tijd in beslag. De mate waarin deze connectietijd de praktische werking van een op Wifi-Direct gebaseerde ITS toepassing obstrueert, dient onderzocht te worden. Ook zal het broadcasten van informatie plaats maken voor het zenden van een identiek bericht naar elke geconnecteerde peer, wat misschien ook een effect zal hebben op de performantie.

Om deze connectietijd concreet te gaan bepalen werden applicaties gebouwd op de Android Wifi-Direct API die gebruik maken van beide connectiemethodes die deze API voorziet: de connect-methode en de createGroup-methode, waarbij de laatste eigenlijk voorzien is voor compatibiliteit met legacy devices. Door uitgebreide logging werden de connectietijden bepaald. De resultaten hiervan vindt u bij de post “labtesten”.

Click Modular Router

Mogelijkheden in Android

De mogelijkheid van een smartphone, specifiek een Android toestel, om ad-hoc broadcasts uit te voeren of simuleren zal bepalend zijn voor de haalbaarheid van een ITS toepassing voor dit doelplatform. De Android API (Android developer reference, geraadpleegd via developer.android.com/reference) biedt veel mogelijkheden aan ontwikkelaars. Op gebied van netwerkmogelijkheden kan een Android applicatie, mits voldoende permissies toegekend, acties zoals netwerkscans uitvoeren of configuraties voor verschillende access points wijzigen. Om rechtstreekse communicatie tussen smartphones te realiseren zou ondersteuning voor ad-hoc broadcasting een optimale oplossing zijn, maar dergelijke functionaliteit is niet voorzien in de huidige versie van het besturingssysteem. Ook connecties met een ad-hoc netwerk kunnen niet gerealiseerd worden.

Click Modular Router

Het aan IBCN ontwikkelde prototype ITS systeem is gebaseerd op ad-hoc broadcasting gerealiseerd door de Click Modular Router. Pogingen om deze software onder Android te benutten waren niet succesvol: het builden van een Click executable voor Android stuitte op een permissieprobleem en een Click static library onder een Android applicatie met toegevoegde Android permissies bleek niet te functioneren.

De pogingen om ad-hoc broadcasting te realiseren werden gestaakt toen de Android Wifi-Direct API onder de aandacht kwam en het idee ontstond om connectiegerichte communicatie te proberen realiseren tussen bewegende voertuigen.

Follow

Get every new post delivered to your Inbox.