Final Project

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
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.
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
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.
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.
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.
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 ->
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 idled for DIFS
csmaca mac, finish sending
sent PKT 1 to 00:00:00:00:00:01,
interrupted in DIFS, time
channel busy
channel busy
26
18 12:37:38 745 00:00:00:00:00:02 -> 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
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
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
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
00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
00:00:00:00:00:02
elapsed 0.005637
50 12:37:38 900 00:00:00:00:00:03 -> channel busy
27

00:00:00:00:00:00. One COMM Suc
1.000000 slots time
57 12:37:39 11 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
00:00:00:00:00:03, CRC right
59 12:37:39 22 00:00:00:00:00:01 -> channel busy
63 12:37:39 24 00:00:00:00:00:01 -> channel idled for SIFS and
0.000000 slots time
00:00:00:00:00:03
00:00:00:00:00:03
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 ->
is ready to
is ready to
is ready to
uplayer PKT
receive and send

receive and send
receive and send
arrived, contention

sent PKT 1 to 00:00:00:00:00:01,
channel busy
channel busy
28
00:00:00:00:00:00, CRC right
only
00:00:00:00:00:00
elapsed 0.007667
25 12:37:38 752 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:00
elapsed 0.007557
28 12:37:38 752 00:00:00:00:00:02 -> channel busy
00:00:00:00:00:01. One COMM Suc
5.000000 slots time
36 12:37:38 882 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
5.861168
38 12:37:38 885 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
00:00:00:00:00:02
elapsed 0.005637
49 12:37:38 900 00:00:00:00:00:03 -> channel busy
29
00:00:00:00:00:00. One COMM Suc
1.000000 slots time
56 12:37:39 11 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
00:00:00:00:00:03, CRC right
58 12:37:39 22 00:00:00:00:00:01 -> channel busy
0.000000 slots time
00:00:00:00:00:03
00:00:00:00:00:03
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
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
only
only
00:00:00:00:00:00
elapsed 0.007183
25 12:09:43 242 00:00:00:00:00:03 -> channel busy
elapsed 0.011427
27 12:09:43 243 00:00:00:00:00:02 -> channel busy
00:00:00:00:00:00
00:00:00:00:00:01. One COMM Suc
0.000000 slots time
36 12:09:43 347 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
0.676994
38 12:09:43 351 00:00:00:00:00:03 -> channel busy
2.000000 slots time
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
window size is 14
46 12:09:45 469 00:00:00:00:00:03 -> timer expire, re-transmits PKT 1
31

window size is 14
9.000000 slots time
51 12:09:45 493 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
elapsed 0.026391
53 12:09:45 496 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
elapsed 0.007536
62 12:09:45 511 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:02
00:00:00:00:00:00. One COMM Suc
5.000000 slots time
71 12:09:45 641 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
00:00:00:00:00:03, CRC right
only
00:00:00:00:00:03
00:00:00:00:00:03
32

00:00:00:00:00:01. One COMM Suc
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 ->
14:46:07 431 00:00:00:00:00:03 ->
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

sent PKT 1 to 00:00:00:00:00:01,
channel busy
channel busy
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
finish sending PKT 1s ACK to
channel busy
33

elapsed 0.009638
31 14:46:07 441 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:01. One COMM Suc
0.000000 slots time
39 14:46:07 545 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:03,
no ACK yet
0.752382
41 14:46:07 549 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
00:00:00:00:00:02
elapsed 0.006546
00:00:00:00:00:03. One COMM Suc
1.000000 slots time
58 14:46:07 669 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:02,
no ACK yet
00:00:00:00:00:03, CRC right
only
34

00:00:00:00:00:03
00:00:00:00:00:03
00:00:00:00:00:02. One COMM Suc
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: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
window size is 7
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:03 -> 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
elapsed 0.007596
14:01:54 945 00:00:00:00:00:02 -> channel busy
14:01:54 945 00:00:00:00:00:01 -> finish sending PKT 1s ACK to
00:00:00:00:00:00
35

00:00:00:00:00:01. One COMM Suc
window size is 7
only
32 14:01:55 114 00:00:00:00:00:03 -> channel idled for DIFS
34 14:01:55 115 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
6.937995
36 14:01:55 118 00:00:00:00:00:02 -> channel busy
00:00:00:00:00:03, CRC right
only
00:00:00:00:00:03
00:00:00:00:00:03
elapsed 0.007507
47 14:01:55 135 00:00:00:00:00:02 -> channel busy
00:00:00:00:00:01. One COMM Suc
1.000000 slots time
54 14:01:55 249 00:00:00:00:00:02 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
00:00:00:00:00:02
36
00:00:00:00:00:00. One COMM Suc
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

window size is 7
only
14:59:52 23 00:00:00:00:00:00 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
window size is 7
14:59:52 32 00:00:00:00:00:02 -> channel busy
00:00:00:00:00:00, CRC right
only
00:00:00:00:00:00
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 50 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
window size is 7
only
14:59:52 163 00:00:00:00:00:02 -> channel idled for DIFS and
3.000000 slots time
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
elapsed 0.057061
33 14:59:52 167 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
00:00:00:00:00:02
elapsed 0.005772
44 14:59:52 182 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:00. One COMM Suc
4.000000 slots time
51 14:59:52 306 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
00:00:00:00:00:03, CRC right
only
00:00:00:00:00:03
00:00:00:00:00:03
00:00:00:00:00:01. One COMM Suc
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

window size is 7
only
15:11:11 663 00:00:00:00:00:00 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
00:00:00:00:00:00, CRC right
window size is 7
only
only
00:00:00:00:00:00
00:00:00:00:00:00
elapsed 0.006014
15:11:11 684 00:00:00:00:00:02 -> channel busy
15:11:11 689 00:00:00:00:00:00 -> gets PKT 1s ACK from
00:00:00:00:00:01. One COMM Suc
window size is 7
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 -> sent PKT 1 to 00:00:00:00:00:00,
no ACK yet
elapsed 0.084149
15:11:11 826 00:00:00:00:00:03 -> channel busy
39

00:00:00:00:00:02, CRC right
only
00:00:00:00:00:02
00:00:00:00:00:02
elapsed 0.007383
43 15:11:11 841 00:00:00:00:00:03 -> channel busy
00:00:00:00:00:00. One COMM Suc
3.000000 slots time
50 15:11:11 960 00:00:00:00:00:03 -> sent PKT 1 to 00:00:00:00:00:01,
no ACK yet
00:00:00:00:00:03, CRC right
54 15:11:11 972 00:00:00:00:00:01 -> channel busy
0.000000 slots time
00:00:00:00:00:03
00:00:00:00:00:03
00:00:00:00:00:01. One COMM Suc
window size is 7
only
65 15:11:12 654 00:00:00:00:00:01 -> channel idled for DIFS
67 15:11:12 654 00:00:00:00:00:01 -> sent PKT 1 to 00:00:00:00:00:03,
no ACK yet
00:00:00:00:00:01, CRC right
40
only
00:00:00:00:00:01
00:00:00:00:00:01
00:00:00:00:00:03. One COMM Suc
41

Final Project

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Project

Uploaded by

Copyright:

Available Formats

GNURadio MAC Final Report

GNURadio MAC Team

2 System Design and Implementation

4 Efficiency of the GNURadio-MACer

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

Not Using IEEE 802.11

Wait for Random

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

1.4 802.11 MAC Frame

Figure 2: 802.11 frame format

2 System Design and Implementation

Figure 3: Interactions between MAC and PHY layers

2.2 PHY layer - based on USRP

Make MAC layer Independent of Hardware

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

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

PHY layer Overview

Figure 5: Interactions between MAC and PHY layers

2.3 MAC layer - CSMA/CA

MAC layer Overview

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

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

S_Pkt: self_pakcet want to send

Figure 6: The State Transition Diagram of MAC layer

2.4 802.11 MAC frame practice

2.5 GUI - Event Driven Practice

Wait for DIFS,

Pause back off

Not interrupted or timer expire

Figure 7: MAC layer transmitting flow chart

Get the type of

Wait for SIFS

Figure 8: MAC layer receiving flow chart

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

Figure 9: GUI layout

3 The Correctness Testing

3.1 Test Case 1

Figure 10: Test Case 1

3.2 Test Case 2

3.3 Test Case 3

Figure 11: Test Case 2

Figure 12: Test Case 3

3.4 Test Case 4

Figure 13: Test Case 4

3.5 Test Case 5

Figure 14: Test Case 5

3.6 Test Case 6

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

Figure 15: Test Case 6

3.7 Test Case 7

Figure 16: Test Case 7

4 Efficiency of the GNURadio-MACer

Figure 17: PHY Frame Format

settings of each field are as followed:

Figure 18: Components of Pure Theoretical MAC Efficiency

We derive the generic equation of pure theoretical MAC efficiency as

4.2 USRP Impact on Theoretical MAC Efficiency

Figure 19: Components of Real Theoretical MAC Efficiency

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

4.3 Practice Efficiency of different cases

Table 2: Delays of real theoretical MAC efficiency

Two transceivers - Efficiency

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

Four transceivers - Efficiency & Fairness