How to measure the system throughput in the wireless LAN ?

 

[Goal]

   In this tutorial, I will show how to measure the total system throughput in the IEEE 802.11 WLAN. There are two methods used in this tutorial. The first one is that all the wireless nodes send all packets to one receiver. Then the log function in the receiver’s MAC is turned on. After simulation, the total system throughput can be obtained. This method is simple. But when there are many receivers in the system, the throughput calculation becomes harder. In the second method, I will show how to use awk language to parse the trace file to obtain system throughput.

 

[Background]

1.      Refer to http://en.wikipedia.org/wiki/Throughput for throughput definition.

2.      Refer to http://www.gnu.org/software/gawk/manual/gawk.html for awk usage.

 

[Simulation]

1.      In this example, we will create 6 wireless nodes including 5 senders and 1 receiver.

1

2

 

Click Zoom in to make the topology clearer.

3

 

4 

2.      Click the “E” to edit the property. In the following steps, I will show how to prepare a traffic application file and load this file into the NCTUns. Because when the number of wireless nodes becomes larger, it is time-consuming to add each application in each node. The node 1 ~ node 5 is the sender and node 6 is the receiver.

 

(test.tfc)

#nctuns traffic generator file

$node_(1) 0.000000 80.000000 stg -u 1000 30 1.0.1.6

$node_(2) 0.000000 80.000000 stg -u 1000 30 1.0.1.6

$node_(3) 0.000000 80.000000 stg -u 1000 30 1.0.1.6

$node_(4) 0.000000 80.000000 stg -u 1000 30 1.0.1.6

$node_(5) 0.000000 80.000000 stg -u 1000 30 1.0.1.6

$node_(6) 0.000000 80.000000 rtg -u -w throughput

 

5

 

6

 

Then click “E” to see whether the setting works or not.

7

 

8

 

9

 

3.      Open the log function in the receiver’s (node 6) MAC.

10

 

4.       Click “R” and start simulation.

 

5.       After simulation, one can get the “test.80211_N6_P1_InThrput.log” in the test.results folder (assume the project name is test). Part of the content is shown below. From the results, we can see the total system throughput is around 820 Kbytes/second.

11

 

6.      Following, I will show the simulation trace file and trace file format.

12_1

 

13

 

(With this operation, the trace file in the text mode will be saved in the /tmp/ptr.log)

14

 

The trace file format can be referred by the following step.

12_2

 

(Read carefully to understand each field’s meaning)

The printPtr utility program can convert a binary packet transfer

log file (.ptr) into a readable text file. This enables the user to 

observe each packet transmission's (1) starting time, (2) ending time,

(3) real source node ID, (4) real destination node ID, (4) intermediate

source node ID, (5) intermediate destination node ID, etc.

 

 

1. The format of the lines in a converted file:

 

        Field 1: <protocol>

                - 802.3

                - 802.11

                - OPHY

                - GPRS

 

        Field 2: <event type>

                - TX  (transmit)

                - RX  (receive)

                - RTX        (re-transmit)

                - BTX        (broadcast transmit)

                - BRX       (broadcast receive)

                - DROP    (drop)

 

        Field 3: <time (unit: tick) at which the event is started>

        Field 4: <duration (unit: tick) of this event>

 

        Field 5: <packet type>

                - DATA             (802.3/802.11 Data packet)   

                - RTS                (802.11 RequestToSend packet)

                - CTS                (802.11 ClearToSend packet)

                - ACK               (802.11 Acknowledgement packet)

                - BCON            (802.11 Beacon packet)

                - PROBQ          (802.11 Probe Request packet)

                - PROBR          (802.11 Probe Response packet)

                - ASSQ             (802.11 Association Request packet)

                - ASSR              (802.11 Association Response packet)

                - REASSQ (802.11 Reassociation Request packet)

                - REASSR  (802.11 Reassociation Response packet)

                - DISASS   (802.11 Disassociation packet)

                - OBS_DATA     (OPHY OBS data packet)

                - OBS_CTL_NOM    (OPHY OBS normal control packet)

                - OBS_CTL_SW        (OPHY OBS switching control packet)

                - O_LP             (OPHY Light path configuration packet)

                - O_DATA (OPHY Light path data packet)

                - GPRS_DATA   (GPRS user data)

                - GPRS_ACCESS       (GPRS access burst)

                - GPRS_DUMMY     (GPRS dummy burst)

                - GPRS_CTL     (GPRS control burst)

                - ACTION        (802.11e action packet)

                - QoS_DATA     (802.11e Data packet)

                - QoS_ACK       (802.11e Ack packet)

                - QoS_POLL     (802.11e Poll packet)

                - QoS_NULL     (802.11e Null packet)

 

        Field 6: <source/destination node IDs based on the IP addresses>

                - e.g.

                        "<3 5>" means that the packet is sent from node 3

                        to node 5, and, in this packet's IP header, the

                        content of the source field is node 3's IP address

                        and the content of the destination field is node 5's 

                     IP address.

       

        Field 7: <transmitted/received node IDs based on the MAC addresses>

 

                [802.11]

                  - format <physical src, physical dest, mac-address dest>

 

                  - e.g.

                        "<3 5 5>" means that the packet is transmitted from

                        node 3 to node 5 and is exactly received by node 5.

                        In this packet's MAC header, the content of the source

                        field is node 3's MAC address and the content of the

                        destination field is node 5's MAC address.

                        "<3 4 5>" may appear because node 4 is located

                        within node 3's transmission range and it may

                        receive the packet sent from node 3 to node 5.

 

 

                [802.3]/[OPHY]/[GPRS]

                  - format <physical src, physical dest>

 

                  - e.g.

                        "<3 5>" means that the packet is transmitted from

                        node 3 to node 5.

 

        Field 8: <packet's ID>

        Field 9:

                 [802.11]/[802.3]/[OPHY]                

                   - <packet's length (unit: byte)>

 

                 [GPRS]

                   - <burst's length (unit: bit)>

 

        Field 10: <count of successive retransmissions >

 

        Field 11: <drop reason>

                - COLL     (collision)

                - CAP       (capture)

                - DUPX     (duplicate)

                - BER       (bit error)

                - RXERR   (receiving a pkt when transmitting another one)

 

        Field 12: <frequency channel (for 802.11/OPHY/GPRS protocol)>

 

 

2. An example usage is as follows:

 

   % ./printPtr example.ptr

 

 

7.      Prepare an awk program to parse ptr.log.

(throughput.awk)

BEGIN{

  sum_pkt_len=0;

  first=0;

  start_time=0.0;

  end_time=0.0;

}

{

  protocol=$1;

  event_type=$2;

  time=$3*1.0/10000000;

  duration=$4;

  pkt_type=$5;

  src_id=$6;

  dst_id=$7;

  src_phy=$8;

  dest_phy=$9;

  dest_mac=$10;

  pkt_id=$11;

  pkt_len=$12;

 

#only the DATA packet and RX type is counted. I also set the calculation time is from 10 to 20 seconds.

  if(event_type=="RX" && pkt_type=="DATA" && time>=10.0 && time<=20.0){

    if(first==0){

      start_time=time;

      first=1;

    }

    end_time=time;

    sum_pkt_len+=(pkt_len);

  }

}

END{

   throughput=(sum_pkt_len)/(end_time-start_time)/1000;

   printf("system throughput=%.3fkbps\n", throughput);

}

 

15

We can get similar system throughput (820.746 kbps).

With this method, one can easily modify the code to meet different needs.

 

Dr. Chih-Heng Ke (http://csie.nqu.edu.tw/smallko), smallko@gmail.com

Department of Computer Science and Information Engineering, National Quemoy University, Taiwan