TAISC

Vaak worden MAC protocollen ontworpen voor specifieke hardware. Een belangrijke reden hier- voor is dat er, zeker bij TDMA, moet rekening worden gehouden met de timings van de hard- ware. Enkele voorbeelden hiervan zijn hoe lang instructies duren, hoe lang toegang tot de radio duurt... De software moet hierop afgestemd worden, eventueel met nop/sleep instructies. De software is dan afhankelijk van de hardware en is niet zomaar correct over te brengen op andere chips met andere timings. Software wordt ook soms speciaal ontworpen voor specifieke hardware voor efficiëntieredenen. [35] geeft verder aan waarom de software van het MAC protocol vaak hardwareafhankelijk is.

Time Annotated Instruction Set Computer, kortweg TAISC, is een closed-source framework

van iMinds VZW waarin makkelijk cross-platform MAC protocollen kunnen worden ontwik- keld [2]. Eerst wordt het protocol ontwikkeld in de hardwareonafhankelijke taal van TAISC. Deze high-level taal lijkt goed op C en analoge programmeertalen. Vervolgens worden hieraan tijdsannotaties toegevoegd door de TAISC-compiler. Deze weet hoe lang instructies duren op bepaalde hardware a.d.h.v. configuratiebestanden. De code wordt vervolgens gecompileerd naar hardwarespecifieke bytecode. Deze bytecode wordt dat op de hardware gezet en vervolgens uitge- voerd door de TAISC execution engine. Dankzij de annotaties wordt ervoor gezorgd dat radio’s op specifieke tijdstippen beheerd worden, wat van cruciaal belang is bij MAC protocollen. De bytecode is ook efficiënt met minimaal performantieverlies.

In figuur 2.6 wordt de volledige TAISC-architectuur weergegeven. Belangrijke onderdelen worden in volgende paragrafen beschreven.

De hardwareonafhankelijke TAISC-taal bevat eigen instructies voor radio’s aan te sturen en arithmetiek. Deze instructies worden vergoten in chains. Chains bevatten reeksen instructies die sequentieel worden uitgevoerd bij het starten van de chain. Dit kan aanschouwd worden als functies van high-level programmeertalen. Bij chains wordt er wel vastgelegd op welk tijdstip de chain wordt gestart.

De starttijd van de chain is daardoor gekend. Omdat er ook gekend is hoe lang instructies duren, is bijgevolg gekend wanneer instructies in de toekomst zullen worden uitgevoerd en de chain weer eindigt. Er is steeds een Init chain. Dit is de eerste chain die wordt uitgevoerd bij het opstarten van de hardware. Vervolgens worden uit deze chain andere chains gestart op specifieke tijdstippen. Deze starten dan ook andere chains, enzovoort. Belangrijk is dat er steeds maximaal één chain actief mag zijn, die wordt beheerd door de TAISC execution engine.

2.2. MAC PROTOCOLLEN VOOR MANET’S 23 In het framework worden ook upper-mac’s gedefinieerd. Deze zijn geschreven in C en dienen ter ondersteuning van de TAISC-code, dat wordt aanschouwd als lower-mac/fysieke laag. Het upper-mac geeft pakketten van hogere lagen door aan het lower-mac om te versturen. Binnen- komende pakketten via de radio worden van het lower-mac aan het upper-mac afgegeven voor verwerking. Bij elk van deze stappen kan het upper-mac eigen statusinformatie bijhouden en eigen beslissingen maken.

Verder handelt het upper-mac ook nog reports van het lower-mac af. Reports zijn vergelijkbaar met events en bevatten een ID, een datapointer en de lengte van het dataveld. Het lower-mac genereert reports doorheen de chain bij het optreden van bepaalde gebeurtenissen. Het is dan aan het upper-mac om te reageren op deze reports, de ID wordt nagegaan en bijbehorende code wordt uitgevoerd. Een voorbeeld is het ”SLOT_END_REPORT”dat het einde van een TDMA slot aankondigt, het upper-mac kan hierop reageren door bv. na te gaan wat voor slot er eindigde en een pakket te versturen in een volgend slot.

Naast upper-mac’s kunnen er ook modules gedefinieerd worden. Modules encapsuleren extra, herbruikbare functionaliteiten die niet in upper-mac’s thuishoren bv. nodige functies voor af- standsbepaling. Upper-mac’s opteren dan om deze modules te gebruiken afhankelijk van de toepassing.

Als laatste wordt er een voorbeeld gegeven van een TAISC-chain. Listing 2.1 geeft aan hoe een pakket kan worden verstuurd nadat er een CCA-check werd uitgevoerd.

Listing 2.1: Pakket versturen met TAISC

void chain_send_packet ( void ){

i f ( waitForTrigger (1 , TAISC_EVENT_dataplane_txFrameAvailable )){

_loadFrame (R1 , packet ) ;

i f ( waitForTrigger ( reliableCCA , _TAISC_EVENT_radio_mediumIsBusy(R1) ) ) {

_flushTx (R1 ) ; txTrigger ( 0 ) ; } else { _tx (R1 , 0 ) ; txTrigger ( 1 ) ; } } }

Eerst wordt er nagegaan of er een pakket moet worden verstuurd. Zo ja, wordt dit pakket op radio R1 geplaatst. Vervolgens wordt er nagegaan of het kanaal bezet is. Zo niet, wordt het

pakket onmiddellijk verstuurd en wordt aan het upper-mac gerapporteerd dat dit succesvol is gebeurd. Bij het falen van de CCA-check wordt de radio geflusht en wordt aan het upper-mac gerapporteerd dat het verzenden is gefaald. Merk op dat de loadFrame-instructie voor de CCA- check gebeurt zodat het pakket zo snel mogelijk na de CCA-check wordt verstuurd. Anders worden er na de CCA-check enkele milliseconden gewacht, waarin een andere node mogelijks een pakket begint te versturen.

Dit voorbeeld kan uitgebreid worden voor CSMA toe te passen. Er moet dan nog een backoff- strategie worden geïmplementeerd. Een simpele strategie zou bv. de chain periodiek opnieuw uitvoeren totdat het pakket verzend raakt.

Voor meer informatie omtrent TAISC wordt verwezen naar [2].