Anda di halaman 1dari 41

GNURadio MAC Final Report

GNURadio MAC Team


April 25, 2011

Contents
1 Background
1.1 USRP . . . . . . .
1.2 GNURadio . . . .
1.3 CSMA/CA . . . .
1.4 802.11 MAC Frame

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

2 System Design and Implementation


2.1 Architecture overview . . . . . . . . . . . . . . . .
2.2 PHY layer - based on USRP . . . . . . . . . . . .
2.2.1 Make MAC layer Independent of Hardware
2.2.2 PHY layer Overview . . . . . . . . . . . .
2.3 MAC layer - CSMA/CA . . . . . . . . . . . . . .
2.3.1 MAC layer Overview . . . . . . . . . . . .
2.3.2 MAC State . . . . . . . . . . . . . . . . .
2.3.3 TX and RX Flow . . . . . . . . . . . . . .
2.4 802.11 MAC frame practice . . . . . . . . . . . .
2.5 GUI - Event Driven Practice . . . . . . . . . . . .
3 The Correctness Testing
3.1 Test Case 1 . . . .
3.2 Test Case 2 . . . .
3.3 Test Case 3 . . . .
3.4 Test Case 4 . . . .
3.5 Test Case 5 . . . .
3.6 Test Case 6 . . . .
3.7 Test Case 7 . . . .

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

3
3
3
3
5

.
.
.
.
.
.
.
.
.
.

6
6
6
6
8
8
8
9
10
10
10

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

14
14
14
14
15
16
16
17

4 Efficiency of the GNURadio-MACer


4.1 Pure Theoretical Efficiency of CSMA/CA MAC
4.2 USRP Impact on Theoretical MAC Efficiency .
4.3 Practice Efficiency of different cases . . . . . .
4.3.1 Two transceivers - Efficiency . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

18
18
20
20
21

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

4.3.2

Four transceivers - Efficiency & Fairness . . . . . . . . .

A Troubleshooting
A.1 Debugging GNURadio . . . . . . . . . .
A.2 PHY CRC Error . . . . . . . . . . . . . .
A.3 First Packet Missing . . . . . . . . . . . .
A.4 Multi-Threading Collision with wxPython

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

B shell script
C Test cases log
C.1 Test case1 log
C.2 Test case2 log
C.3 Test case3 log
C.4 Test case4 log
C.5 Test case5 log
C.6 Test case6 log
C.7 Test case7 log

21
24
24
24
24
25
26

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

26
26
28
30
33
35
37
38

1 Background
1.1 USRP
The Universal Software Radio Peripheral(USRP) products are a family of computerhosted hardware offered by Ettus Research LLC and its parent company, National
Instruments, for making software radios. The USRP product is intended to be a
comparatively inexpensive hardware device facilitating the building of a software
radio. The USRP hardware connects to a host computer through a high-speed USB
or Gigabit Ethernet. This connection enables host-based software to control the
USRP platform and prepare signals for transmission or reception [9].

1.2 GNURadio
GNU Radio with the universal software radio peripheral (USRP) has become one
of the most widely used development toolkits to implement software radios in academic and commercial environments. GNU Radio is a collection of software that
when combined with minimal hardware, allows the construction of radios where
the actual waveforms transmitted and received are defined by software. What this
means is that it turns the digital modulation schemes used in todays high performance wireless devices into software problems.
GNU Radio provides a library of signal processing blocks and the glue to tie
it all together. The programmer builds a radio by creating a graph (as in graph
theory) where the vertices are signal processing blocks and the edges represent the
data flow between them. The signal processing blocks are implemented in C++.
Conceptually, blocks process infinite streams of data flowing from their input ports
to their output ports. Blocks attributes include the number of input and output
ports they have as well as the type of data that flows through each. The most
frequently used types are short, float and complex [6].
Graphical interfaces for GNU Radio applications are built in Python. Interfaces
can be built using any toolkit we can access from Python. GNU Radio provides
blocks that use inter-process communication to transfer chunks of data from the
real-time C++ flow graph to Python-land.

1.3 CSMA/CA
In CSMA/CA, a carrier sensing scheme is used, a node wishing to transmit data
has to first listen to the channel for a predetermined amount of time to determine
whether or not another node is transmitting on the channel within the wireless
range. If the channel is sensed idle, then the node is permitted to begin the
transmission process. If the channel is sensed as busy, the node defers its transmission for a random period of time. Once the transmission process begins, it is
still possible for the actual transmission of application data to not occur.
The use of collision avoidance is used to improve the performance of CSMA
by attempting to divide the wireless channel up somewhat equally among all trans3

mitting nodes within the collision domain. CSMA/CA differs from CSMA/CD
due to the nature of the medium, the radio frequency spectrum. Collisions cannot
be detected while occurring at the sending node, thus it is vital for CSMA/CA or
another access method to be implemented. CSMA/CA is used in 802.11 based
wireless LANs and other wired and wireless communication systems. One of the
problems of wireless data communications is that it is not possible to listen while
sending. Therefore, collision detection is not possible. Another reason is the hidden terminal problem [4].
Start

Assemble
a Frame

Not Using IEEE 802.11


RTS/CTS Exchange

Is the
Channel
Idle?

NO

Wait for Random


Backoff Time

YES

Transmit RTS

CTS Received?

NO
Using IEEE 802.11 RTS/CTS Exchange

YES

Transmit
Application Data

END

Figure 1: Simplified algorithm of CSMA/CA [8]


The 802.11 standard specifies a carrier sense multiple access with collision
avoidance (CSMA/CA) protocol. In this protocol, when a node receives a packet
to be transmitted, it first listens to ensure no other node is transmitting. If the channel is clear, it then transmits the packet. Otherwise, it chooses a random backoff
4

factor which determines the amount of time the node must wait until it is allowed
to transmit its packet. During periods in which the channel is clear, the transmitting
node decrements its backoff counter. (When the channel is busy it does not decrement its backoff counter) When the backoff counter reaches zero, the node transmits the packet. Since the probability that two nodes will choose the same backoff
factor is small, collisions between packets are minimized. Collision detection, as
is employed in Ethernet, cannot be used for the radio frequency transmissions of
IEEE 802.11. The reason for this is that when a node is transmitting it cannot hear
any other node in the system which may be transmitting, since its own signal will
drown out any others arriving at the node [1].

1.4 802.11 MAC Frame


The 802.11 MAC frame, as shown in the following figure, consists of a MAC
header, the frame body, and a frame check sequence (FCS). The numbers in the
following figure represent the number of bytes for each field [2].

Figure 2: 802.11 frame format


The function of each part of 802.11 frame format can be found on Internet
easily, so here we dont talk in detail.

2 System Design and Implementation


2.1 Architecture overview
Considering independence of hardware and configuration flexibility, the GNURadioMACer has been designed to have three layers (shown in Figure 1): PHY layer,
MAC layer and test layer. GNURadio-MACer also offer two services GUI and
logging to support and enhance the functionality of these three layers.

Test Layer

GUI

MAC Layer

Logging

PHY Layer

GNURadio

Figure 3: Interactions between MAC and PHY layers


In order to be independent of hardware, the PHY layer should handle the different properties of hardware and provide the same interfaces to mac layer, next
subsection will give a detail analysis. Above PHY layer, MAC layer runs the CSMA/CA protocol to control media access. And test layer generates packets, and
initializes PHY layer and MAC layer to run the whole system.

2.2 PHY layer - based on USRP


2.2.1

Make MAC layer Independent of Hardware

Normally, a good MAC protocol should be independent of hardware, which makes


MAC layer have good portability among all kinds of platforms. To achieve MAC
layer independence, we must figure out the interactions between MAC and physical
layer, then, remove the independence.
1. Find out dependencies
6

Figure 4: Interactions between MAC and PHY layers [11]


From Figure 1, we can see that there are two kinds of interactions between
MAC and PHY layers: control message, like carrier sensing; packet message, such as down stream packets. We need to find out which part of MAC
is impacted by these two kinds of interactions.
(a) Control interaction
MAC layer need to know the channel status as it need to control the
multi-accesses to avoid collisions. Thus, PHY layer need to keep reporting the carrier sensing statistics(CSS) to MAC layer. As different
hardware have different delays of reporting CSS, and the CSS delay has
a significant impact on the performance of MAC protocol. Therefore,
in order to make MAC protocol independent of hardware, we must figure out how to measure CSS delay dynamically.
(b) Packet interaction
Besides carrier sensing, MAC layer need to send down stream packets
to physical layer and receive up stream packets from physical layer.
After sending one packet to physical layer, the MAC layer need to start
an ACK timer to re-transmit the packet if the timer expire. The amount
of time MAC layer need to wait before timer expired is called ACK delay. ACK delay is roughly same with the round trip delay which consist
of transmission delay, propagation delay, processing delay and queue
delay. Different hardware have different transmission rate, thus, has
different transmission delay. So, the ACK delay depends on hardware.

2. Remove dependencies
As mentioned before, in oder to ensure MAC protocol independent of hardware, we must make sure that the CSS delay and the ACK delay can be
self-adjusted on different hardware. One easy way to do this is let MAC
protocol to measure these two delays when it starts to work.
2.2.2

PHY layer Overview

The PHY layer has two components: transmit component and receive component.
The transmit component has two blocks: the modulator and USRP sink. Thus, it
can receive frame from uplayer, modulate the frame and then transmit the packet
throught USRP sink. The receive component has four blocks: the USRP source,
filter, probe and demodulator; The signal got from USRP source goes through filter,
then the probe block uses the signal strength to decide whether the channel is busy
or not (carrier sensing). The demodulator uses the signal to recovery the packet.

Figure 5: Interactions between MAC and PHY layers


The PHY layer provides two interfaces to MAC layer: the carrier sensing interface and send packet interface, and passes the received packets to MAC layer
throught rx call back function.

2.3 MAC layer - CSMA/CA


2.3.1

MAC layer Overview

The MAC layer of GNURadio-MACer is based on 802.11 CSMA/CA protocol.


As mentioned in section 1.2, before transmitting a frame, a node must wait for the
channel idle constantly for DIFS time; if the channel is busy at first or the DIFS
has been interrupted, the node must wait for DIFS again and then randomly back
off. If the channel is idle at first and idle constantly for DIFS time, the node will
transmit without back off. When a node wants to send ACK, it only need to wait
8

the channel idle uninterruptedly for SIFS time, then it can send the ACK without
back off.
Obviously, the basic CSMA/CA mechanism is not fair. Independent of the
overall time a node has already waited for transmission; each node has the same
chances for transmitting data in the next cycle. To provide fairness, IEEE 802.11
adds a back off timer. Again, each node selects a random waiting time within
the range of the contention window. If a certain station does not get access to
the medium in the first cycle, it stops its back off timer, waits for the channel
to be idle again for DIFS and starts the counter again. As soon as the counter
expires, the node accesses the medium. This means that deferred stations do not
choose a randomized back off time again, but continue to count down. Stations that
have waited longer have the advantage over stations that have just entered, in that
they only have to wait for the remainder of their back off timer from the previous
cycle(s) [12].
2.3.2

MAC State

The state transition of MAC layer is shown in Figure 6.

S_Pkt: self_pakcet want to send


O_Pkt: other_packet received

ACK or NAK

S_Pkt Arrive

Sending

Idle
Time expire or NAK
ACK

send

ACK or NAK

Waiting

O_Pkt
NAK or ACK

S_Pkt Arrive

O_Pkt

replying

Figure 6: The State Transition Diagram of MAC layer


The MAC layer has four states: idle, sending, replying and waiting. Sending
and replying are instantaneous states, which means the MAC layer stays on these

two states only when it is sending a packet or replying ACK, whichs time is very
short. The MAC layer stays on waiting states when it sent a packet but not receive
ACK yet. After the initialization, and the MAC layer stays on idle state, it will also
stay on idle after finishing sending one packet and receiving the ACK.
2.3.3

TX and RX Flow

To implement the CSMA/CA MAC layer, we must figure out the flow of CSMA/CA, including the transmission flow is shown in Figure 7 and receiving flow
is shown in Figure 8.
From the transmitting and receiving flow chart, we can see clearly what action
the MAC layer should perform under different conditions. When transmitting, we
use two loops to make sure the MAC layer wait the channel idle uninterruptedly
for DIFS time. After DIFS, when the MAC layer is backing off, if it is interrupted
after ith slots but before (i + 1)th slots, it will resume the timer at ith slots.
After receiving a packet, the PHY layer will first check the CRC. If the CRC
is all right, the MAC layer will continually check the MAC CRC, the destination
MAC address and the frame type. For a ACK frame, the MAC layer just changes
state to mark that it receives the ACK and finishes one communication successfully,
For receiving a PKT frame, the MAC layer will wait for SIFS and then send the
ACK.

2.4 802.11 MAC frame practice


The GNURadio-MACer uses the 802.11 MAC frame format. We reuse some code
from BBN 802.11 Receiver project [3] to pack data into the 802.11 MAC frame
and unpack 802.11 MAC frame to get data. Before running, all MAC addresses
need to be configured into MAC list. When transmitting, the GNURadio-MACer
will first get the MAC address of its host as source MAC address, randomly select
one MAC address from MAC list as destination; then pack the MAC addresses
and payload into 802.11 MAC frame; finally, invoke the MAC layer CSMA/CA
protocol to transmit the frame.
When receiving, the GNURadio-MACer will unpack the frame first, then perform actions menthoned in section 2.3.3.

2.5 GUI - Event Driven Practice


The GUI of GNURadio-MACer is implemented based on wxPython. wxPython
is a open source and cross-platform GUI toolkit for Python. It allows Python
programmers to create programs with a robust, highly functional graphical user
interface, simply and easily. It is implemented as a Python extension module (native code) that wraps the popular wxWidgets cross platform GUI library, which is
written in C++ [10].

10

Send a packet

Frame preparation

busy
interrupted

Listen to the
channel

free

Wait for DIFS,


Interrupted or not?

Interrupted before

Backoff time =
random slot time

timer expire

Resume timer
Never interrupted
Back off, interrupted
or not

interrupted

Pause back off


timer,
Wait for channel
free

Not interrupted or timer expire

Send packet

Start timer,
wait for ACK

Receive ACK

Finish sending

Figure 7: MAC layer transmitting flow chart

11

Receive a packet

Check PHY
CRC Error

No error

Check des of
frame

My frame

ACK

Get the type of


the packet

packet

Change state

ACK preparation

Wait for SIFS

Send reply

Finish receiving

Figure 8: MAC layer receiving flow chart


The GNURadio-MACer GUI only shows the actions and states of its own without considering other GNURadio-MACer, for example, GNURadio-MACer A sent
a frame to B, and B received it. The GUI of A will only show that A sent a packet

12

to B, without showing that B received a packet. The GUI of GNURadio-MACer is


a frame has two panels, as is shown the GUI figure. The right panel uses nodes to
represent all GNURadio-MACers in the communication system, but only changes
its nodes color based on its action; and the left panel logs all the actions simultaneously.
In order to speed up GUI, we use multi-threading to handle the GUI showing
module and the actual communication part of GNURadio-MACer. And to lower
the coupling of different modules and make sure the wxPython can work well with
multi-threading, we use the event driven techniques to handle the interactions between the GUI showing module and the actual communication part of GNURadioMACer, that is, we define varieties of GUI updating events in the GUI showing
module and define how GUI showing module will handle these events, thus, when
the actual communication part need to update the GUI, it will just post the corresponding events, the GUI module will capture those events and update the GUI
showing.
Our GUI is designed with layout shown in Figure below. The GUI features the
following functions.

Figure 9: GUI layout


1. GUI is called by the main function and displaying the nodes real time status.
Different colors represent different status like carrier sensing, transmitting packets,
receiving packets, transmitting ACK, etc.
2. A separate panel displays description of real time status. This is a multithread task. The time delay of status changing and description cannot be realized
by writing and reading files.
3. Different nodes display their own status.

13

3 The Correctness Testing


In order to verify the correctness of our MAC layer, we develop several test cases
to prove that it works just as what CSMA/CA does. The testbed is composed of 4
USRPs which act as the transceiver. In order to keep timing synchronized perfectly,
we plug 4 USRPs into a single laptop and use system time as all USRPss reference
time. Then we write a shell script in the Appendix to run 4 USRPs at the same
time. We define the CARRIER SENSE INTERVAL as 100us, SLOT TIME as
500us, SIFS as 100us, DIFS as 0.1s, and ACK TIMER as 2s. The communication
frequency is 5GHz and the data rate is 1M bps. Assume A, B ,C, D is assigned
with mac address of 00, 01, 02, 03, respectively. The logs are all listed in Appendix
to verify our MAC-layer works.

3.1 Test Case 1


The first test case is in the Figure 10. Firstly, A gets a packet for B, then C gets a
packet for A during As DIFS, finally, D obtains a packet for B during As transmission to B.

Figure 10: Test Case 1

3.2 Test Case 2


The second test case is similiar to test case 1 except that D gets the packet for B
during As DIFS. Therefore, A still gets the packet first for B, then both C and D
obtain their packets during As DIFS. Figure 11 illustrates our test case.

3.3 Test Case 3


The wireless channel is not always free of noise or interference. Sometimes, the
transmitted packet can not be received by receiver or the ACK can not be receiver
14

Figure 11: Test Case 2

by transmitter. So the retransmission scheme is needed. Our third test case is used
to validate our retransmission scheme works for CSMA/CA shown in Figure 12. A
will first get the packet for B, then C obtains the packet for A during As DIFS. D
gets teh packet for B during Bs SIFS. Both C and Ds transmitted packets are lost
and they both retransmit the packet again after the timer expires. Note that during
retransmission, the contention window will be doubled.

Figure 12: Test Case 3

3.4 Test Case 4


Test case 4 is used to test the senario that if a USRP is waiting its chance to transmit
a packet, it can also switch to receiver mode to receive a packet and send ACK, then
go back to transmitter mode again. In Figure 13, A will transmit to B first, then C
gets the packet for D, and D obtains the packet for C, both during As DIFS.

15

Figure 13: Test Case 4

3.5 Test Case 5


If a node wakes up during the others backoff time, and transmit a packet after
sensing channel idle for DIFS time, it is supposed to interrupt others backing off
timer. So test case 5 is for proving this kind of senario. In figure 14, A will transmit
to B at first, then C wants to transmit to A during As DIFS, D wakes up during Cs
random backoff time and transmit to B. Then Cs backoff is interuppted and needs
to resume the backoff timer after the channel is idle again.

Figure 14: Test Case 5

3.6 Test Case 6


In test case 6, A transmits to B at first, then C wants to transmit to A during As
transmission. D wakes up during Cs backoff time. D wants to transmit to B but is

16

interrupted by Cs transmission during waiting for DIFS. This senario is shown in


figure 15.

Figure 15: Test Case 6

3.7 Test Case 7


In the test cases above, B is always used as receiver. So in our final test case, B
will also transmit packets after receiving. Figure 16 shows that A transmit to B at
first, then C gets the packet for A during Bs SIFS. Then D wants to transmit to B
during Cs DIFS. Finally, B gets a packet for D and transmit it at the end.

Figure 16: Test Case 7

17

4 Efficiency of the GNURadio-MACer


4.1 Pure Theoretical Efficiency of CSMA/CA MAC
Theoretically, three critical factors of MAC efficiency are the PHY frame format,
MAC frame format, and the MAC protocol. As above section described, we have
implemented the CSMA/CA as MAC protocol and 802.11 MAC frame format on
the platform of GNU radio and USRP, and knew very well the overhead due to
the CSMA/CA protocol and MAC frame format. In the implementation of PHY
layer, the Gaussian Minimum Shift Keying (GMSK) is used as the modulation
mechanism due to its advantage of being able to carry digital modulation while still
using spectrum efficiency. Additionally, the whitener method is used to encrypt the
PHY lays payload with CRC. Before we calculate the theoretical MAC efficiency,
it is necessary to detail the PHY frame format which the GNU radio employed. The
PHY frame format consists of preamble, access code, PHY header, payload with
CRC, and the variable pad. The following figure shows the PHY frame format we
derived from the packet utils.py, gmsk.py, pkt.py, and so on. The descriptions and
2
Preamble

0.5

Access code

Whitener
offset

0.5

1.5
Payload
length

Whitener
offset

1.5
Payload
length

1-4092
Payload

0-7

CRC

Pad

Bytes

Payload_with_CRC

Header

Figure 17: PHY Frame Format

settings of each field are as followed:


1. Preamble: It is set to A4F 2.
2. Access Code: The default access code is the 8 Bytes and set to ACDDA4E2
F 28C20F C.
3. Header: The PHY header contains two copies of Whitener offset with upper
nibble and the length of payload with CRC with 12 bits. The Whitener offset
is the key of encryption algorithm and it is a random variable.
4. Payload with CRC: Payload of PHY layer is actual the MAC frame and then
is appended with CRC, which is only for the payload, not whole packet.
5. Pad: This Pad field is needed to make sure each packet ultimately ends up
being a multiple of 512 bytes when sent across the USB, since the buffer size
between USRP and host computer is 512 bytes and only when the buffer is
filled to full and the terminal begin to send the data. We send 4-byte samples
across the USB (16-bit I and 16-bit Q), thus we want to pad so that after
modulation the resulting packet is a multiplier of 128 samples. The GMSK

18

modulator provides 1 bit per symbol and 2 samples per symbol, therefore
after calculation:
lcm(128/8, 2)
1bit per symbol = 8bytes
2samples per symbol

(1)

We get the bytes of modulus is 8, which means the resulting packet has to be
a multiplier of 8 bytes. The range of Pad is from 0 to 7.
First, we perform the calculation of the pure theoretical MAC efficiency when
we only consider overheads from PHY frame, MAC frame and CSMA/CA protocol. The following figure shows the components what are related with MAC
efficiency.
Sender

PHY
Over
DIFS head

MAC
Over
head

Payload

SIFS

PHY
Over
head

MAC
Over
head

ACK

Receiver

Figure 18: Components of Pure Theoretical MAC Efficiency

We derive the generic equation of pure theoretical MAC efficiency as


Epure =

Data
ru
Data+ACK+2Om +2Op
ru

+ DIF S + SIF S

(2)

In the above Equation, Om means the overhead of MAC layer, Op means the
overhead of PHY layer, ru means the datarate of USPR. According to the experiment, the value for each parameter in Equation (1) is shown in the following table.
Table 1: Parameters of pure theoretical MAC efficiency
Parameter
Value
Data
1000 bytes
ACK
5 bytes
MAC overhead
34 bytes
PHY overhead
18+Pad bytes
bitrate
500kbps
DIFS
1ms
SIFS
0.1ms
By using these parameters, we can get the pure theoretical MAC efficiency of
84.12%.
19

4.2 USRP Impact on Theoretical MAC Efficiency


The delay of USRP and Host is very large, thus, the USRP has a very large impact
on theoretical MAC efficiency. To get the real theoretical MAC efficiency, we need
to take two more implementation factors into account: delays due to the limitation of software-based radio which consists of the delay between USRP and host
computer and the carrier sensing delay. Figure 13 shows the components of real
theoretical MAC efficiency.
uplayer
PKT
arrive

Get
ACK

DIFS

Host A
to
USRP A
delay

PKT transmitting

USRP A
to
Host A
Delay
-------Carrier
Sense
Delay

SIFS

Host B
ACK
to
USRP B transmitting
delay

USRP B
to
Host B
Delay
-------Carrier
Sense
Delay

Next round

Get
PKT

Figure 19: Components of Real Theoretical MAC Efficiency


Following the analysis of Figure 13, we get the equation of real theoretical
MAC efficiency is
Eu =

Data
ru
Data+ACK+2Om +2Op
+ du
ru

+ DIF S + SIF S

(3)

The du in Equation 3 indicates the total delay caused by the implementation


of software-based radio. The following table shows the specified delays caused by
different sections shown in Figure 13.
After calculation, we finally get the real theoretical MAC efficiency is about
53.3%.

4.3 Practice Efficiency of different cases


To test whether the practice efficiency of GNURadio-MACer matches its theorical efficiency, we uses two scenarioes to check: two transceivers scenario and
four transceivers scenario. For two transceivers we only compute the practical
efficiency, for four transceivers scenario, besides efficiency, we also compare the
fairness.
20

Table 2: Delays of real theoretical MAC efficiency


Delay name
Delay time
Description
Host A to USRP A
5ms
caused by PKT of 1056 bytes
transmission from Host A to
USRP A
USRP B to Host B + 2ms
delay of USRP B to Host B
Carrier Sense
overlays delay of carrier sense
Host B to USRP B
2ms
caused by ACK of 64 bytes
transmission from Host B to
USRP B
USRP A to Host A + 2ms
delay of USRP A to Host A
Carrier Sense
overlays delay of carrier sense
4.3.1

Two transceivers - Efficiency

For the practical efficiency of GNURadio-MACor, assume the GNURadio-MACer


sends k packets successfully in t seconds, each packet has lp bytes, the actual
bitrate of USRP is ru bps. Thus, the practical efficiency of GNURadio-MACer Ep
is:

Ep =

k lp 8
t ru

(4)

In this scenario, we make two transceivers talk to each other, that is, two
transceivers T R1 and T R2, each one can send packets to the other one, receive
packets from the other one and reply an ACK. If one sends a packet, doesnt get
the ACK and time expired, it will re-transmit the packet until it gets an ACK.
We let each transceiver sends 100 packets one time, and run the experiment 5
times. The time each transceiver used to send 100 packets and receive 100 packets
is shown in Table 3.
We use the average time of these five experiments as t. As each transceiver
transmits 100 packets and recives 100 packets, thus, k should be 200. Using the
Equation 4, we can get that:

Ep =
4.3.2

k lp 8
200 1000 8
=
50.8%
t ru
6.3005 500K

(5)

Four transceivers - Efficiency & Fairness

In this scenario, we make four transceivers talk to each other, that is, four transceivers
T R1, T R2, T R3 and T R4. Each one randomly selects one of other three transceivers
as destination, then send packets to that transceiver. When receiving a packet, the
transceiver will first check if the packets destination is him, if yes, return an ACK,
21

Table 3: Time used by each transceiver in 5 experiments


Item
Transceiver Time (s)
TR1
6.352
Experiment 1
TR2
6.239
Experiment 2

TR1
TR2

6.336
6.224

Experiment 3

TR1
TR2

6.340
6.227

Experiment 4

TR1
TR2

6.353
6.232

Experiment 5

TR1
TR2

6.409
6.293

Average Time

6.3005

otherwise just drop the packet; If one sends a packet, doesnt get the ACK and time
expired, it will re-transmit the packet until it gets an ACK.
We let each transceiver sends 100 packets. The time each transceiver used to
send 100 packets and receive packets from other three transceivers is shown in the
Table 4.
Table 4: Time used by each transceiver in experiment
Transceiver Time (s)
TR1
TR2
TR1
TR2
Average

36.174
36.077
36.078
36.203
36.133

We use the average time of these four transceivers as t. As each transceiver


transmits 100 packets, thus, k should be 400. Using the Equation 4, we can get
that:

Ep =

400 1000 8
k lp 8
=
17.7%
t ru
36.133 500K

(6)

The efficiency decreases sharply as collisions happen, since the ACK expire
time of GNURadio-MACer is very large, this means the retransmission time can
be very long, so, the efficiency decreases a lot compare to the two transceivers
scenario, which the collisions seldom happen.

22

For the fairness of GNURadio-MACer, in Section 3, we have proved that


GNURadio-MACer is right, that is, GNURadio-MACer is running on the CSMA/CA protocol correctly. The backoff accumulation mechanism of CSMA/CA
protocol guarantees the fairness of GNURadio-MACer.

References
[1] 802.11
csma/ca.
http://oscar.iitb.ac.in/
onsiteDocumentsDirectory/csma_ca/csma_ca/index.
html. Accessed in April 2011.
[2] 802.11 frame format. http://technet.microsoft.com/en-us/
library/cc757419%28WS.10%29.aspx. Accessed in April 2011.
[3] Bbn 802.11 receiver. https://www.cgran.org/wiki/BBN80211.
Accessed in April 2010.
[4] Csma/ca introduction.
http://en.wikipedia.org/wiki/
Carrier_sense_multiple_access_with_collision_
avoidance. Accessed in April 2011.
[5] First packet missing. http://gnuradio.blogspot.com/2011/04/
re-discuss-gnuradio-run-two-usrp.html. Accessed in April
2010.
[6] Gnu radio introduction.
http://www.hsc.com/Portals/0/
/Uploads/Articles/HSC-GnuRadio633851530807166689.
pdf. Accessed in April 2011.
[7] How to write a gnu radio signal processing block. http://www.gnu.
org/software/gnuradio/doc/howto-write-a-block.html.
Accessed in April 2010.
[8] Simplified csma/ca algorithm. http://en.wikipedia.org/wiki/
File:Csma_ca.svg. Accessed in April 2011.
[9] Usrp
introduction.
http://en.wikipedia.org/wiki/
Universal_Software_Radio_Peripheral. Accessed in April
2011.
[10] wxpython. http://wxpython.org/what.php. Accessed in April
2010.
[11] wxpython demo.
http://downloads.sourceforge.net/
wxpython/wxPython-demo-2.8.11.0.tar.bz2.
Accessed
in April 2010.

23

[12] Jochen Schiller. Mobile communications, 2000.

Appendices
A

Troubleshooting

A.1 Debugging GNURadio


If you want to debug the python code of GNURadio, you can use pdb, which is
similar to gdb. Pdb supports setting (conditional) breakpoints and single stepping
at the source line level. The GNURadio uses SWIG to wrap C++ class into python
class. Pdb cannot step into the C++ class directly, it only can step into the corresponding swig python file of corresponding C++ class. Thus, if you want to
debug the C++ class of GNURadio, you should build your own C++ block under
the guidance of [7].

A.2 PHY CRC Error


The receive component of GNURadio MAC uses the demodulator provided by
GNURadio. THe demodulator will pass the physical layer CRC check result and
the packet to uplayer. We have encountered many physical layer CRC error problem, after we tested many cases and checked many USRPs, to the best of our
knowledge, there are three main reasons that can lead to physical layer CRC error.
1. The daughter board or the mother board of the USRP is broken
You can use the benchmark program provided GNURadio install packet to
check if the daughter board or the mother board of the USRP is good or not.
2. USRPs are too close
If two USRPs are too close, they may not at the beamform range of each
other. THe CRC error may happen.
3. USRPs temperature is too high
When USRP is too hot, it cannt work normal, the CRC error may happen.

A.3 First Packet Missing


It is normal that the USRP may miss the first packet. The test which uses the
benchmark program provided by GNURadio shows that 60% chance that the first
two packets will miss, 20% of missing first packet, 20% of no missing.
Somebody on the GNURadio mailling list gives a answer about why USRP has
a so high first packet missing ratio, which seems to be correct. He said There is
a lock-in time associated with all of the synchronization loops, which will change
24

depending on the noise in the system. So it might not synchronize until after the
first packet or so. So yes, its random because youre dealing with stochastic processes :) Im a bit surprised that you are sometimes missing the first 2 packets.
Could be due to bad multipath (the benchmark scripts dont use an equalizer) or
any of the other random things that happen [5].

A.4 Multi-Threading Collision with wxPython


If you are using a thread to run the GUI program, but use the reference to update
GUI directly in main thread, like the following,
1 global gui
2 def run_gui():
3
global gui
4
app = wx.App(False)
5
gui = mac_gui()
6
7
#gui.showMsg(hello) is gui.textcrtl.AppendText(hello)
8
gui.showMsg(hello)
9
app.MainLoop()
10
11 def main():
12
global gui
13
t = threading.Thread(None, run_gui)
14
t.start()
15
time.sleep(1)
16
17
msg = %f channel idle % (time.time()%1000)
18
for i in range (1, 100):
19
time.sleep(0.1)
20
gui.showMsg(msg+\n)

We can get error message like The program python received an X Window
System error. or sometimes the GUI just die. After googling the problem, we find
that this is a bug in wxpython when it is working with multi-threading. The error
happens when the X window System invoke the GUI program to display, but at the
same time, the main thread invoke the GUI program to append some text.
When we check the wxPython demo, we find that The main issue with multithreaded GUI programming is the thread safty of the GUI itself. On most platforms
the GUI is not thread safe and so any cross platform GUI Toolkit and applications
written with it need to take that into account. The solution is to only allow interaction with the GUI from a single thread, but this often severely limits what can
be done in an application and makes it difficult to use additional threads at all.
Since wxPython already makes extensive use of event handlers, it is a logical extension to allow events to be sent to GUI objects from alternate threads. A function
called wx.PostEvent allows you to do this. It accepts an event and an event handler
(window) and instead of sending the event immediately in the current context like
ProcessEvent does, it processes it later from the context of the GUI thread [11].

25

Thus, according to the hint above, we use the event driven GUI updating
method, that is, define varieties of GUI updating events in the GUI showing module and define how GUI showing module will handle these events, thus, when the
actual communication part need to update the GUI, it will just post the corresponding events, the GUI module will capture those events and update the GUI showing.
The problem is solved successfully.

B shell script
We write a simple script called run.sh to make sure the system could schedule all
the processes almost the same time to keep timing synchronized.
sudo python qa main.py f 5e9 w 0 &
sudo python qa main 1.py f 5e9 w 1 &
sudo python qa main 2.py -f 5e9 w 2 &
sudo python qa main 3.py f 5e9 w 3 &

Test cases log

We just attach all the logs for the test cases so that you can verify it works.

C.1 Test case1 log


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

12:37:35 589 00:00:00:00:00:01 ->


12:37:35 595 00:00:00:00:00:02 ->
12:37:35 607 00:00:00:00:00:00 ->
12:37:35 609 00:00:00:00:00:03 ->
12:37:38 607 00:00:00:00:00:00 ->
window size is 7
12:37:38 607 00:00:00:00:00:00 ->
only
12:37:38 645 00:00:00:00:00:02 ->
window size is 7
12:37:38 645 00:00:00:00:00:02 ->
only
12:37:38 707 00:00:00:00:00:00 ->
12:37:38 708 00:00:00:00:00:00 ->
12:37:38 708 00:00:00:00:00:00 ->
no ACK yet
12:37:38 713 00:00:00:00:00:02 ->
elapsed 0.067818
12:37:38 713 00:00:00:00:00:02 ->
12:37:38 720 00:00:00:00:00:03 ->
window size is 7
12:37:38 720 00:00:00:00:00:03 ->
12:37:38 744 00:00:00:00:00:03 ->
and 6.000000 remaining slots
12:37:38 744 00:00:00:00:00:02 ->
and 5.000000 remaining slots

is ready to
is ready to
is ready to
is ready to
uplayer PKT

receive and send


receive and send
receive and send
receive and send
arrived, contention

channel idle now, wait for DIFS


uplayer PKT arrived, contention
channel idle now, wait for DIFS
channel idled for DIFS
csmaca mac, finish sending
sent PKT 1 to 00:00:00:00:00:01,
interrupted in DIFS, time
channel busy
uplayer PKT arrived, contention
channel busy
channel idle now, wait for DIFS
channel idle now, wait for DIFS

26

18 12:37:38 745 00:00:00:00:00:02 -> MAC frame not for me, drop!
19 12:37:38 746 00:00:00:00:00:03 -> MAC frame not for me, drop!
20 12:37:38 746 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:00, CRC right
21 12:37:38 747 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
22 12:37:38 749 00:00:00:00:00:01 -> channel idled for SIFS
23 12:37:38 749 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:00
24 12:37:38 749 00:00:00:00:00:01 -> csmaca mac, finish sending
25 12:37:38 752 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.007667
26 12:37:38 752 00:00:00:00:00:03 -> channel busy
27 12:37:38 752 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
28 12:37:38 752 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.007557
29 12:37:38 752 00:00:00:00:00:02 -> channel busy
30 12:37:38 755 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 6.000000 remaining slots
31 12:37:38 756 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 5.000000 remaining slots
32 12:37:38 757 00:00:00:00:00:02 -> MAC frame not for me, drop!
33 12:37:38 757 00:00:00:00:00:03 -> MAC frame not for me, drop!
34 12:37:38 757 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
35 12:37:38 882 00:00:00:00:00:02 -> channel idled for DIFS and
5.000000 slots time
36 12:37:38 882 00:00:00:00:00:02 -> csmaca mac, finish sending
37 12:37:38 882 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
38 12:37:38 885 00:00:00:00:00:03 -> interrupted at slot time
5.861168
39 12:37:38 885 00:00:00:00:00:03 -> channel busy
40 12:37:38 893 00:00:00:00:00:00 -> receives PKT 1 from
00:00:00:00:00:02, CRC right
41 12:37:38 894 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
42 12:37:38 895 00:00:00:00:00:03 -> MAC frame not for me, drop!
43 12:37:38 895 00:00:00:00:00:01 -> MAC frame not for me, drop!
44 12:37:38 894 00:00:00:00:00:00 -> channel idle now, wait for SIFS
only
45 12:37:38 897 00:00:00:00:00:00 -> channel idled for SIFS
46 12:37:38 897 00:00:00:00:00:00 -> sending PKT 1s ACK to
00:00:00:00:00:02
47 12:37:38 899 00:00:00:00:00:00 -> csmaca mac, finish sending
48 12:37:38 899 00:00:00:00:00:00 -> finish sending PKT 1s ACK to
00:00:00:00:00:02
49 12:37:38 899 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.005637
50 12:37:38 900 00:00:00:00:00:03 -> channel busy
51 12:37:38 905 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
52 12:37:38 905 00:00:00:00:00:01 -> MAC frame not for me, drop!

27

53 12:37:38 905 00:00:00:00:00:02 -> gets PKT 1s ACK from


00:00:00:00:00:00. One COMM Suc
54 12:37:38 905 00:00:00:00:00:03 -> MAC frame not for me, drop!
55 12:37:39 10 00:00:00:00:00:03 -> channel idled for DIFS and
1.000000 slots time
56 12:37:39 11 00:00:00:00:00:03 -> csmaca mac, finish sending
57 12:37:39 11 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
58 12:37:39 22 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
59 12:37:39 22 00:00:00:00:00:01 -> channel busy
60 12:37:39 23 00:00:00:00:00:01 -> channel idle now, wait for SIFS
and 0.000000 remaining slots
61 12:37:39 22 00:00:00:00:00:02 -> MAC frame not for me, drop!
62 12:37:39 22 00:00:00:00:00:00 -> MAC frame not for me, drop!
63 12:37:39 24 00:00:00:00:00:01 -> channel idled for SIFS and
0.000000 slots time
64 12:37:39 24 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:03
65 12:37:39 28 00:00:00:00:00:01 -> csmaca mac, finish sending
66 12:37:39 28 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
67 12:37:39 33 00:00:00:00:00:00 -> MAC frame not for me, drop!
68 12:37:39 33 00:00:00:00:00:02 -> MAC frame not for me, drop!
69 12:37:39 33 00:00:00:00:00:03 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc

C.2 Test case2 log


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

12:37:35 595 00:00:00:00:00:02 ->


12:37:35 607 00:00:00:00:00:00 ->
12:37:35 609 00:00:00:00:00:03 ->
12:37:38 607 00:00:00:00:00:00 ->
window size is 7
12:37:38 607 00:00:00:00:00:00 ->
only
12:37:38 645 00:00:00:00:00:02 ->
window size is 7
12:37:38 645 00:00:00:00:00:02 ->
only
12:37:38 707 00:00:00:00:00:00 ->
12:37:38 708 00:00:00:00:00:00 ->
12:37:38 708 00:00:00:00:00:00 ->
no ACK yet
12:37:38 713 00:00:00:00:00:02 ->
elapsed 0.067818
12:37:38 713 00:00:00:00:00:02 ->
12:37:38 720 00:00:00:00:00:03 ->
window size is 7
12:37:38 720 00:00:00:00:00:03 ->
12:37:38 744 00:00:00:00:00:03 ->
and 6.000000 remaining slots

is ready to
is ready to
is ready to
uplayer PKT

receive and send


receive and send
receive and send
arrived, contention

channel idle now, wait for DIFS


uplayer PKT arrived, contention
channel idle now, wait for DIFS
channel idled for DIFS
csmaca mac, finish sending
sent PKT 1 to 00:00:00:00:00:01,
interrupted in DIFS, time
channel busy
uplayer PKT arrived, contention
channel busy
channel idle now, wait for DIFS

28

16 12:37:38 744 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 5.000000 remaining slots
17 12:37:38 745 00:00:00:00:00:02 -> MAC frame not for me, drop!
18 12:37:38 746 00:00:00:00:00:03 -> MAC frame not for me, drop!
19 12:37:38 746 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:00, CRC right
20 12:37:38 747 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
21 12:37:38 749 00:00:00:00:00:01 -> channel idled for SIFS
22 12:37:38 749 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:00
23 12:37:38 749 00:00:00:00:00:01 -> csmaca mac, finish sending
24 12:37:38 752 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.007667
25 12:37:38 752 00:00:00:00:00:03 -> channel busy
26 12:37:38 752 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
27 12:37:38 752 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.007557
28 12:37:38 752 00:00:00:00:00:02 -> channel busy
29 12:37:38 755 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 6.000000 remaining slots
30 12:37:38 756 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 5.000000 remaining slots
31 12:37:38 757 00:00:00:00:00:02 -> MAC frame not for me, drop!
32 12:37:38 757 00:00:00:00:00:03 -> MAC frame not for me, drop!
33 12:37:38 757 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
34 12:37:38 882 00:00:00:00:00:02 -> channel idled for DIFS and
5.000000 slots time
35 12:37:38 882 00:00:00:00:00:02 -> csmaca mac, finish sending
36 12:37:38 882 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
37 12:37:38 885 00:00:00:00:00:03 -> interrupted at slot time
5.861168
38 12:37:38 885 00:00:00:00:00:03 -> channel busy
39 12:37:38 893 00:00:00:00:00:00 -> receives PKT 1 from
00:00:00:00:00:02, CRC right
40 12:37:38 894 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
41 12:37:38 895 00:00:00:00:00:03 -> MAC frame not for me, drop!
42 12:37:38 895 00:00:00:00:00:01 -> MAC frame not for me, drop!
43 12:37:38 894 00:00:00:00:00:00 -> channel idle now, wait for SIFS
only
44 12:37:38 897 00:00:00:00:00:00 -> channel idled for SIFS
45 12:37:38 897 00:00:00:00:00:00 -> sending PKT 1s ACK to
00:00:00:00:00:02
46 12:37:38 899 00:00:00:00:00:00 -> csmaca mac, finish sending
47 12:37:38 899 00:00:00:00:00:00 -> finish sending PKT 1s ACK to
00:00:00:00:00:02
48 12:37:38 899 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.005637
49 12:37:38 900 00:00:00:00:00:03 -> channel busy

29

50 12:37:38 905 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
51 12:37:38 905 00:00:00:00:00:01 -> MAC frame not for me, drop!
52 12:37:38 905 00:00:00:00:00:02 -> gets PKT 1s ACK from
00:00:00:00:00:00. One COMM Suc
53 12:37:38 905 00:00:00:00:00:03 -> MAC frame not for me, drop!
54 12:37:39 10 00:00:00:00:00:03 -> channel idled for DIFS and
1.000000 slots time
55 12:37:39 11 00:00:00:00:00:03 -> csmaca mac, finish sending
56 12:37:39 11 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
57 12:37:39 22 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
58 12:37:39 22 00:00:00:00:00:01 -> channel busy
59 12:37:39 23 00:00:00:00:00:01 -> channel idle now, wait for SIFS
and 0.000000 remaining slots
60 12:37:39 22 00:00:00:00:00:02 -> MAC frame not for me, drop!
61 12:37:39 22 00:00:00:00:00:00 -> MAC frame not for me, drop!
62 12:37:39 24 00:00:00:00:00:01 -> channel idled for SIFS and
0.000000 slots time
63 12:37:39 24 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:03
64 12:37:39 28 00:00:00:00:00:01 -> csmaca mac, finish sending
65 12:37:39 28 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
66 12:37:39 33 00:00:00:00:00:00 -> MAC frame not for me, drop!
67 12:37:39 33 00:00:00:00:00:02 -> MAC frame not for me, drop!
68 12:37:39 33 00:00:00:00:00:03 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc

C.3 Test case3 log


1
2
3
4
5
6
7
8
9
10
11
12
13

12:09:40 114 00:00:00:00:00:02


12:09:40 116 00:00:00:00:00:01
12:09:40 120 00:00:00:00:00:00
12:09:40 124 00:00:00:00:00:03
12:09:43 120 00:00:00:00:00:00
window size is 7
12:09:43 120 00:00:00:00:00:00
only
12:09:43 164 00:00:00:00:00:02
window size is 7
12:09:43 164 00:00:00:00:00:02
only
12:09:43 220 00:00:00:00:00:00
12:09:43 221 00:00:00:00:00:00
12:09:43 221 00:00:00:00:00:00
no ACK yet
12:09:43 224 00:00:00:00:00:02
elapsed 0.059315
12:09:43 224 00:00:00:00:00:02

->
->
->
->
->

is ready to
is ready to
is ready to
is ready to
uplayer PKT

receive and send


receive and send
receive and send
receive and send
arrived, contention

-> channel idle now, wait for DIFS


-> uplayer PKT arrived, contention
-> channel idle now, wait for DIFS
-> channel idled for DIFS
-> csmaca mac, finish sending
-> sent PKT 1 to 00:00:00:00:00:01,
-> interrupted in DIFS, time
-> channel busy

30

14 12:09:43 231 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 0.000000 remaining slots
15 12:09:43 232 00:00:00:00:00:02 -> MAC frame not for me, drop!
16 12:09:43 233 00:00:00:00:00:03 -> MAC frame not for me, drop!
17 12:09:43 233 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:00, CRC right
18 12:09:43 235 00:00:00:00:00:03 -> uplayer PKT arrived, contention
window size is 7
19 12:09:43 235 00:00:00:00:00:03 -> channel idle now, wait for DIFS
only
20 12:09:43 234 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
21 12:09:43 237 00:00:00:00:00:01 -> channel idled for SIFS
22 12:09:43 238 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:00
23 12:09:43 241 00:00:00:00:00:01 -> csmaca mac, finish sending
24 12:09:43 242 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.007183
25 12:09:43 242 00:00:00:00:00:03 -> channel busy
26 12:09:43 243 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.011427
27 12:09:43 243 00:00:00:00:00:02 -> channel busy
28 12:09:43 241 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
29 12:09:43 246 00:00:00:00:00:03 -> MAC frame not for me, drop!
30 12:09:43 246 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
31 12:09:43 246 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 0.000000 remaining slots
32 12:09:43 247 00:00:00:00:00:02 -> MAC frame not for me, drop!
33 12:09:43 248 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 2.000000 remaining slots
34 12:09:43 347 00:00:00:00:00:02 -> channel idled for DIFS and
0.000000 slots time
35 12:09:43 347 00:00:00:00:00:02 -> csmaca mac, finish sending
36 12:09:43 347 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
37 12:09:43 351 00:00:00:00:00:03 -> interrupted at slot time
0.676994
38 12:09:43 351 00:00:00:00:00:03 -> channel busy
39 12:09:43 359 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 2.000000 remaining slots
40 12:09:43 469 00:00:00:00:00:03 -> channel idled for DIFS and
2.000000 slots time
41 12:09:43 469 00:00:00:00:00:03 -> csmaca mac, finish sending
42 12:09:43 469 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
43 12:09:45 347 00:00:00:00:00:02 -> timer expire, re-transmits PKT 1
44 12:09:45 347 00:00:00:00:00:02 -> uplayer PKT arrived, contention
window size is 14
45 12:09:45 348 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 9.000000 remaining slots
46 12:09:45 469 00:00:00:00:00:03 -> timer expire, re-transmits PKT 1

31

47 12:09:45 470 00:00:00:00:00:03 -> uplayer PKT arrived, contention


window size is 14
48 12:09:45 470 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 5.000000 remaining slots
49 12:09:45 493 00:00:00:00:00:02 -> channel idled for DIFS and
9.000000 slots time
50 12:09:45 493 00:00:00:00:00:02 -> csmaca mac, finish sending
51 12:09:45 493 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
52 12:09:45 496 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.026391
53 12:09:45 496 00:00:00:00:00:03 -> channel busy
54 12:09:45 503 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 5.000000 remaining slots
55 12:09:45 504 00:00:00:00:00:03 -> MAC frame not for me, drop!
56 12:09:45 504 00:00:00:00:00:00 -> receives PKT 1 from
00:00:00:00:00:02, CRC right
57 12:09:45 505 00:00:00:00:00:01 -> MAC frame not for me, drop!
58 12:09:45 505 00:00:00:00:00:00 -> channel idle now, wait for SIFS
only
59 12:09:45 508 00:00:00:00:00:00 -> channel idled for SIFS
60 12:09:45 509 00:00:00:00:00:00 -> sending PKT 1s ACK to
00:00:00:00:00:02
61 12:09:45 511 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.007536
62 12:09:45 511 00:00:00:00:00:03 -> channel busy
63 12:09:45 512 00:00:00:00:00:00 -> csmaca mac, finish sending
64 12:09:45 512 00:00:00:00:00:00 -> finish sending PKT 1s ACK to
00:00:00:00:00:02
65 12:09:45 515 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 5.000000 remaining slots
66 12:09:45 517 00:00:00:00:00:01 -> MAC frame not for me, drop!
67 12:09:45 517 00:00:00:00:00:03 -> MAC frame not for me, drop!
68 12:09:45 517 00:00:00:00:00:02 -> gets PKT 1s ACK from
00:00:00:00:00:00. One COMM Suc
69 12:09:45 640 00:00:00:00:00:03 -> channel idled for DIFS and
5.000000 slots time
70 12:09:45 641 00:00:00:00:00:03 -> csmaca mac, finish sending
71 12:09:45 641 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
72 12:09:45 652 00:00:00:00:00:00 -> MAC frame not for me, drop!
73 12:09:45 653 00:00:00:00:00:02 -> MAC frame not for me, drop!
74 12:09:45 653 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
75 12:09:45 655 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
76 12:09:45 657 00:00:00:00:00:01 -> channel idled for SIFS
77 12:09:45 657 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:03
78 12:09:45 657 00:00:00:00:00:01 -> csmaca mac, finish sending
79 12:09:45 658 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
80 12:09:45 664 00:00:00:00:00:02 -> MAC frame not for me, drop!

32

81 12:09:45 665 00:00:00:00:00:03 -> gets PKT 1s ACK from


00:00:00:00:00:01. One COMM Suc
82 12:09:45 665 00:00:00:00:00:00 -> MAC frame not for me, drop!

C.4 Test case4 log


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

14:46:04 317 00:00:00:00:00:03 ->


14:46:04 318 00:00:00:00:00:00 ->
14:46:04 339 00:00:00:00:00:01 ->
14:46:04 345 00:00:00:00:00:02 ->
14:46:07 319 00:00:00:00:00:00 ->
window size is 7
14:46:07 319 00:00:00:00:00:00 ->
only
14:46:07 396 00:00:00:00:00:02 ->
window size is 7
14:46:07 397 00:00:00:00:00:02 ->
only
14:46:07 418 00:00:00:00:00:03 ->
window size is 7
14:46:07 418 00:00:00:00:00:03 ->
only
14:46:07 419 00:00:00:00:00:00 ->
14:46:07 419 00:00:00:00:00:00 ->
14:46:07 419 00:00:00:00:00:00 ->
no ACK yet
14:46:07 422 00:00:00:00:00:02 ->
elapsed 0.025460
14:46:07 422 00:00:00:00:00:02 ->
14:46:07 422 00:00:00:00:00:03 ->
elapsed 0.004442
14:46:07 423 00:00:00:00:00:03 ->
14:46:07 431 00:00:00:00:00:02 ->
and 0.000000 remaining slots
14:46:07 431 00:00:00:00:00:03 ->
and 1.000000 remaining slots
14:46:07 432 00:00:00:00:00:02 ->
14:46:07 432 00:00:00:00:00:03 ->
14:46:07 432 00:00:00:00:00:01 ->
00:00:00:00:00:00, CRC right
14:46:07 434 00:00:00:00:00:01 ->
only
14:46:07 437 00:00:00:00:00:01 ->
14:46:07 438 00:00:00:00:00:01 ->
00:00:00:00:00:00
14:46:07 440 00:00:00:00:00:01 ->
14:46:07 440 00:00:00:00:00:01 ->
00:00:00:00:00:00
14:46:07 440 00:00:00:00:00:02 ->
elapsed 0.009595
14:46:07 441 00:00:00:00:00:02 ->

is ready to
is ready to
is ready to
is ready to
uplayer PKT

receive and send


receive and send
receive and send
receive and send
arrived, contention

channel idle now, wait for DIFS


uplayer PKT arrived, contention
channel idle now, wait for DIFS
uplayer PKT arrived, contention
channel idle now, wait for DIFS
channel idled for DIFS
csmaca mac, finish sending
sent PKT 1 to 00:00:00:00:00:01,
interrupted in DIFS, time
channel busy
interrupted in DIFS, time
channel busy
channel idle now, wait for DIFS
channel idle now, wait for DIFS
MAC frame not for me, drop!
MAC frame not for me, drop!
receives PKT 1 from
channel idle now, wait for SIFS
channel idled for SIFS
sending PKT 1s ACK to
csmaca mac, finish sending
finish sending PKT 1s ACK to
interrupted in DIFS, time
channel busy

33

30 14:46:07 441 00:00:00:00:00:03 -> interrupted in DIFS, time


elapsed 0.009638
31 14:46:07 441 00:00:00:00:00:03 -> channel busy
32 14:46:07 445 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 0.000000 remaining slots
33 14:46:07 445 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
34 14:46:07 445 00:00:00:00:00:03 -> MAC frame not for me, drop!
35 14:46:07 445 00:00:00:00:00:02 -> MAC frame not for me, drop!
36 14:46:07 446 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
37 14:46:07 545 00:00:00:00:00:02 -> channel idled for DIFS and
0.000000 slots time
38 14:46:07 545 00:00:00:00:00:02 -> csmaca mac, finish sending
39 14:46:07 545 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:03,
no ACK yet
40 14:46:07 549 00:00:00:00:00:03 -> interrupted at slot time
0.752382
41 14:46:07 549 00:00:00:00:00:03 -> channel busy
42 14:46:07 556 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
43 14:46:07 557 00:00:00:00:00:00 -> MAC frame not for me, drop!
44 14:46:07 558 00:00:00:00:00:03 -> receives PKT 1 from
00:00:00:00:00:02, CRC right
45 14:46:07 558 00:00:00:00:00:01 -> MAC frame not for me, drop!
46 14:46:07 558 00:00:00:00:00:03 -> channel idle now, wait for SIFS
only
47 14:46:07 560 00:00:00:00:00:03 -> channel idled for SIFS
48 14:46:07 560 00:00:00:00:00:03 -> sending PKT 1s ACK to
00:00:00:00:00:02
49 14:46:07 563 00:00:00:00:00:03 -> csmaca mac, finish sending
50 14:46:07 563 00:00:00:00:00:03 -> finish sending PKT 1s ACK to
00:00:00:00:00:02
51 14:46:07 563 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.006546
52 14:46:07 563 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
53 14:46:07 568 00:00:00:00:00:02 -> gets PKT 1s ACK from
00:00:00:00:00:03. One COMM Suc
54 14:46:07 568 00:00:00:00:00:01 -> MAC frame not for me, drop!
55 14:46:07 568 00:00:00:00:00:00 -> MAC frame not for me, drop!
56 14:46:07 668 00:00:00:00:00:03 -> channel idled for DIFS and
1.000000 slots time
57 14:46:07 669 00:00:00:00:00:03 -> csmaca mac, finish sending
58 14:46:07 669 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:02,
no ACK yet
59 14:46:07 680 00:00:00:00:00:00 -> MAC frame not for me, drop!
60 14:46:07 681 00:00:00:00:00:01 -> MAC frame not for me, drop!
61 14:46:07 681 00:00:00:00:00:02 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
62 14:46:07 681 00:00:00:00:00:02 -> channel idle now, wait for SIFS
only
63 14:46:07 683 00:00:00:00:00:02 -> channel idled for SIFS

34

64 14:46:07 683 00:00:00:00:00:02 -> sending PKT 1s ACK to


00:00:00:00:00:03
65 14:46:07 684 00:00:00:00:00:02 -> csmaca mac, finish sending
66 14:46:07 684 00:00:00:00:00:02 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
67 14:46:07 691 00:00:00:00:00:00 -> MAC frame not for me, drop!
68 14:46:07 691 00:00:00:00:00:03 -> gets PKT 1s ACK from
00:00:00:00:00:02. One COMM Suc
69 14:46:07 691 00:00:00:00:00:01 -> MAC frame not for me, drop!

C.5 Test case5 log


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

14:01:51 809 00:00:00:00:00:01 -> is ready to receive and send


gri_fftw: cant import wisdom from /home/symbol/.gr_fftw_wisdom
14:01:51 810 00:00:00:00:00:02 -> is ready to receive and send
14:01:51 814 00:00:00:00:00:03 -> is ready to receive and send
14:01:51 824 00:00:00:00:00:00 -> is ready to receive and send
14:01:54 824 00:00:00:00:00:00 -> uplayer PKT arrived, contention
window size is 7
14:01:54 825 00:00:00:00:00:00 -> channel idle now, wait for DIFS
only
14:01:54 860 00:00:00:00:00:02 -> uplayer PKT arrived, contention
window size is 7
14:01:54 861 00:00:00:00:00:02 -> channel idle now, wait for DIFS
only
14:01:54 925 00:00:00:00:00:00 -> channel idled for DIFS
14:01:54 925 00:00:00:00:00:00 -> csmaca mac, finish sending
14:01:54 925 00:00:00:00:00:00 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
14:01:54 929 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.068530
14:01:54 929 00:00:00:00:00:02 -> channel busy
14:01:54 937 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 7.000000 remaining slots
14:01:54 937 00:00:00:00:00:03 -> MAC frame not for me, drop!
14:01:54 937 00:00:00:00:00:02 -> MAC frame not for me, drop!
14:01:54 938 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:00, CRC right
14:01:54 939 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
14:01:54 940 00:00:00:00:00:01 -> channel idled for SIFS
14:01:54 940 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:00
14:01:54 944 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.007596
14:01:54 945 00:00:00:00:00:02 -> channel busy
14:01:54 943 00:00:00:00:00:01 -> csmaca mac, finish sending
14:01:54 945 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
14:01:54 948 00:00:00:00:00:03 -> MAC frame not for me, drop!
14:01:54 949 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 7.000000 remaining slots

35

28 14:01:54 950 00:00:00:00:00:00 -> gets PKT 1s ACK from


00:00:00:00:00:01. One COMM Suc
29 14:01:54 950 00:00:00:00:00:02 -> MAC frame not for me, drop!
30 14:01:55 14 00:00:00:00:00:03 -> uplayer PKT arrived, contention
window size is 7
31 14:01:55 14 00:00:00:00:00:03 -> channel idle now, wait for DIFS
only
32 14:01:55 114 00:00:00:00:00:03 -> channel idled for DIFS
33 14:01:55 115 00:00:00:00:00:03 -> csmaca mac, finish sending
34 14:01:55 115 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
35 14:01:55 118 00:00:00:00:00:02 -> interrupted at slot time
6.937995
36 14:01:55 118 00:00:00:00:00:02 -> channel busy
37 14:01:55 127 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
38 14:01:55 127 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
39 14:01:55 128 00:00:00:00:00:02 -> MAC frame not for me, drop!
40 14:01:55 128 00:00:00:00:00:00 -> MAC frame not for me, drop!
41 14:01:55 128 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
42 14:01:55 131 00:00:00:00:00:01 -> channel idled for SIFS
43 14:01:55 131 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:03
44 14:01:55 133 00:00:00:00:00:01 -> csmaca mac, finish sending
45 14:01:55 134 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
46 14:01:55 135 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.007507
47 14:01:55 135 00:00:00:00:00:02 -> channel busy
48 14:01:55 138 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 1.000000 remaining slots
49 14:01:55 139 00:00:00:00:00:00 -> MAC frame not for me, drop!
50 14:01:55 139 00:00:00:00:00:02 -> MAC frame not for me, drop!
51 14:01:55 140 00:00:00:00:00:03 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
52 14:01:55 249 00:00:00:00:00:02 -> channel idled for DIFS and
1.000000 slots time
53 14:01:55 249 00:00:00:00:00:02 -> csmaca mac, finish sending
54 14:01:55 249 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
55 14:01:55 260 00:00:00:00:00:01 -> MAC frame not for me, drop!
56 14:01:55 262 00:00:00:00:00:00 -> receives PKT 1 from
00:00:00:00:00:02, CRC right
57 14:01:55 263 00:00:00:00:00:00 -> channel idle now, wait for SIFS
only
58 14:01:55 261 00:00:00:00:00:03 -> MAC frame not for me, drop!
59 14:01:55 264 00:00:00:00:00:00 -> channel idled for SIFS
60 14:01:55 264 00:00:00:00:00:00 -> sending PKT 1s ACK to
00:00:00:00:00:02
61 14:01:55 268 00:00:00:00:00:00 -> csmaca mac, finish sending
62 14:01:55 268 00:00:00:00:00:00 -> finish sending PKT 1s ACK to
00:00:00:00:00:02

36

63 14:01:55 273 00:00:00:00:00:01 -> MAC frame not for me, drop!
64 14:01:55 272 00:00:00:00:00:02 -> gets PKT 1s ACK from
00:00:00:00:00:00. One COMM Suc
65 14:01:55 274 00:00:00:00:00:03 -> MAC frame not for me, drop!

C.6 Test case6 log


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

14:59:48 902 00:00:00:00:00:01 -> is ready to receive and send


14:59:48 909 00:00:00:00:00:03 -> is ready to receive and send
14:59:48 911 00:00:00:00:00:02 -> is ready to receive and send
14:59:48 922 00:00:00:00:00:00 -> is ready to receive and send
14:59:51 922 00:00:00:00:00:00 -> uplayer PKT arrived, contention
window size is 7
14:59:51 922 00:00:00:00:00:00 -> channel idle now, wait for DIFS
only
14:59:52 22 00:00:00:00:00:00 -> channel idled for DIFS
14:59:52 23 00:00:00:00:00:00 -> csmaca mac, finish sending
14:59:52 23 00:00:00:00:00:00 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
14:59:52 32 00:00:00:00:00:02 -> uplayer PKT arrived, contention
window size is 7
14:59:52 32 00:00:00:00:00:02 -> channel busy
14:59:52 35 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 3.000000 remaining slots
14:59:52 35 00:00:00:00:00:03 -> MAC frame not for me, drop!
14:59:52 36 00:00:00:00:00:02 -> MAC frame not for me, drop!
14:59:52 38 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:00, CRC right
14:59:52 38 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
14:59:52 40 00:00:00:00:00:01 -> channel idled for SIFS
14:59:52 40 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:00
14:59:52 44 00:00:00:00:00:01 -> csmaca mac, finish sending
14:59:52 44 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
14:59:52 44 00:00:00:00:00:02 -> interrupted in DIFS, time elapsed
0.009777
14:59:52 45 00:00:00:00:00:02 -> channel busy
14:59:52 48 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 3.000000 remaining slots
14:59:52 48 00:00:00:00:00:02 -> MAC frame not for me, drop!
14:59:52 50 00:00:00:00:00:03 -> MAC frame not for me, drop!
14:59:52 50 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
14:59:52 109 00:00:00:00:00:03 -> uplayer PKT arrived, contention
window size is 7
14:59:52 109 00:00:00:00:00:03 -> channel idle now, wait for DIFS
only
14:59:52 163 00:00:00:00:00:02 -> channel idled for DIFS and
3.000000 slots time
14:59:52 163 00:00:00:00:00:02 -> csmaca mac, finish sending

37

31 14:59:52 163 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,


no ACK yet
32 14:59:52 167 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.057061
33 14:59:52 167 00:00:00:00:00:03 -> channel busy
34 14:59:52 176 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 4.000000 remaining slots
35 14:59:52 177 00:00:00:00:00:00 -> receives PKT 1 from
00:00:00:00:00:02, CRC right
36 14:59:52 176 00:00:00:00:00:03 -> MAC frame not for me, drop!
37 14:59:52 177 00:00:00:00:00:00 -> channel idle now, wait for SIFS
only
38 14:59:52 177 00:00:00:00:00:01 -> MAC frame not for me, drop!
39 14:59:52 178 00:00:00:00:00:00 -> channel idled for SIFS
40 14:59:52 178 00:00:00:00:00:00 -> sending PKT 1s ACK to
00:00:00:00:00:02
41 14:59:52 180 00:00:00:00:00:00 -> csmaca mac, finish sending
42 14:59:52 180 00:00:00:00:00:00 -> finish sending PKT 1s ACK to
00:00:00:00:00:02
43 14:59:52 182 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.005772
44 14:59:52 182 00:00:00:00:00:03 -> channel busy
45 14:59:52 186 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 4.000000 remaining slots
46 14:59:52 186 00:00:00:00:00:01 -> MAC frame not for me, drop!
47 14:59:52 186 00:00:00:00:00:03 -> MAC frame not for me, drop!
48 14:59:52 187 00:00:00:00:00:02 -> gets PKT 1s ACK from
00:00:00:00:00:00. One COMM Suc
49 14:59:52 306 00:00:00:00:00:03 -> channel idled for DIFS and
4.000000 slots time
50 14:59:52 306 00:00:00:00:00:03 -> csmaca mac, finish sending
51 14:59:52 306 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
52 14:59:52 318 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
53 14:59:52 318 00:00:00:00:00:00 -> MAC frame not for me, drop!
54 14:59:52 318 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
55 14:59:52 320 00:00:00:00:00:02 -> MAC frame not for me, drop!
56 14:59:52 320 00:00:00:00:00:01 -> channel idled for SIFS
57 14:59:52 320 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:03
58 14:59:52 322 00:00:00:00:00:01 -> csmaca mac, finish sending
59 14:59:52 323 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
60 14:59:52 328 00:00:00:00:00:03 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
61 14:59:52 329 00:00:00:00:00:02 -> MAC frame not for me, drop!
62 14:59:52 330 00:00:00:00:00:00 -> MAC frame not for me, drop!

C.7 Test case7 log

38

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

15:11:08 541 00:00:00:00:00:03 -> is ready to receive and send


15:11:08 553 00:00:00:00:00:01 -> is ready to receive and send
15:11:08 556 00:00:00:00:00:02 -> is ready to receive and send
15:11:08 562 00:00:00:00:00:00 -> is ready to receive and send
15:11:11 563 00:00:00:00:00:00 -> uplayer PKT arrived, contention
window size is 7
15:11:11 563 00:00:00:00:00:00 -> channel idle now, wait for DIFS
only
15:11:11 663 00:00:00:00:00:00 -> channel idled for DIFS
15:11:11 663 00:00:00:00:00:00 -> csmaca mac, finish sending
15:11:11 663 00:00:00:00:00:00 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
15:11:11 677 00:00:00:00:00:03 -> MAC frame not for me, drop!
15:11:11 677 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:00, CRC right
15:11:11 677 00:00:00:00:00:02 -> MAC frame not for me, drop!
15:11:11 677 00:00:00:00:00:02 -> uplayer PKT arrived, contention
window size is 7
15:11:11 677 00:00:00:00:00:02 -> channel idle now, wait for DIFS
only
15:11:11 677 00:00:00:00:00:01 -> channel idle now, wait for SIFS
only
15:11:11 679 00:00:00:00:00:01 -> channel idled for SIFS
15:11:11 679 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:00
15:11:11 681 00:00:00:00:00:01 -> csmaca mac, finish sending
15:11:11 681 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
15:11:11 683 00:00:00:00:00:02 -> interrupted in DIFS, time
elapsed 0.006014
15:11:11 684 00:00:00:00:00:02 -> channel busy
15:11:11 688 00:00:00:00:00:02 -> channel idle now, wait for DIFS
and 7.000000 remaining slots
15:11:11 689 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
15:11:11 689 00:00:00:00:00:03 -> MAC frame not for me, drop!
15:11:11 689 00:00:00:00:00:02 -> MAC frame not for me, drop!
15:11:11 741 00:00:00:00:00:03 -> uplayer PKT arrived, contention
window size is 7
15:11:11 741 00:00:00:00:00:03 -> channel idle now, wait for DIFS
only
15:11:11 823 00:00:00:00:00:02 -> channel idled for DIFS and
7.000000 slots time
15:11:11 823 00:00:00:00:00:02 -> csmaca mac, finish sending
15:11:11 823 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
15:11:11 826 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.084149
15:11:11 826 00:00:00:00:00:03 -> channel busy
15:11:11 833 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 3.000000 remaining slots
15:11:11 835 00:00:00:00:00:01 -> MAC frame not for me, drop!
15:11:11 835 00:00:00:00:00:03 -> MAC frame not for me, drop!

39

36 15:11:11 835 00:00:00:00:00:00 -> receives PKT 1 from


00:00:00:00:00:02, CRC right
37 15:11:11 835 00:00:00:00:00:00 -> channel idle now, wait for SIFS
only
38 15:11:11 837 00:00:00:00:00:00 -> channel idled for SIFS
39 15:11:11 837 00:00:00:00:00:00 -> sending PKT 1s ACK to
00:00:00:00:00:02
40 15:11:11 839 00:00:00:00:00:00 -> csmaca mac, finish sending
41 15:11:11 840 00:00:00:00:00:00 -> finish sending PKT 1s ACK to
00:00:00:00:00:02
42 15:11:11 841 00:00:00:00:00:03 -> interrupted in DIFS, time
elapsed 0.007383
43 15:11:11 841 00:00:00:00:00:03 -> channel busy
44 15:11:11 844 00:00:00:00:00:03 -> channel idle now, wait for DIFS
and 3.000000 remaining slots
45 15:11:11 845 00:00:00:00:00:01 -> MAC frame not for me, drop!
46 15:11:11 846 00:00:00:00:00:02 -> gets PKT 1s ACK from
00:00:00:00:00:00. One COMM Suc
47 15:11:11 846 00:00:00:00:00:03 -> MAC frame not for me, drop!
48 15:11:11 960 00:00:00:00:00:03 -> channel idled for DIFS and
3.000000 slots time
49 15:11:11 960 00:00:00:00:00:03 -> csmaca mac, finish sending
50 15:11:11 960 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
51 15:11:11 971 00:00:00:00:00:01 -> receives PKT 1 from
00:00:00:00:00:03, CRC right
52 15:11:11 973 00:00:00:00:00:00 -> MAC frame not for me, drop!
53 15:11:11 973 00:00:00:00:00:02 -> MAC frame not for me, drop!
54 15:11:11 972 00:00:00:00:00:01 -> channel busy
55 15:11:11 973 00:00:00:00:00:01 -> channel idle now, wait for SIFS
and 0.000000 remaining slots
56 15:11:11 975 00:00:00:00:00:01 -> channel idled for SIFS and
0.000000 slots time
57 15:11:11 975 00:00:00:00:00:01 -> sending PKT 1s ACK to
00:00:00:00:00:03
58 15:11:11 976 00:00:00:00:00:01 -> csmaca mac, finish sending
59 15:11:11 978 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:03
60 15:11:11 983 00:00:00:00:00:03 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
61 15:11:11 984 00:00:00:00:00:00 -> MAC frame not for me, drop!
62 15:11:11 984 00:00:00:00:00:02 -> MAC frame not for me, drop!
63 15:11:12 554 00:00:00:00:00:01 -> uplayer PKT arrived, contention
window size is 7
64 15:11:12 554 00:00:00:00:00:01 -> channel idle now, wait for DIFS
only
65 15:11:12 654 00:00:00:00:00:01 -> channel idled for DIFS
66 15:11:12 654 00:00:00:00:00:01 -> csmaca mac, finish sending
67 15:11:12 654 00:00:00:00:00:01 -> sent PKT 1 to 00:00:00:00:00:03,
no ACK yet
68 15:11:12 666 00:00:00:00:00:00 -> MAC frame not for me, drop!
69 15:11:12 667 00:00:00:00:00:03 -> receives PKT 1 from
00:00:00:00:00:01, CRC right
70 15:11:12 667 00:00:00:00:00:02 -> MAC frame not for me, drop!

40

71 15:11:12 668 00:00:00:00:00:03 -> channel idle now, wait for SIFS
only
72 15:11:12 669 00:00:00:00:00:03 -> channel idled for SIFS
73 15:11:12 669 00:00:00:00:00:03 -> sending PKT 1s ACK to
00:00:00:00:00:01
74 15:11:12 672 00:00:00:00:00:03 -> csmaca mac, finish sending
75 15:11:12 672 00:00:00:00:00:03 -> finish sending PKT 1s ACK to
00:00:00:00:00:01
76 15:11:12 677 00:00:00:00:00:02 -> MAC frame not for me, drop!
77 15:11:12 677 00:00:00:00:00:00 -> MAC frame not for me, drop!
78 15:11:12 678 00:00:00:00:00:01 -> gets PKT 1s ACK from
00:00:00:00:00:03. One COMM Suc

41