wiki:WANMAC

Version 23 (modified by varunnayyar, 18 years ago) (diff)

--

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:

No image "BS.bmp" attached to WANMAC

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:

No image "SS.bmp" attached to WANMAC

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 C File : basestation.c and substation.c

Latest Revision Header File : basestation.h and substation.h

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

This section contains all the data structures used in the protocol with their explaination.

pduStruct

The pduStruct 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. Each packet contains a CID, which indicates the subscriber ID. The CID sof zero is for broadcasting purposes.

pduQueueStruct

The pduQueueStruct is a structure containing an array of frameStructs and a few control bytes to keep track of indices, flags 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.

BSQueueStruct

This is the Base Station data structure, for keeping record of the number of subscribers and for their Receive and Transmit Queues.

MAPEntryStruct

The MAPEntryStruct is a single entry/slot of an uplink or a downlink MAP data structure. It contains the start time and the end time for that entry, which denote the number of bursts allocated in a given slot.

MAPStruct

This is the data structure depicting the MAP. It contains the number of entries of the MAP along with the start time for that MAP. Also it has the pointer to the actual entries array.

IDEntryStruct

This depicts an single ID, namely the Connection ID and the MAC information of the node being described. So far we are not using this, as this is used for Network Entry Protocol.

IDStruct

This contains the list and the number of ids which correspond to the changes to be made in the new map. This is used both for deletion as well as for newly added subscriber ids. So far we are not using this, as this is used for Network Entry Protocol.

Base Station Functions

timer_a_int_handler This is the interrupt handler for the first timer peripheral. It checks to see which was the state it was called in and then changes values of global variables accordingly. This is mainly used to tell when the slot for receiving and transmitting ends.

rxPhyBad This function is used to keep a track of the number of bad packets ( CRC Error ) Received. After receiving it simply resets the receiver.

rxPhyGood This function is called when a packet with the correct CRC is received. It copies the packet into the memory. It then checks the state of the BS machine and the Connection ID of the packet received with the expected Connection ID. Else it simply frees the buffer and in the end resets the receiver. Note, the resetting of the receiver is a must and it must be the last step after packet processing.

BSRxInsertQueuebyMAC The function is called when a packet needs to be inserted into a specific queue of the Base Station. This abstracts the behaviour of the PHY-MAC interaction. The queues are circular and this maintains a notion of a flag, to ensure it does not overwrite on any queue location.

Attachments (7)

Download all attachments as: .zip