richt wel door iedereen wordt ontvangen. Het synchronisatieprobleem is moeilijk op te lossen bij beperkte hardware en infrastructuur, wat kort is aangehaald in sectie 2.3. Zonder enige infra- structuur kunnen buren zich enkel met elkaar synchroniseren door één ervan SYNC berichten te laten versturen (de SYNC-node). Dit heeft twee gevolgen.
Ten eerste moeten two-hop buren en dergelijke ook gesynchroniseerd worden. Deze zijn niet direct te bereiken door de SYNC-node, maar wel door gemeenschappelijke one-hop buren. Indien niet iedereen gesynchroniseerd wordt gaan slots van verschillende nodes overlappen, met allerhande collisions tot gevolg.
Ten tweede zijn verschillende groepen nodes, met elk een SYNC-node, niet met elkaar gesyn- chroniseerd. Wanneer deze in elkaars buurt komen moeten er strategieën zijn voor slechts één SYNC-node over te houden, zodat de nieuw-gevormde groep hiermee synchroniseert.
Dit TDMA ontwerp is implementeerbaar op resource-constrained chips met slechts één CPU. Deze implementeren is echter niet realiseerbaar in de masterproef door de beperkte tijd. Het ontwerp is vrij complex en er is geen goede oplossing gevonden voor het synchronisatieprobleem. Er werd aangeraden om een simpelere oplossing te bedenken en te implementeren. Daarom wordt ook nog een simpeler CSMA ontwerp voorgesteld dat zal worden geïmplementeerd.
3.2 CSMA ontwerp
In dit ontwerp wordt CSMA toegepast op het subGHz-kanaal. Het UWB-kanaal blijft nog steeds tijdsslots gebruiken maar er wordt strikt genomen geen TDMA meer toegepast. Het UWB-kanaal wordt tijdelijk voor drie slots gereserveerd. De nodes bepalen zelf wanneer deze slots optreden en enkel de afstandsbepalingspartners moeten gesynchoniseerd worden.
Door CSMA te gebruiken is er geen nood meer aan groepssynchronisatie. Hier werd geen goede oplossing voor gevonden bij de TDMA ontwerpen. Omdat er geen TDMA-superframes meer worden toegepast op het UWB-kanaal, zijn er ook geen slotreservaties meer nodig. Daardoor is er ook geen nood aan reservatietabellen. Dit spaart een hoop berichtuitwisselingen uit. Er is dan ook minder rekenkracht nodig dat werd gebruikt voor deze tabellen te onderhouden en te verwerken tot two-hop reservatiebeelden. Dit alles verlicht het implementatiewerk en maakt het mogelijk het ontwerp te implementeren in deze masterproef.
CSMA komt met eigen nadelen. Het kanaal wordt minder efficiënt benut tegenover TDMA. De performantie vermindert ook bij hoge bezettingsgraden, zoals beschreven in 2.2. Dit kan enkel opgelost worden met duty cycling, wat leidt tot minder up-to-date afstanden tussen nodes.
Figuur 3.5: Afstandsbepaling tussen twee nodes in functie van de tijd. eerst wordt de three-way handshake uitgevoerd op het subGHz-kanaal. Daarna wordt de afstand bepaald op het
UWB-kanaal. Dit laatste is opgesplitst in drie tijdsslots.
Nog steeds moet er afgesproken worden welke nodes het UWB-kanaal gaan gebruiken. Er worden dan tijdelijke UWB-slots gecreëerd. Dit wordt gerealiseerd met een three-way handshake op het subGHz-kanaal. Er werd voor een three-way handshake gekozen omdat deze veel betrouwbaarder is dan één of zelfs twee berichtuitwisselingen. De node die de handshake initialiseert wordt de master genoemd, de andere de slave.
De master geeft aan dat hij aan afstandsbepaling wilt doen met de slave via het InitRanging bericht. De slave geeft aan dat er niemand in zijn one-hop omgeving aan afstandsbepaling doet door een ACK terug te sturen (voor het vermijden van hidden-node collisions). Vervolgens be- vestigt de master deze ACK met het ConfirmRanging bericht. Daardoor weten ook alle buren dat het UWB-kanaal bezet wordt door deze twee nodes. Dit laatste bericht geeft ook aan wan- neer in de toekomst het UWB-kanaal wordt bezet, vanaf nu de reservatietijd genoemd. Op dit tijdstip bericht worden drie tijdsslots achtereenvolgens op het UWB-kanaal uitgevoerd voor afstandsbepaling.
Een volledig overzicht van de berichtuitwisselingen wordt weergegeven in figuur 3.5. De horizon- tale as stelt de tijd voor. Tussen de twee nodes worden berichten uitgewisseld, aangeduid met de pijlen. De afstandsbepaling op het UWB-kanaal wordt aangeduid met de blauwe kleur. Deze berichtuitwisselingen dienen ook als synchronisatiemiddel voor de slots van het UWB- kanaal. Enkel master en slave worden met elkaar gesynchroniseerd. De andere nodes hebben geen nood aan deze synchronisatie. Hier zal verder op worden ingegaan in de implementatie met het TAISC-framework, in sectie 4.2.3.
3.2. CSMA ONTWERP 39 Om de subGHz-berichtuitwisselingen goed te laten verlopen, zijn er extra voorwaarden aanwezig voor het versturen van de berichten. Eerst wordt het InitRanging bericht verstuurd dat de ID van de ontvanger bevat. Elke one-hop buur hoort dit pakket en zal zelf geen pakketten meer sturen voor een vaste, korte timeout. Dit is om de zender de kans te geven het ConfirmRanging bericht te versturen met zo weinig mogelijk kans op collisions. Wanneer een node een InitRanging bericht verstuurt en vervolgens een InitRanging bericht ontvangt, zal deze node ook afstaan om het ConfirmRanging bericht te versturen. Bij het horen van een ConfirmRanging bericht zal elke node voor een langere timeout geen InitRanging berichten meer sturen, totdat het UWB-kanaal weer reserveerbaar is. De meegestuurde reservatietijd in het ConfirmRanging pakket wordt hiervoor gebruikt. Daarmee reserveren geen twee paren die elkaar kunnen horen op hetzelfde moment het UWB-kanaal. Verder wordt er bij dit ontwerp geen extra informatie bijgehouden over de status van het UWB-kanaal. De reservatietijden worden klein gehouden zodat de timeout van buren niet te groot wordt. Tussen het opsturen van het ConfirmRanging bericht en het einde van de reservatietijd wordt het UWB-kanaal niet gebruikt.
Er zijn optimalisaties mogelijk waarbij nodes toch nog subGHz-communicatie verrichten terwijl een buur aan afstandsbepaling doet. Ook kunnen nodes meer informatie bijhouden over de staat van het UWB-kanaal zodat er meerdere reservaties tegelijk mogelijk zijn. Deze zijn echter niet geïmplementeerd maar worden wel opgenomen in future work (hoofdstuk 6).
Iedere node verstuurt ook periodiek een Hello bericht dat enkel het ID van de zender bevat. Zo zijn alle buren op de hoogte van de zender zijn aanwezigheid. Elke node houdt een tabel met records bij van recent gedetecteerde buren. Elk record in de tabel bevat ook een TTL-veld om bij te houden wanneer de buur het laatst gedetecteerd werd. Bij het verlopen van het TTL-veld wordt de buur geschrapt uit de tabel. Deze tabel wordt gebruikt om te bepalen met wie er aan afstandsbepaling wordt gedaan. Hoe dit exact gebeurt is vrij te kiezen. Er kan bv. periodiek aan afstandsbepaling worden gedaan met elke node. Uitgebreidere voorbeelden slaan ook de laatst bekomen afstand op in de tabel. Er kan dan meer gewicht worden gegeven aan nodes waarmee nog niet aan afstandsbepaling is gedaan, of nodes die heel dichtbij liggen uit vorige berekeningen. CSMA-backoffs worden toegepast op het verzenden van het Hello en InitRanging berichten. Nodes wachten dan eerst een willekeurige periode gewacht alvorens deze bericht te proberen versturen. Nadat de backoff verloopt wordt via een CCA-check nagegaan of het medium vrij is. Indien dit niet het geval is, wordt nogmaals een willekeurige periode gewacht. Dit herhaalt zich totdat het subGHz-kanaal vrij is en het pakket wordt verstuurd. Het reageren op ontvangen berichten met ACK- en ConfirmRanging berichten gebeurt onmiddellijk. Daarmee wordt de timeout na het horen van een initRanging bericht beperkt voor een betere performantie. Er zijn twee aanpakken om hidden-node UWB-collisions te vermijden:
afstand overbruggen. Met elke zichtbare buur op het subGHz-kanaal (via het Hello bericht) kan de afstand worden bepaald. Wanneer de slave een InitRanging bericht ontvangt, moet deze eerst nagaan of in zijn one-hop gebied niemand al aan afstandsbepaling doet / wil doen. Zo ja, zullen er collisions op de UWB-kanaal optreden indien de slave het kanaal laat reserveren door de master. Er wordt dus enkel een ACK terug gestuurd indien de slave recent geen Init- of ConfirmRanging berichten heeft gehoord.
One-hop buren van de slave die ook two-hop buren van de master zijn, horen geen Init- en ConfirmRanging berichten. Deze mogen het kanaal niet reserveren, anders ontstaan er hidden-node collisions bij de slave. Dit is te vermijden door de slave ook een ConfirmRan- ging bericht te laten versturen. Daarmee zullen alle one-hop buren van master en slave op de hoogte zijn dat het UWB-kanaal wordt bezet en zullen ze niet aan afstandsbepaling beginnen. De buren mogen ook het kanaal niet laten reserveren.
One-hop buren van de slave kunnen ook op de hoogte worden gebracht door de luisteren naar ACK berichten van de slave. Er wordt dan naar alle drie soorten berichten geluisterd maar dit kan leiden tot slechtere performantie. Wanneer de master toch geen ConfirmRan- ging bericht stuurt (doordat de ACK verloren gaat, of er recent een Init-/Confirmbericht werd ontvangen), zal elke buur van de slave onterecht voor een lange tijd geen afstands- bepaling toelaten.
Er kan niet gegarandeerd worden dat er geen hidden-node collisions zijn bij het opsturen van het ConfirmRanging bericht, tenzij er ook naar ACK’s geluisterd wordt, ten koste van performantie.
• In de tweede aanpak wordt de subGHz-radio zo afgestemd dat de subGHz-signalen alle two- hop buren van het UWB-kanaal overspannen. Een InitRanging bericht wordt nu gehoord door alle nodes die mogelijks hidden-node collisions veroorzaken op het UWB-kanaal. Deze nodes geven de zender de kans om een ConfirmRanging bericht zonder hidden-node collisions te versturen. Bijgevolg zullen geen twee nodes in hetzelfde two-hop UWB-gebied het kanaal op hetzelfde moment reserveren. Er moet nog steeds gecontroleerd worden dat ACK’s mogen worden opgestuurd door na te gaan hoe recent er een InitRanging bericht werd ontvangen. Anders laat een one-hop buur van de slave toe dat het UWB-kanaal door een andere node kan worden gereserveerd. Er moet onder geen omstandigheden meer geluisterd worden naar ACK’s van anderen. Nu zal er geen two-hop UWB-buur van de master het kanaal (laten) reserveren.
Bij deze aanpak moet onderscheid gemaakt worden tussen welke one-hop subGHz-buren ook one-hop UWB-buren zijn, enkel tussen one-hop UWB-buren is er tenslotte UWB- communicatie mogelijk. Het onderscheid is niet onmiddellijk af te leiden. Een eerste manier om dit probleem op te lossen, is om het Hello bericht te versturen volgens de eerste aan- pak. Nodes opgenomen in de burentabel zijn dan one-hop UWB-buren (indien enkel Hello berichten worden gebruikt voor de burentabel aan te vullen). Een tweede manier houdt
3.2. CSMA ONTWERP 41
Figuur 3.6: Afstandsbepaling tussen de zwarte node en een buur. Enkel groene nodes mogen afstandsbepalingen nog toestaan. Afhankelijk van de gebruikte aanpak zullen ook rode nodes
het UWB-kanaal niet meer (laten) reserveren.
geen rekening met het feit dat one-hop subGHz-buren ook one-hop UWB-buren moeten zijn. Twee nodes reserveren dan het kanaal om tijdens afstandsbepaling te besluiten dat ze niet in elkaars UWB-bereik liggen. Deze informatie wordt opgeslagen zodat dit paar het UWB-kanaal niet opnieuw reserveert in de nabije toekomst.
De gevolgen van beide aanpakken worden kort geschetst in figuur 3.6. De zwarte node is de master en initieert afstandsbepaling met een blauwe slave. Blauwe nodes stellen one-hop buren voor. Groene en rode nodes stellen two-hop buren voor, waarvan de rode ook one-hop buren zijn van de slave node. Zowel de blauwe als de rode nodes mogen geen afstandsbepalingen meer toelaten. Bij de eerste aanpak bereikt de zwarte node enkel blauwe nodes. Het is nodig dat de slave een extra bericht verstuurd om de rode nodes op de hoogte te brengen. Eventueel kan er geluisterd worden naar de ACK. Groene nodes horen niks en kunnen ook aan afstandsbepaling doen zonder UWB-collisions. In de tweede aanpak overspant de subGHz-radio van de zwarte node alle nodes. Zowel rode als groene nodes zullen geen afstandsbepaling meer toelaten, terwijl de groene nodes dit wel zouden mogen. Deze aanpak benut het UWB-kanaal daarom minder efficiënt.
Beide aanpakken garanderen bijna zeker dat het UWB-kanaal gereserveerd wordt zonder dat een two-hop buur van het paar het kanaal ook reserveert. Het is nog steeds mogelijk dat er op het subGHz-kanaal collisions optreden, met UWB-collisions tot gevolg.
collisions optreden bij het ConfirmRanging bericht, waardoor buren niet weten dat het UWB- kanaal gereserveerd wordt. Dit leidt mogelijks tot UWB-collisions als buren het UWB-kanaal ook reserveren. De kans dat deze drie soorten collisions achtereenvolgens optreden is echter miniem.
Er wordt geen rekening gehouden wordt met merging collisions. Deze zorgen ervoor dat de drie bovenstaande soorten collisions altijd kunnen optreden, met mogelijke UWB-collisions tot gevolg. Doordat het UWB-kanaal slechts eenmalig en niet ver in de toekomst wordt gereserveerd (versus langdurige TDMA reservaties), is de kans op merging collisions nihil zolang de geplande reservatietijd beperkt is.
4
Verwezenlijking van het CSMA ontwerp
In dit hoofdstuk wordt het CSMA ontwerp van sectie 3.2 geïmplementeerd met behulp van het TAISC-framework. Eerst wordt er een kort overzicht gegeven van de volledige implementatie en wordt het DARPA model beschreven. Vervolgens wordt er meer in detail gegaan in sectie 4.2. De inhoud van de pakketten wordt beschreven, alsook de TAISC-chains, synchronisatie en de interacties tussen het lower- en upper-mac.4.1 Een overzicht
Het ontwerp wordt geïmplementeerd op uitgebreide DWM1001C-chips die ook een subGHz- radio bevatten. Hierover zal meer in detail worden gegaan in sectie 5.1 waar de testconditie wordt beschreven.
De implementatie wordt uitgevoerd op het Contiki-NG besturingssysteem. Dit besturingssys- teem is speciaal ontwikkeld voor IoT toepassingen met resource-contrained chips. De footprint van Contiki-NG is beperkt, er is slechts 30kB ROM en 4kB RAM nodig [48]. Contiki-NG werkt event-driven: zelfgeschreven code reageert op events van bv. timers. Voor een volledig overzicht van Contiki-NG wordt verwezen naar [49].
Eerder in sectie 2.2.3 werd vermeld dat er ook upper-mac’s en modules worden toegevoegd ter 43
ondersteuning van de lower-mac TAISC-code. Deze componenten behoren ook tot de MAC-laag van het DARPA model. Contiki-NG biedt ook reeds geïmplementeerde netwerk- en routingtech- nologieën aan. Deze zijn niet nodig voor de implementatie. Daarom zijn hiervoor ”lege”protocol- len gekozen die informatie doorgeven tussen de lagen zonder iets extra te verwerken (NULLNET en -ROUTING). Er kan vervolgens ook nog eigen applicatiecode worden toegevoegd. In het be- gin werd veel van de implementatie als applicatiecode geschreven. Naarmate het vorderen van de masterproef is veel code verplaatst naar het upper-mac en wordt de applicatielaag enkel nog gebruikt voor testing. Voor een correcte werking van het MAC protocol is er geen applicatiecode nodig (en is daarom leeg gelaten). Er kunnen wel eigen applicaties worden toegevoegd die het MAC protocol aansturen. Afhankelijk van de eisen van deze applicaties kan er meer informatie uitgewisseld worden tussen de lagen.
Een overzicht van de implementatie wordt gegeven in figuur 4.1. Aan de rechterkant wordt het DARPA model aangeduid met accolades. De groene componenten stellen de componenten voor waar het ontwerp wordt geïmplementeerd. De witte componenten zijn reeds geïmplementeerd maar zijn relevant voor de implementatie.
Het lower-mac dient enkel voor pakketten te versturen en ontvangen en houdt geen statusinfor- matie bij. Dit is gedelegeerd aan het upper-mac. Binnenkomende pakketten worden afgegeven aan en verwerkt door het upper-mac. Zo wordt er o.a. bijgehouden welke one-hop buren er recent werden gedetecteerd. Ook bepaalt het upper-mac met wie er aan afstandsbepaling wordt gedaan. Pakketten worden door het upper-mac ingevuld en aan het lower-mac afgegeven om te verstu- ren. Aan hogere lagen kan extra informatie worden blootgesteld, zoals berekende afstanden en aanwezige buren.
De uwb_ranging_v2 module wordt niet gebruikt door de implementatie omdat deze teveel functionaliteiten aanbiedt voor wat er slechts nodig is. Een beperkt aantal code snippets met nodige functionaliteiten zijn opgenomen in het upper-mac.