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


Ignore:
Timestamp:
Jun 26, 2009, 3:13:49 PM (15 years ago)
Author:
rpl1
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • OFDMReferenceDesign/Applications/Characterization

    v4 v5  
    2323=== OFDM Reference Design Code ===
    2424
    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.
     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
    28 These to types are warpnodeStats (which contains Statistical Data) and warpnodeTraffic (which contains parameters for updating the board)
     28These two types are warpnodeStats (which contains Statistical Data) and warpnodeTraffic (which contains parameters for updating the board)
    2929The two types are defined as:
    3030
    31 __Struct containing node statistics:__
     31Struct containing node statistics:
    3232{{{
    3333typedef struct {
     
    5050}}}
    5151
    52 __Struct containing traffic paramters for a node:__
     52Struct containing traffic paramters for a node:
    5353{{{
    5454typedef struct {
     
    8686}}}
    8787
    88 The traffic struct include a paramter called trafficMode. trafficeMode specifies whether a board is transmittion or receiving. Include two #defines for Transmit and Receive:
     88The traffic struct include a paramter called trafficMode, which specifies whether a board is transmitting or receiving. Include two #defines for Transmit and Receive:
    8989{{{
    9090#define TRANSMIT 1
     
    115115}}}
    116116
    117 This 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.
     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.
    118118
    119119The design of sendAck sends a warpnodeCommand with values, which denote it is the ack version of the warpnodeCommand ({{{myNodeCmd.cmdID = NODECMD_NODEACK}}}).
     
    124124        //Initialize Payload Address
    125125        int pktBuf_payloadAddr;
    126        
     126
    127127        //Fill in a node command reply pkt
    128128        myNodeCmd.structType = STRUCTID_NODECOMMAND;
     
    184184In 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
    185185
    186 The mgmtFromNetworkLayer_callback extends previous codes that have processed mangement structures because this callback process the traffic struct and the new node commands.
    187 
    188 Because 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.
    189 If a packet is a NODE2SVR, the node has received an ack packet or stat packet from the other node.
     186The mgmtFromNetworkLayer_callback extends previous codes that have processed management structures because this callback processes the traffic struct and the new node commands.
     187
     188Because 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.
     189If 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.
     190
     191In the NODECMD, check the cmdStruct->cmdID for the IDs of NODECMD_RESETSTATS, NODECMD_START, NODECMD_STOP, and NODECMC_REQUESTSTATS:
     192
     193NODECMD_RESETSTATS needs to reset all values in myStats and send an ack packet if requested:
     194{{{
     195case NODECMD_RESETSTATS:                               
     196        if( (cmdStruct->nodeID) == myID)
     197        {       
     198                //Reset the good/bad pkt counts and Rx/Tx byte counts
     199                for(i=0; i<WARPNET_NUMNODES; i++)
     200                {
     201                        myStats[i].goodPackets = 0;
     202                        myStats[i].partnerBadPackets = 0;
     203                        myStats[i].otherBadPackets = 0;
     204                        myStats[i].txBytes = 0;
     205                        myStats[i].rxBytes = 0;
     206                        myStats[i].time = 0;
     207                }       
     208                //Send Ack Packet
     209        if(rxSeqNum > 0) sendAck(rxSeqNum);
     210        }
     211}}}
     212
     213NODECMD_START sets a xtime variable start_timer and begins packet generation if the traffic struct had set Mode to TRANSMIT:
     214{{{
     215case NODECMD_START:                                     
     216        XTime_GetTime(&start_timer);
     217        if (Mode==TRANSMIT){
     218        warpmac_startPacketGeneration(packetlength,Time); //second argument is interval in usec
     219        }
     220}}}
     221
     222NODECMD_STOP stops packet generation, calculates the time difference, updates the time variable in myStats, and sends an ack if requested:
     223{{{
     224case NODECMD_STOP:
     225        //xil_printf("NODECMC_STOP \r\n");
     226        warpmac_stopPacketGeneration();
     227       
     228        XTime_GetTime(&end_timer);
     229        long long xtime=0;
     230        xtime=end_timer-start_timer;
     231        for(i=0; i<WARPNET_NUMNODES; i++)
     232        {
     233                myStats[i].time = xtime;
     234        }
     235       
     236        if((cmdStruct->nodeID) == myID)
     237        {       
     238        //Send Ack Packet
     239        if(rxSeqNum > 0) sendAck(rxSeqNum);
     240        }
     241}}}
     242
     243NODECMC_REQUESTSTATS sends the stats packet and ack packet if requested:
     244case NODECMC_REQUESTSTATS:
     245        if( (cmdStruct->nodeID) == myID)
     246        {       
     247                sendStatsPacket(rxSeqNum);
     248                                                       
     249                //Send Ack Packet
     250                if(rxSeqNum > 0) sendAck(rxSeqNum);
     251        }
    190252
    191253
     
    198260                myStats[i].otherBadPackets++;
    199261        }
     262}}}
     263
     264The new design implements a STRUCTID_NODETRAFFIC, which updates the interval between packets, the transmission mode, and packet length:
     265{{{
     266case STRUCTID_NODETRAFFIC: //This is for a traffic struct
     267        trafficStruct = (warpnodeTraffic*)(payload+rxPktOffset);
     268       
     269        if((trafficStruct->nodeID) == myID)
     270        {
     271        //Send Ack Packet
     272        if(rxSeqNum > 0) sendAck(rxSeqNum);
     273       
     274        Time=trafficStruct->txInterval;
     275        Mode=trafficStruct->trafficMode;
     276        packetlength=trafficStruct->txPacketLen;
     277        }               
     278rxPktOffset += sizeof(warpnodeTraffic);
    200279}}}
    201280
     
    213292}}}
    214293
    215 In the main function, global values need to be initialized.
    216 First, 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 
    218 Certain global variables need to be set to default values:
     294In 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)
     295
     296Set these global variables to default values:
    219297{{{
    220298        Mode=0;