| 137 | | == Typedefs == |
| 138 | | [source:/ResearchApps/MAC/ACKMAC/src/ackmac.c@91#L175 frameStruct] |
| 139 | | |
| 140 | | 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. |
| 141 | | |
| 142 | | [source:/ResearchApps/MAC/ACKMAC/src/ackmac.c@91#L191 pktQueueStruct] |
| 143 | | |
| 144 | | 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 [wiki:"Video Board" Video Board], or eventually the ethernet controller. |
| 145 | | |
| 146 | | [source:/ResearchApps/MAC/ACKMAC/src/ackmac.c@91#L206 dataStruct] |
| 147 | | |
| 148 | | 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. |
| | 137 | == Typedefs == This section contains all the data structures used in the protocol with their explaination. |
| | 138 | |
| | 139 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@305#L46 pduStruct] |
| | 140 | |
| | 141 | 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 |
| | 142 | packet contains a CID, which indicates the subscriber ID. The CID sof zero is for broadcasting purposes. |
| | 143 | |
| | 144 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@91#L58 pduQueueStruct] |
| | 145 | |
| | 146 | 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 [wiki:"Video Board" Video Board], or eventually the ethernet controller. |
| | 147 | |
| | 148 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@91#L68 BSQueueStruct] |
| | 149 | |
| | 150 | This is the Base Station data structure, for keeping record of the number of subscribers and for their Receive and Transmit Queues. |
| | 151 | |
| | 152 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@91#L74 MAPEntryStruct] |
| | 153 | |
| | 154 | 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, |
| | 155 | which denote the number of bursts allocated in a given slot. |
| | 156 | |
| | 157 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@91#L79 MAPStruct] |
| | 158 | |
| | 159 | 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 |
| | 160 | the pointer to the actual entries array. |
| | 161 | |
| | 162 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@91#L79 IDEntryStruct] |
| | 163 | |
| | 164 | 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, |
| | 165 | as this is used for Network Entry Protocol. |
| | 166 | |
| | 167 | [source:/ResearchApps/MAC/WANMAC/Basestation/basestation.h@91#L79 IDStruct] |
| | 168 | |
| | 169 | 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 |
| | 170 | as for newly added subscriber ids. So far we are not using this, as this is used for Network Entry Protocol. |
