Changes between Version 3 and Version 4 of OFDMReferenceDesign/Applications/Characterization


Ignore:
Timestamp:
Jun 26, 2009, 2:33:29 PM (15 years ago)
Author:
rpl1
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • OFDMReferenceDesign/Applications/Characterization

    v3 v4  
    11== OFDM Reference Design - MAC/PHY Performance Characterization ==
    22
    3 This application characterizes the performance of the OFDM Reference Design and a user-supplied MAC implementation. This application utilizes multiple WARP nodes along with external PCs to orchestrate the experiments.
     3This application characterizes the performance of the OFDM Reference Design and a user-supplied MAC implementation. This application utilizes multiple WARP nodes along with external PCs to orchestrate the experiments. The main focus of this design is to show in real time how a computer running a client program written in a non-C language (TCL) can connect to a server, which interprets commands into warpnode management structures and sends to the commands to the warp nodes, which interpret the commands.
    44
    55In this application, the WARP nodes have no MAC or IP addresses. Both nodes run the same program.
     
    2323=== OFDM Reference Design Code ===
    2424
    25 Summary: The following extensions to the warp framework seeks to expand node control by allowing a server to relay requests to warpnodes. The requests are sent as different struct types. These structs will set board parameters to certain values using Command and Traffic structs, and command (command structs) the board to stop and start transmissions, as well as request data (stat structs) about the transmission. This model places the boards in a state where data for wireless transmission is locally created instead of taken from the ethernet.
     25__Summary:__ The following extensions to the OFDM Reference Design expand node control by allowing a server to relay requests to warpnodes. The requests are sent as different struct types. These structs will set board parameters to certain values using Command and Traffic structs, and command (command structs) the board to stop and start transmissions, as well as request data (stat structs) about the transmission. This model places the boards in a state where data for wireless transmission is locally created instead of taken from the ethernet.
    2626
    2727The development of creating an interactive warpnet control requires the introduction of new structure types for the warp platform
     
    2929The two types are defined as:
    3030
    31 ///Struct containing node statistics
     31__Struct containing node statistics:__
     32{{{
    3233typedef struct {
    3334        unsigned char structType;
     
    4748        unsigned long long time;
    4849} warpnodeStats;
    49 
    50 ///Struct containing traffic paramters for a node
     50}}}
     51
     52__Struct containing traffic paramters for a node:__
     53{{{
    5154typedef struct {
    5255        unsigned char structType;
     
    6467        unsigned short reserved1;
    6568} warpnodeTraffic;
    66 
    67 
    68 Because of these types warpnet_node.h needs to be expanded with these two structs.
    69 
    70 Additionally, new pound defines are required for new struct type definitions:
    71 Under //Struct Types for WARP Node <-> Server Packets
     69}}}
     70
     71warpnet_node.h needs to be expanded with these two new structs.
     72
     73Additionally, new pound defines are required for the new setup:
     74Under ''//Struct Types for WARP Node <-> Server Packets''
     75{{{
    7276Add: #define STRUCTID_NODETRAFFIC 0x45
    73 
    74 Under //Node command codes
     77}}}
     78
     79Under ''//Node command codes''
     80{{{
    7581#define NODECMD_SENDPACKET 0x64
    7682#define NODECMD_SENDSTATS 0x65
     
    7884#define NODECMD_STOP 0x67
    7985#define NODECMC_REQUESTSTATS 0x68
     86}}}
    8087
    8188The traffic struct include a paramter called trafficMode. trafficeMode specifies whether a board is transmittion or receiving. Include two #defines for Transmit and Receive:
     89{{{
    8290#define TRANSMIT 1
    8391#define RECEIVE 0
    84 
    85 
    86 Help: In warpmac.c and csmaMac.c you could comment out warpnet_node.h and replace it with my attached warpnet_node2.h
    87 
    88 
    89 We need to expand the number of global variables.
    90 One can choose to include that standard code for processing numRxStructs and place this in mgmtFromNetworkLayer_callback. By including some of these definnitions such as STRUCTID_NODECONTROL, STRUCTID_NODEID, STRUCTID_NODECOMMAND that include commands for reseting, reboots, sendpacket. This standard code will need certain global variables.
     92}}}
     93
     94__Help:__ In warpmac.c and csmaMac.c you could comment out warpnet_node.h and replace it with my attached warpnet_node2.h
     95
     96The remainder of code extensions will occur in csmaMac.c
    9197
    9298For the new extension to the previous frame work, the following global variables will be required:
    9399
     100{{{
    94101///Global Stat struct
    95102warpnodeStats myStats[WARPNET_NUMNODES];
     
    106113unsigned int Time;
    107114unsigned short packetlength;
    108 
    109 
    110 Two functions should be included:
     115}}}
     116
     117This implementation of the OFDM Reference Design uses two similar functions for transmitting ack packets and stat packets when requested . Additionally, both functions require the seqNum as a parameter in order to ensure proper packet organization on the server-client side.
     118
     119The design of sendAck sends a warpnodeCommand with values, which denote it is the ack version of the warpnodeCommand ({{{myNodeCmd.cmdID = NODECMD_NODEACK}}}).
     120The full design for sendAck is as follows:
     121{{{
    111122void sendAck(char rxSeqNum)
    112 
    113 and
    114 
    115 void sendStatsPacket()
    116 
    117 void processControlStruct(warpnodeControl* ctrlStruct)
    118 
    119 
    120 In previous designs of warnet, the emacRx_callback was called when data was specified for the node and when it was specified for transmission over the air. The new design splits
    121 mgmtFromNetworkLayer_callback
    122 
    123 
    124 
    125 
    126 Whenever phyRx_badHeader_callback is called, we need to update all otherBadPackets in myStats. We do this by looping over the number of WARPNET_NUMNODES
     123{
     124        //Initialize Payload Address
     125        int pktBuf_payloadAddr;
     126       
     127        //Fill in a node command reply pkt
     128        myNodeCmd.structType = STRUCTID_NODECOMMAND;
     129        myNodeCmd.nodeID = myID;
     130        myNodeCmd.cmdID = NODECMD_NODEACK;
     131        myNodeCmd.cmdParam = rxSeqNum;
     132                                                       
     133        //Fill in the ethernet packet's header info
     134        txEthPktHeader.ethType = WARPNET_ETHTYPE_NODE2SVR;
     135        memset(&(txEthPktHeader.srcAddr), (unsigned char)myID, 6); //Generic source address; ignored throughout
     136        memset(&(txEthPktHeader.dstAddr), (unsigned char)0xFF, 6); //Broadcast destination address
     137                                               
     138        //Fill in the ethernet packet's header info
     139        txEthPktHeader.pktLength = sizeof(warpnetEthernetPktHeader) + sizeof(warpnodeCommand);
     140        txEthPktHeader.numStructs = 1;
     141        txEthPktHeader.seqNum = rxSeqNum;
     142       
     143        //Copy over data for transmission over wire
     144        pktBuf_payloadAddr = warpphy_getBuffAddr(WARPNET_PKTBUFFINDEX);
     145        memcpy((void *)pktBuf_payloadAddr, &(txEthPktHeader), sizeof(warpnetEthernetPktHeader));
     146        memcpy((void *)pktBuf_payloadAddr+sizeof(warpnetEthernetPktHeader), &(myNodeCmd), sizeof(warpnodeCommand));
     147       
     148        //Send the packet over the wire
     149        warpmac_sendRawEthernetPacket((void *)pktBuf_payloadAddr, txEthPktHeader.pktLength);
     150        return;
     151}
     152
     153}}}
     154
     155The design of sendStatPacket requires a few small modifications:
     156{{{
     157void sendStatsPacket(char rxSeqNum)
     158{
     159        //Initialize Payload Address
     160        unsigned int pktBuf_payloadAddr;
     161       
     162        //Fill in the ethernet packet's header info
     163        txEthPktHeader.pktLength = sizeof(warpnetEthernetPktHeader) + (WARPNET_NUMNODES*sizeof(warpnodeStats));
     164        txEthPktHeader.numStructs = WARPNET_NUMNODES;
     165        txEthPktHeader.seqNum = rxSeqNum;
     166
     167        //Copy the ethernet header and stats payload to a memroy buffer
     168        pktBuf_payloadAddr = warpphy_getBuffAddr(WARPNET_PKTBUFFINDEX);
     169        memcpy((void *)pktBuf_payloadAddr, &(txEthPktHeader), sizeof(warpnetEthernetPktHeader));
     170       
     171        //Copy each stats struct (one per partner)
     172        memcpy((void *)pktBuf_payloadAddr+sizeof(warpnetEthernetPktHeader), &myStats, WARPNET_NUMNODES*sizeof(warpnodeStats));
     173       
     174        //Send the packet over the wire
     175        warpmac_sendRawEthernetPacket((void *)pktBuf_payloadAddr, txEthPktHeader.pktLength);
     176       
     177        return;
     178}
     179}}}
     180
     181
     182When a warpnodeControl struct is received the function processControlStruct updates the node with the parameters in the warpnodeControl struct.
     183
     184In previous designs of warpnet, the emacRx_callback was called when data was specified for the node and when it was specified for transmission over the air. The new design makes a distinction between these two types through mgmtFromNetworkLayer_callback and dataFromNetworkLayer_callback
     185
     186The mgmtFromNetworkLayer_callback extends previous codes that have processed mangement structures because this callback process the traffic struct and the new node commands.
     187
     188Because the nodes are on the same ethernet network, the managmenet callback checks if the ethernet type is from the server to node or vice-versa.
     189If a packet is a NODE2SVR, the node has received an ack packet or stat packet from the other node.
     190
     191
     192Whenever phyRx_badHeader_callback is called,  the otherBadPackets count should be incremented:
     193{{{
    127194        int i;
    128195        //Update every stats struct, since we don't know where this bad pkt came from
     
    131198                myStats[i].otherBadPackets++;
    132199        }
    133 
    134 
    135 
    136 When phyRx_goodHeader_callback is called, two types of updates need to occur if myStats.
    137 If the callback enters the if(state&GOOD) we need to update the goodPacket count, rxBytes and txBytes as follows:
    138                                 myStats[srcNode].goodPackets++;
    139                                 myStats[srcNode].rxBytes += (packet->header.length + NUM_HEADER_BYTES + NUM_PAYLOAD_CRC_BYTES + NUM_PAYLOAD_TAIL_BYTES);
    140                                 myStats[srcNode].txBytes += NUM_HEADER_BYTES;
    141 If the callback enters the if(state&BAD) we need to update the partnerBadPackets:
     200}}}
     201
     202
     203When phyRx_goodHeader_callback is called, depending on the type, the count for goodPackets or partnerBadPackets is incremented
     204If the callback enters the if(state&GOOD) update the goodPacket count, rxBytes and txBytes as follows:
     205        {{{
     206        myStats[srcNode].goodPackets++;
     207        myStats[srcNode].rxBytes += (packet->header.length + NUM_HEADER_BYTES + NUM_PAYLOAD_CRC_BYTES + NUM_PAYLOAD_TAIL_BYTES);
     208        myStats[srcNode].txBytes += NUM_HEADER_BYTES;
     209        }}}
     210If the callback enters the if(state&BAD) update the partnerBadPackets:
     211{{{
    142212        myStats[srcNode].partnerBadPackets++;
    143 
    144 
    145 In the main function, a couple values need to be initialized.
    146 
    147 
    148 
     213}}}
     214
     215In the main function, global values need to be initialized.
     216First, warpmac_enableDataFromNetwork, warpmac_setBaseRate, and warpmac_enableDummyPacketMode. For this application, the boards will be left in DummyPacketMode because to prevent them from transmitting information from the wire. (Due to the nature of the set up with routers, the TCP ack packets sent from the TCL-client computer to the server computer will be sent over the wireless channel. This can create problem because the computers will retransmit the data when they don't receive TCP-acks)
     217
     218Certain global variables need to be set to default values:
     219{{{
     220        Mode=0;
     221        sendStats=0;
     222        Time=0;
     223        packetlength=1470;
     224       
     225        int i; 
     226        //Initialize the Stats Structs
     227        for(i=0; i<WARPNET_NUMNODES; i++)
     228        {
     229                txSequences[i] = 1;
     230                rxSequences[i] = 0;
     231                myStats[i].structType = STRUCTID_NODESTATS;
     232                myStats[i].nodeID = myID;
     233                myStats[i].partnerID = i;
     234                myStats[i].goodPackets = 0;
     235                myStats[i].otherBadPackets = 0;
     236                myStats[i].partnerBadPackets = 0;
     237                myStats[i].rxBytes = 0;
     238                myStats[i].txBytes = 0;
     239                myStats[i].reserved0 = 0;
     240        }
     241}}}
     242
     243Because csmaMac uses randomization to offset packet transmission, the random number generators need to be seeded to different values. Although multiple methods can be used to seed the random number generator, one method uses the xor of the bytes of the node ID with a random clock cycle input and WarpRadio_v1_RSSIData:
     244{{{
     245        (myID ^ ((int) rand_time) ^ WarpRadio_v1_RSSIData(RADIO2_ADDR));
     246}}}
     247
     248Lastly, the Ethernet Packet Header is Initaliezd wit the Source Address and Destination Address:
     249{{{
     250        txEthPktHeader.ethType = WARPNET_ETHTYPE_NODE2SVR;
     251        memset(&(txEthPktHeader.srcAddr), (unsigned char)myID, 6); //Generic source address; ignored throughout
     252        memset(&(txEthPktHeader.dstAddr), (unsigned char)0xFF, 6); //Broadcast destination address
     253}}}
    149254
    150255