Demonstration 8
This demonstration consists of a series of activities used to introduce the TDMA Event Scheduler radio model.
Background information for this demonstration includes:
This activity will demonstrate a TDMA Event Schedule emulation running a simple round-robin schedule.
-
Change directory into the Demonstration 8 directory
[me@host emane-tutorial]$ cd 8 -
For this demonstration we will be instantiating 10 TDMA NEMs. Let's take a look at the referenced NEM definition file tdmanem.xml.
<!DOCTYPE nem SYSTEM "file:///usr/share/emane/dtd/nem.dtd"> <nem> <transport definition="transvirtual.xml"/> <mac definition="tdmaradiomodel.xml"/> <phy> <param name="fixedantennagain" value="0.0"/> <param name="fixedantennagainenable" value="on"/> <param name="bandwidth" value="1M"/> <param name="noisemode" value="all"/> <param name="propagationmodel" value="precomputed"/> <param name="systemnoisefigure" value="4.0"/> <param name="subid" value="7"/> </phy> </nem>
This NEM configuration resembles those we have seen so far in the tutorial. It is good to take note that the propagationmodel is set to precomputed, so we know pathloss events are required for the emulation.
Let's look at the radio model configuration in tdmaradiomodel.xml.
<!DOCTYPE mac SYSTEM "file:///usr/share/emane/dtd/mac.dtd"> <mac library='tdmaeventschedulerradiomodel'> <param name='fragmentcheckthreshold' value='2'/> <param name='fragmenttimeoutthreshold' value='5'/> <param name='neighbormetricdeletetime' value='60.0'/> <param name='neighbormetricupdateinterval' value='1.0'/> <param name='queue.aggregationenable' value='on'/> <param name='queue.aggregationslotthreshold' value='90.0'/> <param name='queue.depth' value='255'/> <param name='queue.fragmentationenable' value='on'/> <param name='queue.strictdequeueenable' value='off'/> <param name="pcrcurveuri" value='file:///usr/share/emane/xml/models/mac/tdmaeventscheduler/tdmabasemodelpcr.xml'/> </mac>
The TDMA model has a lot of capability but unlike the other models we have seen, this model gets a bulk of its configuration from TDMA Scheduler events. Before we talk about those, let's look at the available configuration parameters.
For the TDMA radio model the most commonly used configuration parameters are:
-
A TDMA Schedule event contains an NEM's view of a specified schedule. This view includes the slots that are assigned to an NEM for transmit, receive and idle functions. A full schedule contains information about the structure of the schedule:
- Number of frames in a multiframe
- Number of slots in a frame
- Slot overhead in microseconds
- Slot duration in microseconds
- Transceiver bandwidth
A full or update schedule contains slot information for one or more frames. For the give schedule multiframe, you can specify a default frequency, power, class and datarate for all frames and slots. Those defaults can be override at the frame and individual slot levels.
See Defining a TDMA Schedule for more information.
Lets have a look at schedule.xml:
<emane-tdma-schedule> <structure frames="1" slots="10" slotoverhead="0" slotduration="1500" bandwidth="1M"/> <multiframe frequency="2.4G" power="0" class="0" datarate="100M"> <frame index="0"> <slot index="0" nodes="1"/> <slot index="1" nodes="2"/> <slot index="2" nodes="3"/> <slot index="3" nodes="4"/> <slot index="4" nodes="5"/> <slot index="5" nodes="6"/> <slot index="6" nodes="7"/> <slot index="7" nodes="8"/> <slot index="8" nodes="9"/> <slot index="9" nodes="10"/> </frame> </multiframe> </emane-tdma-schedule>
This is a very simple schedule. There is 1 frame in the multiframe and 10 slots in the frame. Each slot is 1.5 milliseconds. Each NEM in the schedule is assigned 1 transmit slot and 9 receive slots.
Let's start up the demo and have a look.
-
Start up the OLSR topology viewer
[me@host 8]$ ../scripts/olsrlinkview.py & -
Start the demonstration
[me@host 8]$ sudo ./demo-start -
Send in the TDMA Schedule
The emaneevent-tdmaschedule application can be used to publish TDMA Schedule events from XML.
[me@host 8]$ emaneevent-tdmaschedule schedule.xml -i emanenode0 -
Let's take a look at node-1's schedule using emaensh
Each NEM receives its own TDMA Schedule event with that NEM's view of the schedule.
[me@host 8]$ emanesh node-1 get table nems mac scheduler.ScheduleInfoTable scheduler.StructureInfoTable nem 1 mac scheduler.ScheduleInfoTable | Index | Frame | Slot | Type | Frequency | Data Rate | Power | Class | Destination | | 0 | 0 | 0 | TX | 2400000000 | 100000000 | 0.0 | 0 | 0 | | 1 | 0 | 1 | RX | 2400000000 | | | | | | 2 | 0 | 2 | RX | 2400000000 | | | | | | 3 | 0 | 3 | RX | 2400000000 | | | | | | 4 | 0 | 4 | RX | 2400000000 | | | | | | 5 | 0 | 5 | RX | 2400000000 | | | | | | 6 | 0 | 6 | RX | 2400000000 | | | | | | 7 | 0 | 7 | RX | 2400000000 | | | | | | 8 | 0 | 8 | RX | 2400000000 | | | | | | 9 | 0 | 9 | RX | 2400000000 | | | | | nem 1 mac scheduler.StructureInfoTable | Name | Value | | bandwidth | 1000000 | | frames | 1 | | slotduration | 1500 | | slotoverhead | 0 | | slots | 10 |When you compare that to node-2 you see the only difference for this schedule is who transmits when.
[me@host 8]$ emanesh node-2 get table nems mac scheduler.ScheduleInfoTable scheduler.StructureInfoTable nem 2 mac scheduler.ScheduleInfoTable | Index | Frame | Slot | Type | Frequency | Data Rate | Power | Class | Destination | | 0 | 0 | 0 | RX | 2400000000 | | | | | | 1 | 0 | 1 | TX | 2400000000 | 100000000 | 0.0 | 0 | 0 | | 2 | 0 | 2 | RX | 2400000000 | | | | | | 3 | 0 | 3 | RX | 2400000000 | | | | | | 4 | 0 | 4 | RX | 2400000000 | | | | | | 5 | 0 | 5 | RX | 2400000000 | | | | | | 6 | 0 | 6 | RX | 2400000000 | | | | | | 7 | 0 | 7 | RX | 2400000000 | | | | | | 8 | 0 | 8 | RX | 2400000000 | | | | | | 9 | 0 | 9 | RX | 2400000000 | | | | | nem 2 mac scheduler.StructureInfoTable | Name | Value | | bandwidth | 1000000 | | frames | 1 | | slotduration | 1500 | | slotoverhead | 0 | | slots | 10 |
-
Let's see how well node-1 is keeping up with its transmit slot schedule
The TxSlotStatusTable shows how well transmit slot opportunities are being serviced. For every assigned transmit slot, the table will show whether the scheduler could have/did transmit (Valid) or if there was an error due to timing (Missed) or sizing (Big). The table also breaks down in quantiles, where in the slot the radio model is when it wakes for transmit.
[me@host 8]$ emanesh node-2 get table nems mac TxSlotStatusTable nem 1 mac TxSlotStatusTable | Index | Frame | Slot | Valid | Missed | Big | .25 | .50 | .75 | 1.0 | 1.25 | 1.50 | 1.75 | >1.75 | | 0 | 0 | 0 | 9057 | 26 | 0 | 9057 | 0 | 0 | 0 | 0 | 0 | 0 | 26 |
-
Similarly we can also see how well node-1 is keeping up with its receiving slot schedule
The RxSlotStatusTable shows how well frames are being received. For every over-the-air frame, the table shows whether it was received in the correct slot (Valid), received in the wrong receive slot (Missed), received in the correct slot but during idle (Idle), received in the correct slot but during transmit (Tx) or if the end-of-transmission time of the frame crossed slot boundaries (Long) possibly due to propagation delay. The table also breaks down in quantiles, where in the slot the radio model is when it receives a frame.
[me@host 8]$ emanesh node-1 get table nems mac RxSlotStatusTable nem 1 mac RxSlotStatusTable | Index | Frame | Slot | Valid | Missed | Idle | Tx | Long | .25 | .50 | .75 | 1.0 | 1.25 | 1.50 | 1.75 | >1.75 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | | 2 | 0 | 2 | 395 | 0 | 0 | 0 | 1 | 302 | 93 | 0 | 0 | 1 | 0 | 0 | 0 | | 3 | 0 | 3 | 392 | 0 | 0 | 0 | 0 | 296 | 96 | 0 | 0 | 0 | 0 | 0 | 0 | | 4 | 0 | 4 | 389 | 0 | 0 | 0 | 1 | 276 | 113 | 0 | 0 | 1 | 0 | 0 | 0 | | 5 | 0 | 5 | 399 | 0 | 0 | 0 | 1 | 321 | 78 | 0 | 0 | 0 | 0 | 1 | 0 | | 6 | 0 | 6 | 69 | 0 | 0 | 0 | 2 | 53 | 16 | 0 | 0 | 0 | 2 | 0 | 0 | | 7 | 0 | 7 | 78 | 3 | 0 | 0 | 0 | 52 | 26 | 0 | 0 | 3 | 0 | 0 | 0 | | 8 | 0 | 8 | 76 | 1 | 0 | 0 | 5 | 52 | 24 | 0 | 0 | 0 | 0 | 1 | 5 | | 9 | 0 | 9 | 71 | 0 | 0 | 0 | 0 | 55 | 16 | 0 | 0 | 0 | 0 | 0 | 0 |
The emulator physical layer will sometimes overwrite the start-of-transmission time of a received over-the-air frame based on its configured timesyncthreshold.
This explains the 12 Long frames seen above and can be verified checking the physical layer's numTimeSyncThresholdRewrite statistic.
[me@host 8]$ emanesh node-1 get stat nems phy numTimeSyncThresholdRewrite nem 1 phy numTimeSyncThresholdRewrite = 12
-
We're finished but leave the demonstration running for the next activity.
[me@host 8]$ sudo ./demo-stop
This activity will demonstrate how easy it is to knock a node out of the network by sending an incomplete schedule. Let's try to change the schedule so that NEM 3 will transmit on 2GHz.
-
Take a look at our first attempt of changing NEM 3's tx slot frequency:
<emane-tdma-schedule > <structure frames="1" slots="10" slotoverhead="0" slotduration="1500" bandwidth="1M"/> <multiframe frequency="2.4G" power="0" class="0" datarate="100M"> <frame index="0"> <slot index="0" nodes="1"/> <slot index="1" nodes="2"/> <slot index="2" nodes="3"> <tx frequency='2G'/> </slot> <slot index="3" nodes="4"/> <slot index="4" nodes="5"/> <slot index="5" nodes="6"/> <slot index="6" nodes="7"/> <slot index="7" nodes="8"/> <slot index="8" nodes="9"/> <slot index="9" nodes="10"/> </frame> </multiframe> </emane-tdma-schedule>
-
Send in the new schedule
[me@host 8]$ emaneevent-tdmaschedule -i emanenode0 schedule-tx_3.xml -
Take a look at the OLSR topology viewer. Everything is good, right?
What happened? Those solid to dashed links coming from node-3 indicate one-way links. So node-3 can hear other nodes but no one can hear node-3. Eventually olsrd will time those links completely out.
Let's take a look at node-3's schedule.
[me@host 8]$ emanesh node-3 get table nems mac scheduler.ScheduleInfoTable nem 3 mac scheduler.ScheduleInfoTable | Index | Frame | Slot | Type | Frequency | Data Rate | Power | Class | Destination | | 0 | 0 | 0 | RX | 2400000000 | | | | | | 1 | 0 | 1 | RX | 2400000000 | | | | | | 2 | 0 | 2 | TX | 2000000000 | 100000000 | 0.0 | 0 | 0 | | 3 | 0 | 3 | RX | 2400000000 | | | | | | 4 | 0 | 4 | RX | 2400000000 | | | | | | 5 | 0 | 5 | RX | 2400000000 | | | | | | 6 | 0 | 6 | RX | 2400000000 | | | | | | 7 | 0 | 7 | RX | 2400000000 | | | | | | 8 | 0 | 8 | RX | 2400000000 | | | | | | 9 | 0 | 9 | RX | 2400000000 | | | | |Ok, that looks good. So why is node-1 not receiving. Let's take a look at his BroadcastPacketDropTable0.
[me@host 8]$ emanesh node-1 get table nems phy BroadcastPacketDropTable0 nem 1 phy BroadcastPacketDropTable0 | NEM | Out-of-Band | Rx Sensitivity | Propagation Model | Gain Location | Gain Horizon | Gain Profile | Not FOI | Spectrum Clamp | | 2 | 0 | 0 | 20 | 0 | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 20 | 0 | 0 | 0 | 355 | 0 | | 4 | 0 | 0 | 20 | 0 | 0 | 0 | 0 | 0 | | 5 | 0 | 0 | 20 | 0 | 0 | 0 | 0 | 0 | | 6 | 0 | 0 | 21 | 0 | 0 | 0 | 0 | 0 | | 7 | 0 | 701 | 20 | 0 | 0 | 0 | 0 | 0 | | 8 | 0 | 695 | 21 | 0 | 0 | 0 | 0 | 0 | | 9 | 0 | 705 | 20 | 0 | 0 | 0 | 0 | 0 | | 10 | 0 | 705 | 20 | 0 | 0 | 0 | 0 | 0 |You see the Not FOI counts? That means node-1 is receiving over-the-air frames on a frequency that it was not set to receive on.
Take a look at the schedule from node-1's perspective.
[me@host 8]$ emanesh node-1 get table nems mac scheduler.ScheduleInfoTable nem 1 mac scheduler.ScheduleInfoTable | Index | Frame | Slot | Type | Frequency | Data Rate | Power | Class | Destination | | 0 | 0 | 0 | TX | 2400000000 | 100000000 | 0.0 | 0 | 0 | | 1 | 0 | 1 | RX | 2400000000 | | | | | | 2 | 0 | 2 | RX | 2400000000 | | | | | | 3 | 0 | 3 | RX | 2400000000 | | | | | | 4 | 0 | 4 | RX | 2400000000 | | | | | | 5 | 0 | 5 | RX | 2400000000 | | | | | | 6 | 0 | 6 | RX | 2400000000 | | | | | | 7 | 0 | 7 | RX | 2400000000 | | | | | | 8 | 0 | 8 | RX | 2400000000 | | | | | | 9 | 0 | 9 | RX | 2400000000 | | | | |Something was wrong with the modified schedule we sent. We forgot to tell the other NEMs to listen on 2GHz.
-
Take a look at the new "new" schedule: schedule-tx_3_with_rx.xml.
<emane-tdma-schedule > <structure frames="1" slots="10" slotoverhead="0" slotduration="1500" bandwidth="1M"/> <multiframe frequency="2.4G" power="0" class="0" datarate="100M"> <frame index="0"> <slot index="0" nodes="1"/> <slot index="1" nodes="2"/> <slot index="2" nodes="3"> <tx frequency='2G'/> </slot> <slot index="2" nodes="1:2,4:10"> <rx frequency='2G'/> </slot> <slot index="3" nodes="4"/> <slot index="4" nodes="5"/> <slot index="5" nodes="6"/> <slot index="6" nodes="7"/> <slot index="7" nodes="8"/> <slot index="8" nodes="9"/> <slot index="9" nodes="10"/> </frame> </multiframe> </emane-tdma-schedule>
The part that was missing told the other NEMs that slot 2 was a receive on 2Ghz.
Let's send that schedule in and see what happens.
[me@host 8]$ emaneevent-tdmaschedule -i emanenode0 schedule-tx_3_with_rx.xml -
Once you see node-3 join back in, stop the demonstration with demo-stop.
[me@host 8]$ sudo ./demo-stop