Description

The WANMAC is a TDM MAC that serves as a framework for all Scheduled Access MACs. In this scheme, their is one Base Station (BS) and many Subscriber Stations (SS) forming a Star Topology. The BS broadcasts downlink and uplink maps periodically which tells a SS when would be its turn to send and receive data, as is done in 802.16 or Wimax. For the first implementation we have assumed the system to be in equilbrium i.e. no new SS`s are added to the system. Their is no notion of an ACK here and no contention issues.

This behavioral description of both BS and SS can be transformed to state-machines, which in turn can be transformed to C-code. A few typical transitions through states are numbered. For the Base Station, we have the following states:

1) Process Map : The BS decides the allocation of slots for the uplink and the downlink to the various SS. Each slot consists of the number of burst units allowed. For our TDM system we have assumed a equal slots for all the subscribers. Also, new Connection ID`s are allocated during this stage.

2) Send Map : The Base Station broadcasts the map created in the above stage, using a special Connection ID 0, meant for all the Subscriber nodes already in the system.

3)DL Burst : The BS emits on the downlink as specified by Map transmitted in the previous stage. To distinguish between each of the SS it uses a Connection ID, which corresponds to its own queues. This can be heard by all the nodes and they too distinguish it by their Connection ID.

4) Contention Time : This stage is for future reserve. Any new SS wishing to join the system and already synchronized with BS would send in a Request during this stage. For the time being we make the BS and the SS sleep during this period.

5) UL Burst : The BS receives on the uplink as specified by Map transmitted in the previous stage. Again it distinguishes between various SS`s by the use of Connection ID.

6) Map Sending : If the BS does not receive from any SS for a long time, it enters this special stage. After coming to this state, the BS emits MAPS Periodically and simply waits for the rest of the frame.

For the Subscriber Station, the states look like the following:

1) Map Wait : A Subscriber Station begins by waiting for a good map broadcast. This is like polling for reception of a Map. The SS state machine cannot proceed any further untill it receives any further

2) Read Map : This basically involves processing of the map read and extracting the uplink time, downlink time and the waiting period for a subscriber.

3)Wait DL Burst : This is the waiting stage after which a SS can receive downlink bursts from the base station.

4) Rx DownLink : As the receive process is asynchronous, this invloves setting timer and receiving packets before timeout, meant for that node from the BS. It simply fills up its queues or hands up to the application layer.

5) Contention Period : As of now this stage simple involves waiting for the desired time, but can be used to exchange messages with the BS for increasing decreasing its slot size as per its demand.

6) Wait UL Burst : This is the waiting stage afer which a SS can transmit uplink downlink bursts from the base station.

7) Tx Uplink : The SS reads from it Tx Queue and transmits to the BS. Before starting to transmit it sets a timer which would tell it when to stop transmitting. After transmitting it simply waits for another map.

The behavior described above is a small subset of that which is implemented in the attached code. Here, we bridge that state machine to a source and a sink (ethernet and OFDM physical layer respectively for a transmitter, and vice versa for a receiver). In that way, we have a project that creates a virtual wire between three WARP node, one BS and two SS. Any ethernet and higher layer traffic will be forwarded across the wireless medium.

Code

Latest Revision: basestation.c and substation.c

Note: This code relies on many external dependencies and will not compile on traditional architectures.

Documentation

When the MAC program is executed, it sets up the external devices that must be used (Ethernet​, Radio and PHY​, and Automatic Gain Control​).

Typedefs

frameStruct​

The frameStruct type is the internal representation of what information is included in the frame sent to the PHY. There is a one to one conversion between this struct and array of bytes interpreted by the PHY. This allows us to abstract away from this array structure, making our MAC's behavior independent of the header format.

pktQueueStruct​

The pktQueueStruct is a structure containing an array of frameStructs and a few control bytes to keep track of indices, and the length of the queue. This queue can serve two purposes. The first use is during the receive phase of the MAC. When the MAC receives a packet from another node, it needs to put the payload somewhere. Because the specification of the connection between our MAC and higher networking layers is still in the process of being defined, we need a method of abstracting our layer away from this future glue layer. An acceptable solution is to simply copy packets from the PHY's memory space into a queue. It is assumed that another in the xilkernel will be taking these packets and giving them to higher layers. The other use of this queue is on the transmit side of the MAC. Again, the connection to the higher layer is still being defined, so we need a way of getting packets to send in the meantime. You can think of the transmit queue as analogous to the receive queue, in that some process somewhere gives us packets to send. This could be the Video Board, or eventually the ethernet controller.

dataStruct​

The dataStruct contains miscellaneous control bytes for proper MAC behavior. These tell the MAC its own address, whether or not to sniff other node's packets, and whether to send and receive negative acknowledgements. Additionally, it is in this struct that the MAC keeps track of re-sends and backoff timers.

Functions

ackmac_main​

This function is the primary thread spawned by the xilkernel via the shell. It really has two purposes: during startup it must initialize memory spaces and do general set-up tasks such as setting up interrupts, and during all other times, it polls over status bytes that determine if the node is ready and able to transmit a new packet, and if so, it calls the tx function.

tx​

The transmitter can send new packets, resend old packets, send ACKs and send nACKs, depending on what state the machine is in when it is called. To help abstraction, the transmitter does not directly send packets. Instead, it passes them off to a dedicated function that interfaces directly with the PHY layer (see mem2ifc).

rx​

The receiver gets called by the PHY receiver whenever it has received a packet. The receiver has different behavior depending on whether the packet received was destined for itself or another node. Also, it sets the state machine appropriately depending on what was received (ACK, nACK, or data).

timer_a_int_handler​

This is the interrupt handler for the first timer peripheral. It updates the number of dropped packets and number of timeouts, then sets the backoff timer before attempting to resend.

setTimer​

The setTimer function allows the use of software timers for the MAC. Currently, the two types of timers needed are timeouts and backoffs. The timeout is a preset amount of time that the node is willing to wait for an ACK before retransmitting. The backoff occurs whenever a collision is inferred. The backoff is an exponential uniformly distributed random variable.

writeMem2Ifc​

This function is responsible for converting the frameStruct type into an array of bytes to be sent in the PHY layer. Because this conversion effectively defines the frame format, placing this into its own function allows us to upgrade frame formats without affecting the behavior of the MAC itself.

writeIfc2Mem​

This is the inverse process of the previous function. This converts the array of bytes back into something that the MAC can understand (the frameStruct type).

writeMem2Mem​

This is responsible for copying received packet structure into receive queue for higher layers to access.

checkSum​

The checksum is used to infer corrupted data upon receipt of a packet. This checksum is a very simple addition of bytes. If we choose to implement other checksum algorithms, we can replace this function without the MAC even knowing.