Changes between Version 18 and Version 19 of OFDMReferenceDesign/Applications/Characterization


Ignore:
Timestamp:
Jul 1, 2009, 1:04:40 PM (15 years ago)
Author:
rpl1
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • OFDMReferenceDesign/Applications/Characterization

    v18 v19  
    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. The main focus of this design shows 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, to send commands to the warp nodes, which execute the commands.
     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 shows 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, using the server to send commands to the warp nodes, which execute the commands.
    44
    55In this application, the WARP nodes have no MAC or IP addresses. Both nodes run the same program.
    … …  
    2929=== OFDM Reference Design Code ===
    3030
    31 __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. The two complete codes for the modifications are the attached files csmaMac.c and warpnet_node2.c
    32 
    33 The development of creating an interactive warpnet control requires the introduction of new structure types for the warp platform
     31__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 C struct types.  Command and Traffic structs set board parameters, while Command structs are used 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. The two complete codes for the modifications OFDM are the attached files csmaMac.c and warpnet_node2.c
     32
     33The development of creating an interactive warpnet control requires the introduction of new structure types for the warp platform.
    3434These two types are warpnodeStats (which contains Statistical Data) and warpnodeTraffic (which contains parameters for updating the board)
    3535The two types are defined as:
    … …  
    8080Under ''//Struct Types for WARP Node <-> Server Packets''
    8181{{{
    82 Add: #define STRUCTID_NODETRAFFIC 0x45
     82#define STRUCTID_NODETRAFFIC 0x45
    8383}}}
    8484
    … …  
    9292}}}
    9393
    94 The traffic struct include a paramter called trafficMode, which specifies whether a board is transmitting or receiving. Include two #defines for Transmit and Receive:
     94The traffic struct include a parameter called trafficMode, which specifies whether a board is transmitting or receiving. Include two #defines for Transmit and Receive:
    9595{{{
    9696#define TRANSMIT 1
    … …  
    9898}}}
    9999
    100 __Help:__ In warpmac.c and csmaMac.c you could comment out warpnet_node.h and replace it with my attached warpnet_node2.h
     100__Help:__ In warpmac.c and csmaMac.c you could comment out warpnet_node.h and replace it with the attached warpnet_node2.h
    101101
    102102The remainder of code extensions will occur in csmaMac.c
    … …  
    124124
    125125The design of sendAck sends a warpnodeCommand with values, which denote it is the ack version of the warpnodeCommand ({{{myNodeCmd.cmdID = NODECMD_NODEACK}}}).
     126
    126127The full design for sendAck is as follows:
    127128{{{
    … …  
    186187
    187188
    188 When a warpnodeControl struct is received the function processControlStruct updates the node with the parameters in the warpnodeControl struct.
     189The function processControlStruct updates the node with the parameters in the warpnodeControl struct.
    189190
    190191In 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
    191192
    192 The mgmtFromNetworkLayer_callback extends previous codes that have processed management structures because this callback processes the traffic struct and the new node commands.
     193The mgmtFromNetworkLayer_callback extends previous code used to process management structures because this callback processes the new traffic struct and the new node commands.
    193194
    194195Because the nodes are on the same Ethernet network, the management callback checks if the Ethernet type is from the server to node or vice-versa.
    195 If a packet is a NODE2SVR, the node has received an ack packet or stat packet from the other node. Because both nodes are on the same network and can see all traffic, in the implementation for SVR2NODE nodes checks the nodeID in the structs to determine whether the command is meant for it.
     196If a packet is a NODE2SVR, the node has received an ack packet or stat packet from the other node. Because both nodes are on the same network and see all traffic on the network, the implementation for SVR2NODE nodes checks if the nodeID in the structs equals myID.
    196197
    197198In the NODECMD, check the cmdStruct->cmdID for the IDs of NODECMD_RESETSTATS, NODECMD_START, NODECMD_STOP, and NODECMC_REQUESTSTATS:
    … …  
    287288
    288289
    289 When phyRx_goodHeader_callback is called, depending on the type, the count for goodPackets or partnerBadPackets is incremented
     290When phyRx_goodHeader_callback is called, either the count for goodPackets or partnerBadPackets is incremented.
     291
    290292If the callback enters the if(state&GOOD) update the goodPacket count, rxBytes and txBytes as follows:
    291293        {{{
    … …  
    294296        myStats[srcNode].txBytes += NUM_HEADER_BYTES;
    295297        }}}
     298
    296299If the callback enters the if(state&BAD) update the partnerBadPackets:
    297300{{{
    … …  
    299302}}}
    300303
    301 In the main function, set 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)
     304In the main function, set warpmac_enableDataFromNetwork, warpmac_setBaseRate, and warpmac_enableDummyPacketMode. For this application, the boards will be left in DummyPacketMode to prevent the nodes 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)
    302305
    303306Set these global variables to default values:
    … …  
    326329}}}
    327330
    328 Include the callback for management packets 
     331Include the callback for management packets:
    329332{{{
    330333        warpmac_setMgmtFromNetworkCallback((void *)mgmtFromNetworkLayer_callback);
    … …  
    342345        memset(&(txEthPktHeader.dstAddr), (unsigned char)0xFF, 6); //Broadcast destination address
    343346}}}
    344 
    345 
    346347
    347348