Software Defined Radio Implementation of aTwo-way Relay Network with Digital Network

CodingDmitry Kramarev, Yi Hong, and Emanuele Viterbo

Department of Electrical and Computer Systems Engineering,Monash University, Australia

Email: {dmitry.kramarev, yi.hong, emanuele.viterbo}@monash.edu

Abstract—Network coding is a technology which has thepotential to increase network throughput beyond existing stan-dards based on routing. Despite the fact, that the theoreticalunderstanding is mature, there have been only a few paperson implementation of network coding and demonstration of aworking testbed. This paper presents the implementation ofa two-way relay network with digital network coding. Unlikeprevious work, where the testbeds are implemented on customhardware, we implement the testbed on GNU Radio, an open-source software defined radio platform. In this paper we discussthe implementation issues and the ways to overcome the hardwareimperfections and software inadequacies of the GNU Radioplatform. Using our testbed we measure the throughput of thesystem in an indoor environment. The experimental results showthat the network coding outperforms the traditional routing aspredicted by the theoretical analysis.

Index Terms—Software-defined radio, GNU radio, networkcoding, two-way relay network, testbed, network coding imple-mentation.

I. INTRODUCTION

In the simplest two-way relay network (TWRN), twoterminals A and B exchange information via relay R. Therelay is needed when the terminals are unable to communicatedirectly due to large distance, low SNR or major obstacles.The traditional scheduling (TS) scheme implements suchcommunication in four time slots, as shown in Figure 1a.First, A transmits a message m1 to relay R; second, relay Rforwards m1 to B. In the third and fourth time slots, terminalB transmits a message m2 to relay R, and R forwards m2

to A, respectively. With digital network coding (DNC), it ispossible to increase the throughput of the network by 33%via reducing the number of time slots to three, as shown in(Figure 1b). In the first and second time slots, each terminaltransmits its message m1 and m2 to the relay, then in thethird slot, relay R broadcasts the XOR of the two receivedmessages m1 ⊕m2 to both terminals. In this case, a terminalis able to recover the information based on the receivedcombination and its own transmitted message. DNC was firstproposed in [1] and [2]. Physical-layer network coding (PNC)proposed in [3] allows for further reduction of the number oftime slots to two, by superposing the first and the second timeslots. The design of a PNC testbed will be investigated inour future work. In [4] Louie et al. compare the performance

N210 N210

N210

N210 N210

N210

A B

R

A B

R

1 2

34

1 2

33

(a)

N210 N210

N210

N210 N210

N210

A B

R

A B

R

1 2

34

1 2

33

(b)

Fig. 1: Two-way relay network with (a) the four-hop TS, and(b) three-hop DNC scheme

of the two-, three-, and four-hop TWRNs. The paper alsoprovides an extensive survey of the recent theoretical workon network coding for two-way relay networks.

Although a significant number of theoretical results havebeen verified by simulations, limited results are available onthe implementation of TWRN testbeds on real-time hardware.Only a few implementations of DNC in TWRN or larger relaynetworks are reported in [2], [5] and [6]. For example, [5]demonstrates essential reduction of time required to exchangevideo files between smartphones, in case DNC is employed.In [2], Katti et al. present a new architecture for wirelessmesh networks (COPE), which improves the throughput ofwireless networks by forwarding DNC mixed packets. Thetestbed consists of 20 wireless nodes located on two floors ofa building. In addition to demonstrating advantages of DNC,the authors also investigate the implementation issues of alarge network, such as the congestions control, traffic patterns

2014 Australian Communications Theory Workshop (AusCTW)

978-1-4799-3354-9/14/$31.00 ©2014 IEEE 120

and optimal routing. Another example of implementationof a multi-hop relay network with MIMO network codingis provided in [6]. The MIMO TWRN implements dataexchange within two time slots by transmitting messagesfrom both the terminals at the same time. Both messages arefully recovered by exploiting multiuser antenna diversity ofMIMO system with space-time coding. Then the messagesare XORed and broadcasted in the second time slot.

All the testbeds, mentioned above are implemented onspecific dedicated hardware. Such hardware provides onlya few opportunities to easily modify the important physicallayer functions and parameters such as modulation type,frequency range etc., or extend an experiment. In contrast,software-defined radio (SDR) enables to implement insoftware all the baseband signal processing algorithms suchas modulation, demodulation, filtering, and synchronization[7] - [9]. The hardware for SDR is based on an inexpensivesimple RF front-end, followed by analog-to-digital anddigital-to-analog converters. SDR introduces significantflexibility and programmability, compared to traditionalcommunication systems.

Taking into account this gap between theory and practicewe see the interest for implementation of a two-way relaynetwork testbed using SDR. As a first step towards theimplementation of PNC in TWRN, we design a three-hopDNC relay network using GNU Radio, an open-source SDRplatform. GNU Radio provides signal processing blocksto implement software radios using external low-cost RFhardware. GNU Radio applications, written in the Pythonlanguage consist of signal processing blocks implemented inC++. Using these blocks and creating new custom blocks,we are able to implement real-time radio systems in asimple-to-use environment [10]. In this paper we discuss theimplementation challenges in GNU Radio and analyze theperformance of our testbed.

The rest of this paper is organized as follows. In Section IIwe describe some implementation aspects and ways we haveused to resolve them. Section III provides detail descriptionof two-way relay network schemes for our testbed. Theexperimental environment and measurements results areprovided in Section IV. Finally, Section V concludes thispaper and discusses directions for future work.

II. IMPLEMENTATION ASPECTS OF THE HALF-DUPLEXCOMMUNICATION

In this section we discuss implementation aspects for thehalf-duplex communication used in the prototype testbed.We start with the discussion of hardware and softwareplatforms, and we then present design aspects for half-duplexpacket-switched communications in GNU Radio. Also, wesummarize all the parameters of the different blocks involvedin the design and describe the used packet format.

-�Wb

Fig. 2: Bandpass signal spectrum with IF processing

A. Hardware and Software

The hardware platform is based on Universal SoftwareRadio Peripheral (USRP) N210 from Ettus Research [11].Each USRP is equipped with an half-duplex XCVR2450daughterboard operating in 2.4-2.5 GHz and 4.9-5.9 GHz dualband. The GigE interface connects the USRP and the hostPC, and allows for 25 MSPS (16-bit) data transfer. We setthe carrier frequency at 2.41 GHz and the sampling rate at6.25 Msps (complex samples) at the USRP source and sink.A terminal is implemented with an USRP N210 connected toan individual PC running GNU Radio. The software is basedupon GNU Radio 3.6.2.

B. Mitigation of the USRP Transmission noise

Measurements with a spectrum analyzer indicate, that RFsof the daughterboards have a significant DC component,volume of which largely varies from one daughterboard to an-other. This phenomenon causes TX gain control parameters tobe unrepresentative and the TX SNR uncontrollable. As such,swapping of two terminals can cause significant degradationof the system throughput, especially with lower TX gains.

In order to mitigate this TX noise impact we have employedadditional digital up/down-conversion of the baseband signalto a small intermediate frequency (IF). The intermediatefrequency fI is chosen such that fI > Wb/2, where Wb isthe bandwidth of the transmitted signal. The baseband signalis first up-converted to IF on the TX side using the onboardFPGA. Then, we choose the carrier frequency fc in the USRPsink such that:

fc = fd − fI ,

where fd is the actual transmitted carrier frequency. Thespectrum of the resulting bandpass signal after IF processingis illustrated in Figure 2. Similarly, on the receiver side,the bandpass signal is first down-converted to IF fI by theUSRP’s daughterboard and further digital down-conversion tobaseband is performed by the FPGA on the motherboard. As aresult, the unwanted noisy component is shifted to frequency

2014 Australian Communications Theory Workshop (AusCTW)

121

f = −fI < Wb/2 and suppressed by the pulse-shapingfilter before demodulation. Thus, our IF processing improvesthe TX SNR, and in turn increases the effective range ofTX gains. This makes manual calibration of the TX powerunnecessary.

C. Half-Duplex Packet Switching in GNU Radio

The current GNU Radio software architecture is primarilyaimed at processing continuous data streams. Packet switchingis therefore difficult to implement in the GNU Radio receiverdue to the bursty nature of the incoming stream. In the currentversion of GNU Radio blocks are not clocked and operateunder the control of a scheduler, which attempts to provide asteady stream of input data to each signal processing block.To the best of our knowledge there is no half-duplex packetswitching implementations which would be satisfactory toadopt in our project in GNU Radio.

We employ the transmit-on-receive approach, i.e., aterminal transmits its packet upon reception from the otherterminal. This approach identifies the terminal startingcommunication as the master and the other as the slave.

preamble detected?

postamble correct?

packet_no ==packet_no_expected?

Initializing

listen

Begin

packet_no++

Make a new packet

Send packet

yes

yes

yes

no

no

ECC decoding

timeout_flag ==1

no

no

CRC correct?

Save payload

yes

no

yes

Begin

reset timer

idle

timer>Tout

reset timertimeout_flag =1

yes

no

reset timer

Master Mode only

Fig. 3: A terminal operation flowchart

Packets are equipped with sequence number which is usedas an ACK/NACK mechanism. The transmitter decides ifthe transmitted packet has been received successfully bythe receiver, based on the reply packet number. Receptionof a corrupted packet will cause the retransmission of theprevious packet, which in turn causes the retransmissionof the corrupted packet. The flowchart of this half-duplex packet switching protocol is presented in Figure 3.Upon reception from the other terminal, the terminalcompares the packet number of the received packet withthe expected packet number. If these numbers are equal,the terminal increments its own packet number and inturn transmits the next packet, otherwise re-transmits theprevious packet. The master retransmits on timeout in casethe communication is lost. The slave starts transmitting onlyafter receiving a packet from the master.

We implemented this half-duplex packet switching protocolin Python and included it into GNU Radio Companion (GRC)flow graphs as a custom block, as shown in Figures 8,9.The GRC flow graphs are described in details in the Appendix.

D. Block Parameters and Packet Format

Table I contains parameters for the communication betweentwo USRP devices.

Block Parameter ValueUSRP USRP Sample Rate 6.25M

Antenna J1Rx Gain 0 dB

Mod./Demod. Modulation Scheme DQPSK (Gray code)Samples per symbol 2Excess BW 0.3AGC Default

Half-duplex Packet Length 4096 bytesCorrelator Tolerance 9Master Timeout Tout 0.05 s.Guard time Tg 0.006 s.ECC (10,8) Reed-Solomon,

CRC Adler-32

TABLE I: Parameters of design and experiments

The packet format is presented in Figure 4. A packetbegins with 128 bytes of dummy data, followed by 8-bytesaccess code. The dummy data is sent at the beginning of thepacket and is used for carrier, phase and timing recovery onthe receiver side. An access code is needed for addressingthe destination terminal and for frame synchronization.The next part of the packet consists of one byte packet

Dummy Data Access Code packet no Encoded payload CRC pad 0x55 0xFF

128 bytes 8 bytes 1 byte 1 byte

4 bytes4096 bytes

4 bytes

SOB EOB

Fig. 4: Packet format

2014 Australian Communications Theory Workshop (AusCTW)

122

A

R

B

A

R

B0 1 2 3 1 1 2 32

timeout

timetime

(a) (b)

1 2 3 4 1 1 2 32 1 2 3 4

timeout timeout Tg Tg Tg

Fig. 5: Network synchronization: (a) the four-hop scheme, (b) the three-hop scheme

sequence number followed by the encoded payload, CRCchecksum, the pad and the postamble. For ECC we employthe (10, 8) Reed-Solomon code over GF (28), available inthe Python extension module [12]. CRC32 error detectionalgorithm is also added for post-ECC data verification. Thepostamble indicates the end of the packet and is representedby one byte with value 0x55. In the presence of timingrecovery errors, an incorrectly received postamble indicatesinsertion/deletion errors. The length of the pad variesaccording to the codeword length of the used ECC in orderto keep the required packet size. Finally, four extra bytesof 0xFF are added to the tail of the packet as a guard interval.

III. TWO-WAY RELAY NETWORK SCHEMES

In this section we provide the detailed description of thetwo-way relay network schemes implemented in the testbed,namely the four-hop scheme and three-hop scheme basedon DNC. The communication between a terminal and therelay is based on the half-duplex packet switching protocoldescribed in the previous section.

A. The Four-hop Scheme Based on the Traditional Scheduling

In the four-hop scheme each terminal has its owntx access code and rx access code. The relay has two pairsof tx access code and rx access code, such that:

tx access codeR0 = rx access codeA,tx access codeR1 = rx access codeB ,rx access codeR0 = tx access codeA,rx access codeR1 = tx access codeB .

We set one of the terminals into the master mode to performthe network synchronization. Figure 5 shows the networksynchronization scheme when terminal A is the master.Terminal A initiates the communication by sending the firstmessage m0 addressed to R. Upon receiving m0, R verifiesthe packet. If the packet is correct, the preamble of m0 ischanged from tx access codeA to rx access codeB andthis modified message m′

0 is forwarded to terminal B. Afterbeing received m′

0 is verified and processed according to theprocedure described in Figure 3. If the reception is successful,

B sends its message m1 to R and this message is forwardedto A in the same manner. Upon successful reception themaster transmits the next message and so on. In the case, apacket is lost or corrupted in any hop, time-out occurs, andthe master retransmits the previous message.

B. The Three-hop Scheme Based on DNC

In the three-hop scheme each terminal has its owntx access code but shares the rx access code. The relay hasone tx access code and two rx access code, such that:

tx access codeR0 = rx access codeA =rx access codeB ,

rx access codeR0 = tx access codeA,rx access codeR1 = tx access codeB ;

which allows relay R to communicate with both terminalsat the same time. Unlike the four-hop scheme, the networksynchronization here is performed by the relay, as shown inFigure 5. At the beginning R broadcasts a packet containingdummy data. Upon reception terminal A transmits its messageimmediately (hop 1), while B transmits after a delay Tg

(hop 2). If the messages from both the terminals are receivedsuccessfully, R performs XOR of the two messages payloaddata and broadcasts the resulting message (hop 3). Aftersuccessful reception of the broadcasted message, terminalsA and B transmit the next messages and so on. In caseany packet is lost at any hop, time-out at R happens and Rre-transmits the previous XORed packet.

IV. EXPERIMENTAL RESULTS

In this section, we demonstrate the performance of thetestbed via a series of experiments in the indoor environment.The locations of the terminals and relay are illustrated inFigure 6. Each terminal is located in a separate room suchthat the distance between terminal A and the relay is about9 meters, the distance between terminal B and the relay isabout 12 meters, and the distance between two terminals isabout 18 meters. The data exchanged between the terminals arerandomly generated. The payload scrambling is implementedto avoid pattern-dependencies. Figure 7 shows a measured

2014 Australian Communications Theory Workshop (AusCTW)

123

Fig. 6: Locations of the terminals in the indoor environment

average data throughput of the TWRN per direction vs. theTX gain. With TX gain 20dB the average data throughput perdirections achieves about 504 kbps and 664 kbps for TS andDNC, respectively. The lower performance of the TS schemeat 25 dB may be due to power amplifier nonlinearity. Thus, thethroughput of the DNC scheme is about 30% higher than thatof the TS scheme. Also, the figure demonstrates the advantageof the TWRN communication over direct communication,when the distance between the terminals is large. Directcommunication between two terminals without relay is onlypossible with the highest TX gain (25 dB). Despite the gain,the throughput is still lower than that of the TWRN due topresence of uncorrectable errors, insertion/deletion errors andpacket losses.

Dat

a th

roug

hput

, kb

ps

0

100

200

300

400

500

600

700

Tx Gain, dB10 15 20 25

DNC TS direct

Fig. 7: Measured average data throughput per direction vs. TXgain

V. CONCLUSION AND FUTURE WORK

In this paper we have presented a prototype of the two-wayrelay network implemented in GNU Radio. This prototypesupports both the four-hop traditional scheduling protocol andthe three-hop digital network coding. In order to overcome thenegative impact of the hardware imperfections and softwareinadequacies we have implemented a few signal processingalgorithms on the FPGA of the USRP devices, such as theintermediate frequency processing. Additionally, we havedesigned the GNU Radio blocks for the half-duplex packetswitching.

We then have investigated the performance of the testbedin terms of throughput. The actual throughput of the testbedusing digital network coding is about 30% higher than thatof the traditional scheduling. This result agrees with thetheoretical performance. At the same time, the throughput ofthe direct communication without the relay is significantlylower than that of the TWRN.

Finally, our future research will focus on implementationof the physical-layer network coding for the two-way relaynetwork.

ACKNOWLEDGEMENT

This work was performed at the Monash Software DefinedTelecommunications Lab. This work was partially supportedby Australian Federal and Victoria State Governments andthe Australian Research Council through the ICT Centre ofExcellence program, National ICT Australia (NICTA).

APPENDIX

GNU Radio Companion (GRC) generates a signalprocessing Python script from the signal flow graph. Wecreate a GRC flow graph composed of standard and customblocks. The flow graphs representing a terminal and the relayare shown in Figures 8 - 10. Figure 8 shows a flow graph ofa terminal for the four-hop scheme. Figure 9 shows a flowgraph of a terminal adapted for the three-hop scheme. Theskip head block is used to skip the dummy data from thefirst message sent for synchronization purpose. The XORblock connected with output rx out of Half-Duplex blockand the source file is used to recover the message from thenetwork-coded received packet.

The GRC flow graph of the relay for both schemes isshown in Figure 10, where both the schemes are implementedin Python in the block Half-Duplex-R.

REFERENCES

[1] R. Ahlswede, N. Cai, S.-Y. Li, and R. Yeung, “Network information flow,”IEEE Trans. Inf. Theory, vol. 46, no. 4, pp. 1204-1216, July 2000.

[2] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Medard, and J. Crowcroft,“XORs in the air: Practical wireless network coding,” IEEE/ACM Trans.on Networking, vol. 16, no. 3, pp. 497-510, June 2008.

2014 Australian Communications Theory Workshop (AusCTW)

124

Fig. 8: GRC flow graph of the terminal with the four-hop scheme

Fig. 9: GRC flow graph of the terminal with the three-hop scheme

Fig. 10: GRC flow graph of the relay

[3] S. Zhang, S. C. Liew, and P. P. Lam, “Physical-Layer Network Coding,”in Proceedings of the 12th annual international conference on Mobilecomputing and networking (MobiCom 06), pp. 358-365, LA, USA, Sept.2006

[4] R. H. Y. Louie, Y. Li, and B. Vucetic, “Practical Physical Layer NetworkCoding for Two-Way Relay Channels: Performance Analysis and Com-parison,” IEEE Trans. on Wireless Comm., vol. 9, no. 2, pp. 764-777,Feb. 2010.

[5] H. Seferoglu, L. Keller, B. Cici, A. Le, and A. Markopoulou, “CooperativeVideo Streaming on Smartphones,” Proceedings of the 49th AnnualAllerton Conference, pp. 220-227, Illinois, USA, 2011.

[6] K. Mizutani, Y. Kida, T. Miyamoto, K. Sakaguchi, and K. Araki, “Real-ization of TDD Two-way Multi-hop Relay Network with MIMO NetworkCoding,” Proceedings of the 6th Int. ICST Conference on Cognitive RadioOriented Wireless Networks and Communications, Osaka, Japan, 2011.

[7] A. Abidi, “The Path to the Software-Defined Radio Receiver,” IEEE J.Solid-St. Circ., vol. 42, no. 5, pp. 954-966, May 2007.

[8] J. Mitola, “The Software Radio Architecture,” IEEE Commun. Mag., vol.33, no. 5, pp. 26-38, May 1995.

[9] C. Johnson, W. Sethares, and A. Klein, “Software Receiver Design,”

Cambridge University Press, 2011.[10] GNU Radio: http://gnuradio.org/[11] Ettus Research USRP N210, https://www.ettus.com/product/details/UN210-

KIT[12] Reed-Solomon ECC Python Extension Module,

http://hathawaymix.org/Software/ReedSolomon/

2014 Australian Communications Theory Workshop (AusCTW)

125