IT 11 008

Examensarbete 30 hp
February 2011

Evaluation and Enhancement of

TCP with Network Coding in Wireless
Multihop Networks
Xiaolin Bai

Institutionen fr informationsteknologi
Department of Information Technology

Abstract
Evaluation and Enhancement of TCP with Network
Coding in Wireless Multihop Networks
Xiaolin Bai

Teknisk- naturvetenskaplig fakultet

UTH-enheten
Besksadress:
ngstrmlaboratoriet
Lgerhyddsvgen 1
Hus 4, Plan 0
Postadress:
Box 536
751 21 Uppsala
Telefon:
018 471 30 03
Telefax:
018 471 30 00
Hemsida:
http://www.teknat.uu.se/student

Network coding is a very promising technology to efficiently utilize resources of both

wired and wireless networks, and has received much attention from both academia
and industry recently. Since wireless channel is inherently broadcast and suitable for
application of network coding. However, the performance of legacy TCP over
wireless ad hoc network is not satisfactory due to the special features of wireless
networks, such as hidden terminal and exposed terminal problems, transmission
errors, topology variations and routing instability, etc. As we know, the performance
degradation of TCP may be caused by the rate control mechanism of TCP itself and
routing protocol, while no research on this issue has been found until now. Thus, in
this paper, we implement the COPE based on NS-2, and evaluate the performance of
COPE with other TCP protocols adapted for wireless ad hoc network, such as
TCP-FeW and TCP-AP. The simulation results show that COPE can greatly improve
the network throughput and is reasonable framework to wireless network coding.
However, COPE does not work for every network topology with each TCP protocol,
or even worse than the traditional transmission mode. To overcome this problem, I
propose two schemes to improve the performance of TCP over wireless network
coding. One is called Encode Once, which ensures the packet being encoded at most
one time and improves the performance of COPE. Another one is called Network
Coding Aware TCP, which adapts sending rate of TCP based on
TCP-AP protocol and increases the network throughput.

Handledare: Lianghui Ding

mnesgranskare: Ping Wu
Examinator: Anders Jansson
IT 11 008
Tryckt av: Reprocentralen ITC

Contents
1

Introduction
1.1 Problem Statement and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Wireless Multihop Networks and Network Coding

2.1 Wireless Ad Hoc Networks . . . . . . . . . . .
2.2 TCP in Wireless Ad Hoc Networks . . . . . . .
2.2.1 NewReno . . . . . . . . . . . . . . . .
2.2.2 TCP-FeW . . . . . . . . . . . . . . . .
2.2.3 TCP-AP . . . . . . . . . . . . . . . . .
2.3 Network Coding . . . . . . . . . . . . . . . . .
2.4 COPE . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Opportunistic Listening . . . . . . . .
2.4.2 Opportunistic Coding . . . . . . . . . .
2.4.3 Reception Report . . . . . . . . . . . .

Network Simulator: NS-2

Implementation of COPE on NS-2

4.1 Opportunistic Listening . . . . . . . . .
4.2 Opportunistic Coding . . . . . . . . . .
4.3 Reception Report . . . . . . . . . . . .
4.4 Pseudo Broadcast . . . . . . . . . . . .
4.5 Asynchronous ACK and Retransmission
4.6 Packet Reception . . . . . . . . . . . .
4.7 Definition of Packet Header . . . . . . .
4.8 Definition of COPE . . . . . . . . . . .
4.9 Definition of Queues . . . . . . . . . .
4.9.1 COPEPriQueue . . . . . . . . .
4.9.2 NonAckQueue . . . . . . . . .
4.9.3 AckPendQueue . . . . . . . . .
4.9.4 PacketPool . . . . . . . . . . .
4.9.5 PacketInfo . . . . . . . . . . .
4.9.6 ProbGuess . . . . . . . . . . .
4.9.7 VirQueue . . . . . . . . . . . .
4.10 Timers . . . . . . . . . . . . . . . . . .
4.10.1 CopeTimer . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

8
8
9
9
10
10
10
12
12
12
13
14
15
15
15
16

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

20
20
20
21
21
21
21
22
22
23
23
24
25
25
27
27
30
30
30

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

31
31
31
31
34
35
35
35
35
36
36

Simulation and Performance

5.1 Simulation Setup . . . .
5.2 Performance Metrics . .
5.3 Simulation Results . . .
5.3.1 Chain Topology .
5.3.2 X-I Topology . .
5.3.3 X-II Topology .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

37
37
37
38
38
38
39

Proposal and Evaluation

6.1 Encode Once . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Network Coding Aware TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42
42
43

Conclusions and Future Work

7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45
45
45

4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
5

4.10.2 NonAckTimer
4.10.3 CtrlPktTimer .
Opportunistic Listening
Opportunistic Coding .
Decoding . . . . . . .
Reception Report . . .
Asynchronous ACKs .
Control Packet . . . . .
Retransmission . . . .
Resume a packet . . .
TCP Reordering . . . .

Bibliography

47

List of Figures
2.1
2.2
2.3

A Classic Wireless Ad Hoc Network . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Principle of Network Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
COPE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11
13
14

3.1
3.2

Structure of mobile node in NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Structure of mobile node with COPE in NS-2 . . . . . . . . . . . . . . . . . . . . . . .

17
19

4.1
4.2
4.3
4.4
4.5
4.6
4.7

COPE Packet Header . . . . . .

COPE Structure . . . . . . . . .
Class Graph for COPEPriQueue
Butterfly Topology . . . . . . .
Neighbors Packet Status . . . .
Downside Packet Received . . .
Upside Packet Received . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

22
23
24
28
28
32
34

5.1
5.2
5.3
5.4
5.5
5.6

Chain Topology . . . . . . . .
Throughput in Chain Topology
X-I Topology . . . . . . . . .
Throughput in X-I Topology .
X-II Topology . . . . . . . . .
Throughput in X-II Topology .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

38
39
40
40
41
41

6.1
6.2

Throughput of X-I topology with Encode Once . . . . . . . . . . . . . . . . . . . . . .

Throughput of X-I topology with Network Coding Aware Using TCP-AP . . . . . . . .

43
44

.
.
.
.
.
.

Chapter 1

Introduction
Network coding, is young and very promising technology. It was the seminal paper Network information
flow by Ahlswede, Cai, Li and Yeung [1], that gave birth to network coding. Network coding is to
efficiently utilize resources in both wired and wireless networks, by letting the routers operate on the
packets rather than pure forwarding, it has received much attention from both academia and industry
recently. Network coding has several advantages [2], among which the most well-known is increasing the
throughput of networks. Other important advantages are the robustness to packet loss and link failures,
easy implementation and improved security.
COPE (Coding Opportunistically) is the first practical network coding scheme for wireless networks [13,
14], and is to be used here in this thesis work. The Transmission Control Protocol (TCP) is one of the
most important protocols in the Internet Protocol Suite, which is the set of communication protocols used
for the Internet and other similar networks. TCP is intended for use as a highly reliable host-to-host
protocol between hosts in packet-switched computer communication networks, and in interconnected
systems of such networks [40]. And TCP is a connection-oriented protocol, provides end-to-end, reliable
and ordered delivery of a stream of bytes between a source and a destination device. Evaluation and
enhancement of TCP with COPE in wireless multihop networks are the tasks of this thesis work.

1.1 Problem Statement and Motivation

A number of works up to now have been done in various aspects of network coding in both wired and
wireless networks, such as coding approaches [3, 4, 5, 6], network utility optimization with network
coding [7, 8, 9, 10, 11], and implementation of network coding [12, 14], etc. Most of the above works are
on wireless networks since wireless channels are inherently broadcast and suitable for the application of
network coding.
In general, network coding can be classified into two categories: intra-session and inter-session network coding. In intra-session network coding only packets from the same session are coded, while in
inter-session network coding packets from different sessions are coded together. Intra-session network
coding is only used for multicast, and it has been proved that linear network coding can achieve the rate
region of multicast [3]. Inter-session network coding is more complicated and optimizing inter-session
network coding is still an open question. However, there are much more coexisting flows in practical
wired and wireless networks, and even simple network coding approaches can obtain significant performance gain [14]. Thus, construction and optimization of inter-session network coding are more attractive
and valuable for practical networks.
In a practical application of network coding, opportunistic network coding was proposed first implemented using XOR (Exclusive Disjunction, also called Exclusive OR) as the operation between packets
8

in a 802.11-based wireless ad hoc network, and showed significant performance gain [14]. It is shown
in [14], the performance gain of TCP with COPE in a 802.11 network is almost neglected. However, most
wireless applications rely on legacy TCP to communicate with TCP-dominant wired hosts, and it is likely
that TCP will remain as the major transport protocol for the clients of 802.11 networks [15]. Hence, the
analysis and improvement of TCP performance in multihop ad hoc networks are important and valuable.
The performance of legacy TCP over multihop ad hoc networks is not satisfactory due to the special
features of wireless networks, such as hidden terminal and exposed terminal problems, transmission
errors, topology variations and routing instability, etc [16]. A lot of research has been done on TCP
performance in multihop ad hoc networks in recent yeas [16, 17, 18, 19, 20, 21, 22] by considering the
practical limitation of wireless ad hoc networks. Joint implementation of TCP and network coding has
also received attention recently [23, 24, 25]. However, as we know, the performance degradation of TCP
may be caused by the rate control mechanism of TCP itself and routing protocol [15, 26, 27], and no
research on this issue has been found until now. This is one of the main motivations of this thesis project.
Thus, in this thesis, we use network simulator NS-2 to implement COPE, and evaluate the performance of COPE in comparison with other TCP protocols adapted for wireless ad hoc network, such as
TCP-AP and TCP-FeW. Finally, if possible we try to propose a coding-aware TCP protocol, which takes
into account the influence of network coding.
The motivation of this work is the idea to find the reasons that cause the performance degradation of
TCP in wireless multihop networks, especially focus on the rate control mechanism of TCP itself. As the
previous research shows the network coding can increase the throughput of TCP. If we use the better rate
control mechanism of TCP for network coding, we can achieve the better performance of TCP.

1.2 Contributions
The contributions of the thesis consist of the following aspects.
1. COPE is an open source project which is implemented using NS-2. Then more and more researchers could research on it and make their own contributions to COPE and network coding in
wireless ad hoc networks.
2. Performance of COPE is evaluated, which proves that using COPE as a network coding approach
is reasonable. Three TCP protocols (TCP-NewReno, TCP-FeW and TCP-AP) with and without
COPE (with and without network coding) are simulated.
3. A new scheme of TCP-AP is proposed, which is a network coding aware TCP.
4. A new scheme of Encode Once is proposed to improve the performance of COPE.

1.3 Thesis Structure

The rest of the thesis is organized as follows. Chapter 2 introduces the wireless ad hoc networks, TCP
protocols, network coding and COPE. Network simulator NS-2 used in this thesis are introduced in
Chapter 3. After that, the details on the implementation of COPE on NS-2 are described in Chapter 4.
Then, Chapter 5 presents the results of simulation and evaluation, as well as the analysis and discussion
of the results in Chapter 6. Moreover, Chapter 7 gives the conclusions, and prospects improvements and
work to be done. Finally, Appendix includes Code API.

Chapter 2

Wireless Multihop Networks and

Network Coding
2.1 Wireless Ad Hoc Networks
A wireless ad hoc network is a decentralized wireless network. The network is ad hoc because it does not
rely on a preexisting infrastructure, such as routers in wired networks or access points (AP) in managed
(infrastructure) wireless networks. Instead, each node participates in routing by forwarding data for other
nodes, and so the determination of which nodes forward data is made dynamically based on the network
connectivity [39].
Figure 2.1 shows a classic wireless ad hoc network. As shown in the figure, the nodes in the network
are equipotent, and no centralized node is required. The nodes are not only ordinary mobile devices,
but also act as senders, routers and receivers in the network. When the receiver is out of the senders
transmission range, the packets have to be forwarded by middle nodes before reaching the destination.
Sometimes, they need to be forwarded several times, due to the long distance between the source and
destination, which is called Multi-Hop. This is the main difference between wireless ad hoc network and
other kinds of networks. The nodes cooperate with each other through network protocols and distributed
algorithms, and finally achieve self-organized communication. So it is also called Multi-Hop Wireless
Network, Self-Organized Network or Infrastructureless Network.

2.2 TCP in Wireless Ad Hoc Networks

The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP
is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer
communication networks, and in interconnected systems of such networks [40]. TCP is a connectionoriented protocol, provides end-to-end, reliable and ordered delivery of a stream of bytes between computers.
Due to network congestion, traffic load balancing, or other unpredictable network behavior, TCP has
to provide some specific features to detect these problems, retransmit the lost data, rearranges out-of-order
data, and even helps minimize network congestion to reduce the occurrence of the other problems [41].
Thus, TCP provides connection management, congestion control and flow control. This thesis is focused
on the congestion control, which consists of four intertwined congestion control algorithms: Slow Start,
Congestion Avoidance, Fast Retransmit, and Fast Recovery [42].

10

Tablet Computer
PDA

Smart Phone
Notebook

Figure 2.1: A Classic Wireless Ad Hoc Network

As discussed previously, the features and algorithms of TCP have been introduced in wired networks,
they work excellently over wired networks; however, as the evolution of the wireless networks and the
inherent characteristics of the wireless devices, those protocols are not suitable. The TCP protocols used
over wired networks cannot differentiate packet losses caused by congestion from link errors, so they
assume any packet loss is considered to be the result of network congestion and resolves it by decreasing
sending rate, which directly causes the dramatical reduction of the congestion window size as a precaution. However, wireless links have high probability of packet loss that is caused by transmission error,
mobility, fading, shadowing, hand off and other radio effects, all of which are not congestion. These
problems could be temporary, and the wireless devices could recover themselves later. If the congestion
control has been done before recovering, this will cause severe degradation of TCP performance. Consequently, it leads to the high frequency fluctuation in congestion window size, and the under-utilization
of the radio link. A lot of research has been done on this subject of how to conquer these problems.
There are two general ideas to cope with the problems: one is to hide error losses from the sender, the
other is to let sender know the cause of packet loss. According to these two ideas, the proposed solutions
could be classified in three categories: split-connection solutions (which require some changes in the
network without modifying end nodes, such as I-TCP [43] and M-TCP [44]), link layer solutions (such as
Snoop [45]), end-to-end solutions (which require modifications at the client or server, such as WTCP [46]

11

and TCP Westwood [47]).

As this thesis is only focused on the TCP protocol, which belongs to the end-to-end solutions. The
following sections introduce the current TCP protocol: TCP NewReno and two new protocols suggested
for wireless ad hoc networks: TCP-FeW and TCP-AP.

2.2.1 NewReno
TCP NewReno [48] is a slight modification over TCP Reno. When receiving three duplicate ACKs, TCP
Reno assumes there is packet loss happens on the link, and then start up the Fast Retransmit and Fast
Recovery process, which will immediately retransmit the lost packet. TCP Reno works very well when
the packet loss ratio is low. But TCP Reno doesnt perform well under the condition of high packet loss,
especially when there are multiple packet losses in one congestion window. Thats because TCP Reno
can only detect a single packet loss. When multiple packet losses happen, the later lost packets excluding
the first one would be retransmitted only after time-out. And time-out and retransmission would cause
TCP to go back to Slow Start stage, which results in low utilization of link and dramatically degrades
the performance of TCP.
To overcome this problem, TCP NewReno improves retransmission during the Fast Recovery stage
of TCP Reno. For every lost packet, TCP NewReno would retransmit it and wait for the acknowledgment
before exiting from Fast Recovery process. TCP NewReno successfully prevents TCP from going back
to Slow Start when there are multiple packet drops. TCP NewReno keeps the same performance at low
ratio of packet loss, and substantially outperforms TCP Reno at high ratio of packet loss.

2.2.2 TCP-FeW
As previous research [49] shows, to restrict the size of the congestion window of TCP to 1 or 2 would
lead to great improvement of the performance in wireless multihop networks. According to this research,
in 2005 K. Nahm, etc. [50] introduces the FeW (Fractional Window Increment) scheme, which prevents
the over-reaction of the on-demand routing protocol by limiting TCPs aggressiveness. TCP-FeW allows
the TCP congestion window to grow by a fractional rate 6 1 (packets) at each RTT (Round-Trip-Time).
That means adding one packet into the congestion window at every 1 / RTT.
More specific, lets assume the size of the current congestion window is W current , the source node
transmits W current packets to destination node and receives the same number of ACKs from the destination
node during each RTT. When receiving an ACK, the source node updates the current congestion window
size though the following formula (2.1):
W new = W current +

W current

(2.1)

where 0 < 6 1. When = 1, the pattern of increase of the formula above is the same as the traditional
style, increasing window size when receiving an ACK. So TCP-FeW keeps the original mechanism of
TCP congestion window growth. In addition to that, TCP-FeW can monitor the network traffic without
any other additional information and provide quick reactions.

2.2.3 TCP-AP
In multihop wireless networks, the main reason of packet drops is at the link layer rather than buffer
overflow, which is opposed to the wired network. Furthermore, the congestion control of TCP NewReno
purely depends on packet loss, the size of congestion window has been decreased when the packet drops
happen rather than proactively detect the trend of congestion by monitoring the network traffic. Thats
why TCP NewReno performs quite poorly in multihop wireless networks, as well as severe unfairness
among competing TCP flows.
12

In 2005, S. M. EIRakabawy, etc. [51] proposes a new congestion control algorithm for TCP over
multihop IEEE 802.11 wireless networks called TCP-AP (TCP with Adaptive Pacing). TCP-AP is a
rate-based scheduling of transmissions within the TCP congestion window. The source node adapts
its transmission rate according to the estimation of the current 4-hop propagation delay and coefficient
of variation of recently measured RTTs. Unlike the previous solutions, TCP-AP keeps the end-to-end
semantics of TCP, does not need to modify the routing or link layer, and does not rely on the cross-layer
information from intermediate nodes along the path. Moreover, TCP-AP achieves excellent fairness and
quick reaction to control network traffic conditions.

2.3 Network Coding

Network coding is a technique, which is the integration of coding theory and information theory, gives
the ability of data processing rather than forwarding packets to combine several packets together for
transmission. This can increase the amount of information over a single transmission. Consequently, the
overall performance of the network is improved.
The core idea of network coding is to improve the utilization ratio of links by using the computing
capability of the node. To be more specific, the routers or middle nodes carry out the encoding process
and then send out the encoded packets using multicast technology, while the receivers perform the decoding process when receiving the encoded packets. The transmitting process usually requires the help
of other nodes. However, in the traditional network, the routers or the middle nodes only copy, amplify
and forward the received signals, this is kind of waste of resource. Network coding breaks down this
restriction, and it permits routers and middle nodes to process the packets they received, then send out the
encoded packets using specific algorithm.
To let you understand network coding more clearly, a simple example (Figure 2.2) is given to explain
the principle of network coding.

Node N / Router

Node N / Router

F 1( x , y , z )

F 2( x, y , z )
F 3( x , y , z )
(b) Network Coding

(a) Traditional Transmission

Figure 2.2: Principle of Network Coding

As shown in Figure 2.2, node N is a router or middle node in a wireless ad hoc network, it receives
packets x, y, z from different nodes, and then encodes and transmits them. While in the traditional network
(Figure 2.2 (a)), node N only performs the store and forward operations, so the packets forwarded are the
same as received.
Here we will investigate what will happen when using network coding (Figure 2.2 (b)). Node N
processes the packets received. After processing, the new packets come out:F1 (x, y, z), F2 (x, y, z) and
F3 (x, y, z), which are the combination of the packets received from different nodes. So the traditional
store-and-forward model could be considered as the special case of network coding. Network coding can
be implemented in different approaches, for example, Linear Network Coding [53], Random Network
Coding [54], Coding-Aware Routing (ROXC, Routing with Opportunistically Coded Exchanges) [55]
and COPE (Coding Opportunistically) [13], etc. In this thesis project, COPE is considered because it is
13

the first practical implementation of wireless network coding scheme. More details of COPE is introduced
in the following section 2.4.

2.4 COPE
COPE is a practical network coding scheme for wireless networks. It was proposed by S. Katti et.al. in
2006 [13], [14]. COPE is the first implementation of inter-session network coding in a real testbed and
shows significant performance gain. The aim of COPE is to bridge the theory of network coding with
practical application.
COPE was implemented in a real testbed with 20 laptops. COPE is implemented using the Click
Toolkit [38] in Linux and evaluated in an IEEE 802.11a network. However, the source code of COPE is
not open and it is also not easy for every interested researcher to implement a similar testbed. Therefore,
we implement COPE in the network simulator, NS-2, to evaluate its performance with different network
configurations.

1
2
3

4
As packet
Bs packet

(a) Traditional Transmission Mode

3
As packet XOR Bs packet

(b) COPE Mode

Figure 2.3: COPE Example
The key idea of COPE is making use of network coding to reduce the number of transmissions to save
14

transmission time and scare wireless resources. Several packets are sent together with network coding
to multiple nexthop nodes, which can correctly decode it. The whole process of COPE is shown in the
Figure 2.3. As shown in the figure, in COPE node C combines two packets into one (Encoding Process)
and broadcasts it, when neighbor nodes A and B receive this broadcast encoded packet, they would try
to get the original packet through the packets they have already hold (Decoding Process). While the
traditional transmission mode would require two transmissions instead of one broadcast. Compared to
the traditional transmission mode, we can see that the total times of transmission with COPE is three,
rather than the four times of traditional transmission mode.
COPE includes three parts: (i) Opportunistic Listening; (ii) Opportunistic Coding; (iii) Reception
Reports.

2.4.1 Opportunistic Listening

Opportunistic listening is to increase opportunities of network coding. All nodes listen to the wireless
channel all the time and receive all packets and try to decode them whether the packets are intended to
them or not.

2.4.2 Opportunistic Coding

Opportunistic coding is the method of finding the packets to encode. Network coding happens among
neighboring nodes, which have redundancy information to decode the coded packet. When a node gets
the wireless channel, it needs to choose packets for coding from local buffers. Since there may exist many
choices of network coding, COPE builds up several rules for coding packet selection.
Coding native packets only.
Coding as more packets as possible to maximize the gain of network coding.
The total decoding probability of all nexthop nodes is larger than a threshold G (By default, G =
0.8).
Never delaying packets. The packet at the head of the output queue has to be included in the
transmission.
Never coding packets to the same nexthop.

2.4.3 Reception Report

The transmitting node selects coding packets according to what packets the nexthop nodes have. There
are two ways through which the transmitting node obtains information about packets in nexthop nodes.
One is reception report, in which both piggyback report and periodical report are employed.
The other is guessing, which guesses the probability of overhearing the packet at the nexthop nodes
leveraging routing protocols.

15

Chapter 3

Network Simulator: NS-2

NS-2, stands for Network Simulator version 2 (and NS for the first generation) and is a discrete event
simulator targeted at networking research. NS-2 provides substantial support for simulation of TCP,
routing, and multicast protocols over wired and wireless (local and satellite) networks [52]. NS-2 includes
almost all the main parts of network, and it is a free and open-source platform for network simulation.
Thats why NS-2 is used widely in academic fields, and chosen here in this thesis work for the simulation
of TCP with network coding and the evaluation of its performance.
The core of the wireless module in NS-2 is mobile node, which was originally ported as CMUs
(Carnegie Mellon University) Monarch groups mobility extension to NS [52]. It is a basic node object
equipped with wireless functionalities, and the mobile node can move within the given topology, receive
and send radio signals through wireless channel. The characteristics of mobility like node movement, periodic location update, topology maintenance, etc., are implemented by C++, while the internal network
components (like classifier, Link Layer (LL), Media Access Control (MAC), Channel, etc.) are assembled using OTcl, which is an object oriented extension of the scripting language Tcl (Tool Command
Language).
The users may use command: node-config to configure the mobile node, there are several options:
ad-hoc routing protocol, link layer, MAC layer, channel, etc. The node-config commands look like the
following:
$ns_ node-config -addressType hierarchical
-adhocRouting AODV
-llType LL
-macType Mac /802 _11
-ifqType Queue/ DropTail / PriQueue
-ifqLen 50
-antType Antenna / OmniAntenna
-propType Propagation / TwoRayGround
-phyType Phy / WirelessPhy
-topologyInstance $topo
-channel Channel / WirelessChannel
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF

The structure of a mobile node in NS-2 is shown in Figure 3.1. It consists of Agent/Sink, Link Layer,
16

Sink

Agent
target_

uptarget_

LL
downtarget_

IFq

uptarget_

mac_
downtarget_

MAC
downtarget_

uptarget_

NetIF
uptarget_

channel_

Channel
Figure 3.1: Structure of mobile node in NS-2
Interface Queue, MAC Layer, Network Interfaces and Channel. Each of the main components is briefly
described here.
Agent
Agent represents endpoint where network layer packets are constructed, and is used in the implementation of protocols, such as TCP and UDP (User Datagram Protocol) protocols. Any node in
NS-2 as a source of data flow needs to attach a specific Agent to generate packets.
Sink
Sink, as the opposite of Agent, is the consumer of the network layer packets. The node acts as a
receiver needs to attach a specific Sink to receive packets.
LL (Link Layer)
Link Layer connects to a ARP (Address Resolution Protocol) module, which is used to resolve the
MAC address using IP address. All the packets sent out by Agent will be transferred to Link Layer,
and then Link Layer puts them into the IFq. For the packets received, MAC transfers them to Link
Layer, and then Link Layer would pass them to its up target Sink.
IFq (Interface Queue)
There are two kinds of Interface Queue. When the routing protocol is DSR (Dynamic Source
Routing), a special queue called CMUPriQueue would be used, because different kinds of packets
would be assigned different priorities using DSR. Otherwise, another queue called PriQueue, which
17

pushes the packets at the head of the queue, will be used. The encoding and decoding operations
are implemented on this layer.
MAC (Media Access Control)
MAC layer is implemented as DCF (Distributed Coordination Function) MAC protocol in IEEE
802.11. There is a Tap Agent (Tap Agent is application level process on NS-2 node that converts
network packets between the simulated and the real network.) could be registered itself with the
MAC object using method installTap(). As the requirements of the network coding, the Tap Agent
will promiscuously snoop all the packets received by MAC layer, before address filtering is done,
and pass them up to the specific layer IFq.
NetIF (Network Interfaces)
NetIF layer in NS-2 acts as the hardware interface used by mobile node to access the channel
and simulates signal integrity, collision, transmission error, etc. The Radio Propagation Model
(Radio Propagation Model exists in physical layer of each mobile node and is used to predict
the received signal power of each packet.) has been integrated into NetIF layer. NetIF marks
each transmitted packet with transmission power, wavelength, etc. and decides whether coming
packet can be received by the mobile node with given distance, transmit power and wavelength. In
addition to that, Omni Directional Antenna module, which has unity gain for all direction, has been
implemented into this layer too.
Channel
Channel simulates the practical transmission of the packet at the physical layer. Contention mechanisms have been realized on Channel, which allows the MAC layer to carry out contention, carrier
sense and collision detection. If more than one transmissions happens at the same time, Channel
mark the collision flag. By checking this flag, MAC layer could be aware of this collision and
handle it.
COPE will be implemented on IFq layer. So we should make a few slight modifications to the original
structure of the mobile node in NS-2. For opportunistic listening, the up target of MAC is no longer LL,
because the COPE is implemented on IFq layer and all the incoming packets should pass through COPE.
If the destination or next hop of incoming packet is this node, then pass this packet to LL, which now is
the up target of IFq. Otherwise, COPE saves it in the packet pool for a while or drop it directly depending
on the packet is decodable or not. The new structure of the mobile node with COPE looks like Figure 3.2.

18

Sink

Agent
target_

uptarget_

LL
downtarget_

uptarget_

COPE

IFq

mac_
downtarget_

uptarget_

MAC
downtarget_

uptarget_

NetIF
uptarget_

channel_

Channel
Figure 3.2: Structure of mobile node with COPE in NS-2

19

Chapter 4

Implementation of COPE on NS-2

Three key parts of COPE as well as complementary parts for IEEE 802.11 network, pseudo-broadcast,
asynchronous acknowledgment and retransmission, are to be implemented. IEEE 802.11 MAC and the
IFq protocol stacks on NS-2 will be modified to adapt to the present application, and network coding is
mainly done in IFq. For the implementation, lots of programming work is needed. This will be explained
in this chapter.

4.1 Opportunistic Listening

Since wireless is a broadcast medium, COPE sets nodes to overhear packets from all the neighbor nodes,
and store them for a limited period T (the default in our implementation is T = 1.0s). In addition, each
node broadcasts reception report to tell its neighbors which packets it has stored. Reception reports are
sent by piggybacking the data packets the node sends out. If there are no data packets to send, the special
control packets contain reception reports will be sent periodically.
In current NS-2, the received packet will be dropped if the received signal strength is less than a
certain threshold or the node is not the intended receiver of the packet, while we have to keep all packets
received for network coding later on.
Thus, we need to modify the packet receiving mechanism in MAC layer. All packets now are transferred up to the input queue. If the node is the intended receiver, the packet will be transferred up to
routing layer or transport layer by IFq. Otherwise, the packet will be kept in a new backup queue.

4.2 Opportunistic Coding

In current NS-2, if the MAC layer has a packet to transmit, it needs to contend for the channel. After the
packet has been transmitted, the MAC layer will refetch a new packet from COPE(IFq), then that packet
will be transferred to MAC layer. Hence, there is only loose coupling between these two layers in the
current NS-2.
With network coding, COPE, when the MAC layer catches the channel, it needs to inform the IFq to
do opportunistic network coding. We can implement it in the following way. First, the IFq transfers the
packet as in legacy NS-2; Then, when the MAC layer catches the channel, it informs IFq; Third, the IFq
looks for coding opportunity and sends a newly organized packet to MAC layer.
As to how to find packets to do network coding, we can implement it as in COPE. We maintain two
virtual queues, one for long packets, and the other for short ones. The node maintains two queues for

20

each neighbor, and both of these queues are implemented with linked list (list, one of the C++ STL
Containers).
The most tricky rule of opportunistic network coding is to guarantee the probability of decoding,
which depends on guessing. In COPE implemented in the testbed, the probability of overhearing leverages the routing protocol. However, we are going to implement it in a different and simpler way. The
overhearing probability of calculated by smoothing historical records. Assuming the probabilities in the
last and current report periods are pl and and pc , respectively, we can calculate the updated overhearing
probability as follows
pu = (1 ) pl +

t
t
pc + (1 t
) pl
( Tt + 1) T
( T + 1) T

(4.1)

where is the moving weight, t is the time between last and current reports and T is the reference period.
With this method, we will not need any help from the routing layer and generalize the application area
of COPE.

4.3 Reception Report

Reception report include two parts, namely, piggyback report and periodical report.
Piggyback report can be done after opportunistic coding in IFq by appending the report to the packet.
Periodical report can be done by setting a timer in IFq. When the MAC layer is idle for transmission
and there is no new packet in the queue in IFq, the timer is started. The timer will be reset by new packet
arrival or periodical report. The timeout will trigger a periodical report if there are newly received packet.
This is what proposed in COPE.

4.4 Pseudo Broadcast

Pseudo-broadcast is to select one of the intended receivers in the coded packet as the receiver returning
ACK. How to select the one is not clear in COPE. Here, we can select the receiver of the oldest packet as
the receiver returning ACK.

4.5 Asynchronous ACK and Retransmission

Asynchronous acknowledgment is done in IFq after reception report is fixed. To do this, we need a record
of decoded packets without acknowledgment.
When a node receives a negative acknowledgment (NACK), it will put the packet at the head of the
queue and retransmit it again.
In NS-2, the maximum number of retransmissions is controlled at the MAC layer, since a packet is retransmitted immediately after receiving NACK. With COPE, the situation is complicated, the transmitted
packet is saved in a queue now and the retransmission maybe after other packets have been transmitted.
Thus, we have to record the number of retransmissions of each packet in the queue.

4.6 Packet Reception

If a node receives a packet, it will transfers it to IFq, and IFq decodes it if possible. Otherwise, the coded
packet will be dropped by IFq directly.

21

4.7 Definition of Packet Header

The header of COPE is defined similar to the structure the paper provides, except the first block (packets
XOR-ed together), which lists information of packets coded together. In COPE, asynchronous acknowledgment is realized with local sequence number defined and exchanged between neighboring nodes.
However, it is not described clearly how the local packet sequence number is sent to the neighboring
node. Thus, in our implementation, we assign each native packet a local packet sequence number at the
sender (defined as Local PKT SEQ NUM) and include it in the first block of COPE header in the packet.
The structure of the packet header looks like Figure 4.1.
For each native packet in the encoded packet, the header lists its ID (PKT ID), which is a 32-bit hash
of the packets source IP address and IP sequence number. This IP sequence number means the number
of native packets, including native packets both directly sent and the ones encoded, sent from this node.

ENCODED_NUM
Packets
XOR-ed
together

PKT_ID

NEXTHOP

LOCAL_PKT_
SEQ_NUM

MAC Header
REPORT_NUM
COPE Header
Reception
Report

SRC_ID

LAST_PKT

Bit Map
Routing Header
(Optional; depends on protocol)
IP Header

ACK_NUM
ACK
Block

NEIGHBOR

LAST_ACK

Ack Map

Figure 4.1: COPE Packet Header

Note that IP sequence number is totally different from the local sequence number. IP sequence number is defined by the source node of a flow (the number of native packets sends from this node to one
node or several nodes), but the local sequence number Local PKT SEQ NUM is defined by the last hop
transmitter (the number of native packets sends to one specific neighbor).

4.8 Definition of COPE

We realize main functions of COPE in the interface queue (IFq) in NS-2. We define a main IFq proxy,
named as COPE (refer to Figure 4.2), which works as a IFq entry and interacts with LL and MAC, and
contains main logical algorithms for both encoding and decoding process. With all queues and timers
encapsulated inside, COPE instance is created for each node by tcl/tk. Once COPE receives a packet
from LL(its upper layer), it will transfer the packet to the real IFq(COPEPriQueue) to encode the native
packet, while if the packet is received from MAC layer, COPE will first decide whether the packet is
coded or not. If the packet is a coded one, COPE decodes it first and then sends it to the COPEPriQueue.
22

Otherwise, the packet is sent to COPEPriQueue directly. This is because our one-queue dual-access
design for COPEPriQueue, refer to COPEPriQueue description in section 4.9 for detail.

Figure 4.2: COPE Structure

4.9 Definition of Queues

Each node maintains several queues, including one NonAckQueue, one AckPendQueue, one PacketPool,
one PacketInfo and one ProbGuess.

4.9.1 COPEPriQueue
COPEPriQueue is the real IFq which is a multiple inheritance from CMUPriQueue and PriQueue as
showed in the following class graph (Figure 4.3). Although NS-2 uses different IFq for different routing
protocols (e.g., AODV and DSR), here we just integrate both of them together and overwrite some of their
functions. In current version of COPE in NS-2, we only consider two mostly widely used routing protocols, AODV and DSR (due to the time reasons, only DSR is implemented), and other routing protocols
can also be included into this implementing framework easily.
As you see in Figure 4.3, both queues inherit from a common class Connector which will result in
an ambiguous function call, so we need to indicate a specific path while using Connectors members or
functions.
Another problem is that we design the IFq much more like a BiConnector rather than just a Connector,
because all packets sent up from MAC layer have to go through COPE prior to LL, so that the incoming
packet can be decoded by COPE firstly and the packet sent up to LL is native. Since the decoded native
packets by COPE are sent up immediately without any need to store them in an UP queue, we simulate
the BiConnector by adding a uptarget member into COPE to simplify this class inheritance system. In
contrast, only one COPEPriQueue is implemented for all DOWN packets, Thus the COPEPriQueue
here is called one-queue dual-access design for IFq.

23

Figure 4.3: Class Graph for COPEPriQueue

4.9.2 NonAckQueue
In order to realize retransmission of packets sent out in a coded way, we use NonAckQueue to store all
native packets, which are sent out using network coding from this node, but have not been acknowledged.
In other words, the uncodable packets (control packets and non-encoded packets) would not be put into
NonAckQueue.
typedef struct {
u_int16_t local_seqnum ; // local sequence number of Non - Acked pkt
u_int8_t rcounter ; // counter for times of retransmission
Packet * ppkt ; // pointer to packet
} non_ack_entry_t ;
typedef struct {
int nodeid ; // next hop

24

list < non_ack_entry_t >* entries ;

} non_ack_t ;

Whenever OutputQueue sends out a native packet, which is included in an encoded packet, this native
packet is put into the NonAckQueue. At the same time, COPE starts a timer for this native packet. The
duration of this timer slightly longer than the Round Trip Time (RTT). We call this timer NonAckTimer,
which inherits from CopeTimer. If the acknowledgment of this native packet comes back before the timer
expires, the COPE stops this timer and delete this native packet from NonAckQueue. Otherwise, this
native packet will be retransmitted, by putting it at the head of OutputQueue. And immediately, set a new
timer for this native packet and increase the retransmission counter by one. When OutputQueue sends it
out, it checks the counter, if counter == 2 (retransmission threshold is 2 by default), then stop its timer
and drop this packet.

4.9.3 AckPendQueue
Each node maintains an AckPendQueue for each neighboring node, each saves the pending ACK information related to the corresponding neighbor. AckPendQueue is implemented as a linked list, whose
nodes structure looks like this:
# define ACKMAP_TOTAL_SIZE

256

typedef struct {
int neighbor ; //MAC address of the neighbor
u_int16_t lastack ; // last ack sequence number
u_int16_t shifts ; // number of bits shifted
bitset < ACKMAP_TOTAL_SIZE > ackmap ;
} ack_pend_t ;

4.9.4 PacketPool
PacketPool (Packet Pool), keeps a copy of all native packets it has received or sent out. To clear expired
packets in the Packet Pool, garbage collection is conducted every few seconds. The structure of the PacketPool consists of one hash table, one first-in-first-out (FIFO) queue (backup queue), and one reception
report list.
Hash Table
hash_map <int , Packet *> pkt_table_ ;

We use a hash table to store native data packets keyed on packet id. The buckets of the hash table is
the pointer of the packet corresponding to this packet id. Its easy for COPE to do decoding when
receiving an encoded packet, because COPE could quickly get the corresponding packet through
its id.
Backup Queue To store packet pointers with FIFO strategy using the linked list. The purpose of
this backup queue is to assist the process of garbage collection.

25

typedef struct {
double time ;
Packet * ppkt ;
} pkt_entry_t ;
list < pkt_entry_t > backup_queue_ ;

Reception Report List To record which packets have been received from which neighbor, and also
which packets would be expired in the coming period, and be delete from Packet Pool during the
garbage collection process. This list is also the source of periodic reception reports.
# define BITMAP_TOTAL_SIZE 256
# define BITMAP_SIZE 8
typedef struct {
nsaddr_t srcip ; // source ip
u_int16_t lastpkt ; // ip sequence number
u_int16_t shifts ; // number of bits shifted
bitset < BITMAP_TOTAL_SIZE > bitmap ; // bit -map of recently heard
packets
u_int16_t max ;
} report_t ;
list <report_t > report_list_ ;

In Pool
When one native packet has been received or sent out, it is put into the PacketPool. The procedure of
doing that looks like this:
Firstly, check whether this packet has been in the pool or not. If it is, then the packet ignored. In
addition, check whether this packet has been garbage collected before. If so, then ignore it too.
Secondly, push this packet into the backup queue.
Thirdly, add this packets information into the hash table.
Finally, update the reception report list according to this packet.
Get Reception Report
There are also two situations need to get reports, just like getting ACKs from AckPendQueue. Firstly,
when the node has data packet to send out, it checks whether there is any reception report to transmit, if
so, it appends them to the COPE header. Secondly, when there is no data packet to send out, then periodic
report is broadcasted as a special control packet, which contains the reception reports.

26

Garbage Collection
Without appropriate approach to clear the out-of-date packets in the pool, the pool will soon overflow.
Thats why the garbage collection is used. The garbage collection is executed by COPE every few seconds.

4.9.5 PacketInfo
Each node keeps a hash set, packet info, that is keyed on packet id. For each packet in the output queue,
the table indicates whether each neighbor has that packet or not.
Using the gnu hash set as the hash set implementation, where gnu hash set is an easy-to-use hash
set, but hasnt been included into the C++ standard library. If our implementation of COPE would be
compiled on other platform, there may be some compiling problems. To fix this problems, you should
change the including path of hash set to the specific platform required.
As said before, the hash table should keyed on packet id, however, to get faster access speed and better
performance, the structure key (info key t, as showed bellow) is used rather than the packet id.
# include <ext / hash_set >
using namespace __gnu_cxx ;
typedef struct {
int nodeid ;
hash_set <int > pkt_ids ;
} pkt_info_t ;

Thats because if the hash set is keyed on packet id, when checking whether a packet is in the set or
not, true indicates the neighbor has that packet, false means not. When the sender wants to do encoding
process and gets one neighbors probability of having that packet, it has to search the whole list for each
packet, which wastes time and resources. If the packet id is used as key, the probability of each neighbor
having that packet is one entry of the hash set. That means the sender can get each neighbors probability
with high speed, which is the main advantage of hash set over other data structures.

4.9.6 ProbGuess
General Ideas
After searching for the packet info, if the node is still not sure whether its next hop has a specific
packet or not, a probability guessing mechanism should be utilized.
The guessed probability is only used at the the encoding-needed node(subset of intermediate nodes),
as a prob demander, the node will maintain an instance of ProbGuess to update probs after packet info
is updated and fetch a specific prob from. To explain how probability guessing works and whats the
implementation idea, we can consider a simple network scenario firstly as shown in Figure 4.4:
In the above simple topology, its obvious that A and C are source nodes with data flow A-B-E-F
and C-B-E-F separately, both B and E probably encode a native packet. Assume that A has sent out
packets with sequence number 1, 2, 3 and C, E have received all these packets and kept them in the
COPEPriQueue, then we can compute the new probability at E by this way:
E maintains a table for each source ip and the entry of each table is keyed by all its neighbor nodes,
at a certain time point, E receives a reception report and update the table into the following status(see
Figure 4.5, with V:exist, X:non-exist ) according to several important rules:

27

Figure 4.4: Butterfly Topology

Figure 4.5: Neighbors Packet Status

1. For each source ip, only update status of the packets from the smallest sequence number to the
largest sequence number defined by packets in the COPEPriQueue (A1 to A3, C1 to C3 in the
example).
2. For the host node, status of all packets in my COPEPriQueue should be V, since I have them
all.(A1 to A3, C1 to C3 in the example)
3. If a neighbor is the source node or previous hop, it definitely has that packet (node A and B has A1,
A2, A3 for sure in the example).
4. If a neighbor has sent a valid reception report, the host node knows that whether the neighbor has
a specific packet or not, thus the corresponding status should also be updated (Ds reception report
said that he has A1, A3 but A2 in the example).
5. If a neighbor is the destination, it shouldnt has this packet (Fs status for A1, A2, A3 is X in the
example).
6. Otherwise, status should be X by default.
Thus, we can easily calculate a probability p c for each source ip (p c(D,A) = 2/3, p c(F,C) = 1/3), which
means node D has any packet originated from source A with probability equal to 2/3. p c(F,C) can also

28

be calculated similarly. As you may note, instead of evaluating each packets probability, we just evaluate
the probability of a set of packets sourced by a specific node.
Until now, we skip a fact that the probability is updated continuously, to increase the accuracy of
the guessed probability, we should consider historical records as a factor and design an algorithm to
compute probability accumulatively, so a formula(as mentioned above, in Implementation of COPE in
NS-2/Opportunistic Coding) based on Moving Weighted Average Method which also regards updating
time period as a coefficient.
Lets elaborate the network scenario described before. Assuming that at node E, node Ds last reception report arrived at T 0 while the current report time is T 1 , and node Ds last probability for source A is
p l(D,A), then the guessed probability is updated as
pu [D, A] = pl [D, A] +

T1 T0
pc [D, A]
T

(4.2)

where T is the periodical report duration, alpha is an adjusting factor.

Throughout the above description, if the calculated probability is smaller than G(0.8 here), we judge
the packet is impossible to be decoded in this neighbor.
Implementation Details
Firstly, to record all probability information, a map is constructed with a self-defined key. An updating
operation will result in the modification of one entry in this prob info table and the node will get a desired
probability from here too.
Second, since packets set in COPEPriQueue is changeable all the time, every time a new reception
report is received, the node should modify a consistent start and end sequence number for each source
ip, then count the total number of packets (e.g. 3 from source A in the scenario). At the same time, also
count the number of packets in a certain neighbors reception report(e.g. 2 for node D from source A in
the scenario), thus we can derive a current probability. A new structure can be used as an assistant for this
process, and a list of instances of this structure are created in the runtime.
typedef struct {
nsaddr_t src_ip ;
uint16_t start_seq_num ;
uint16_t end_seq_num ;
int pkt_count ;
} src_info_t ;

Third, to record the historical updating time for each neighbor, a simple struct is designed and similarly create a list of instances according to different neighbor node.
typedef struct {
int nodeid ;
double last_report_time ;
} nb_info_t ;

Fourth, two iterfaces are provided. one is to update prob info table after updating packet info, which
means a reception report received. This function will execute the following works:
1. update the src list information according to the large and small virtual queue, since the source nodes
are determined while initialization, no need to change(insert/delete) the list elements dynamically.
29

2. update nb ids nb info t, if it exists, delet add a new nb info t to the list, now one little problem
still exists that nothing to do if a node is no longer its neighbor.
3. get the new pkt info, and compute a new prob with the above strategy
4. update the new prob in prob info table, if the updated entry exists, delete it and insert a new one
5. reset the src list to a default status
Another get prob info will simply search for the hash table according to a specific source and neighbor, if no entry exists, return zero as the probability.
void up_prob_info (int nb_id ,
neighbor_list_node * neighbor list ,
VirQueue * virtual table ,
PacketInfo * pkt_info );
double get_prob_guess (int src ip , int neighbor id);

4.9.7 VirQueue
The virtual queue is used to store all packets pointer in the COPEPriQueue, sorted by the next hop and
packet type(Large/Small) pair. So a new hash table is constructed with a specific virtual key, each entry
stores a packet queue which maintains all qualified packets.
There are three main interfaces for VirQueue, the first one is inserting a packet into the virtual table
after inserting into the output queue, the related entry is specified by next hop id and packet size, if no
entry exist, creat it dynamically, the bool parameter is to decide enque head or push back; the second one
is getting a virtual packet matching the passed parameters; the third one will remove a packet from the
virtual table, if the packet queue becomes empty after removing, just naturally delete the whole entry.
void enque_vir_pkt ( Packet * p, bool rt);
PacketQueue * get_vir_pktq (int node_id , char type );
void remove_vir_pkt ( Packet * p);

4.10 Timers
Each node maintains following timers to control the packet retransmission, periodic control packets, and
reception reports, etc.

4.10.1 CopeTimer
CopeTimer is the parent class of other timers in COPE, which inherits from Handler. CopeTimer provides
some virtual member functions for child classes.

30

4.10.2 NonAckTimer
NonAckTimer is used to manage the retransmission of unacknowledged packets. A NonAckTimer is
started for each native packet in the encoded packet when sending out. If the acknowledgment comes
back before the timer expires, the packet in the NonAckQueue is remove, and the timer of this packet
is stopped. Otherwise, the timer expires. Then the retransmission process is called, by getting out that
packet from NonAckQueue and retransmitting it, increasing the retransmission counter by 1, and starting
a new timer for this packet.
Note that, to identify which timer, the neighbors ID and local sequence number in that packet have
been recorded when starting timer for it. These two variables are used to decide which timer should be
stopped when receiving ACKs.

4.10.3 CtrlPktTimer
There are some periodic control packets, reception reports and pure ACK packets in COPE, that is the
reason why this CtrlPktTimer exists. This timer is started when the OutputQueue is empty, and stopped
when the OutputQueue contains packets. When the timer expires, the control packets are sent out.

4.11 Opportunistic Listening

COPE exploits the shared nature of the wireless broadcast medium, which creates many opportunities for
nodes to overhear packets. Each node snoops on all communications over the wireless medium and store
the overheard packets for a limited period T (the default is T = 0.5s).
In addition, each node acknowledges which packets it has heard by piggybacking the data packets the
node transmits, which is called reception report in this paper. If a node has no data packets to transmit, it
periodically sends the reception reports in special control packets.
As for implementation in NS-2, inheriting from Class Tap should be a good choice, which minimizes
the changes of NS-2. There the Class Tap is left to tap out all data packets (both encoded and native)
received at this host and promiscuously snoop them for interesting tidbits. However, the problem cannot
be solved by inheriting, because there is another Agent DSRAgent inherits from Class Tap. When these
two subclasses use the same member element in super-class, which causes some problems. Considering
these situations, the solution is: add one more variant of Class Tap, which is used to handle all the COPE
related incoming packets.

4.12 Opportunistic Coding

Each node create a COPE instance which will further create a lot of assistant queues, handlers and even
timers in its init function. All encoding algorithm is implemented in COPE as mentioned before, to
elaborate how encoding process is realized, we can refer to the following sequence diagram (Figure 4.6)
which simulates a packet p received at a node:
COPE receives p with its direction DOWN(1), it will firstly set the packet id and cope sequence number to the packets header(2) if this is the source node, then call COPEPriQueues
cope prq senddown function(3).
COPEPriQueue push back p and also enque p s pionter into the virtual table(4), then put this
packet into PktPool if this is the source node(5), call COPEs encode function(7) with a dequed
packet which is from head of COPEPriQueue(6).

31

Figure 4.6: Downside Packet Received

COPE firstly get packets from virtual packet queue of all valid neighbors, then check each of them
whether p is encodable or not. To do this, it will ask PktInfo and ProbGuess in order, either of
them said yes can directly lead this packet encodable. After this, COPE will xor all candidate
packets and append them into the cope headers xor field, then return this encoded packet res pkt.
Actually, this process is much more complicated than this, so a pseudo code in the following part
may be more understandable.(8 to 14)

32

Algorithm 4.12.1: <ENCODE>(< Packet p >)

comment: Encode a native packet p
Remained NbList Neighbors Nexthop(p)
Encoded PktList p
if size o f p < PACKET S IZE T HRES HOLD
then tag S mall
else tag Large
for each get node N in Remained NbList

prob 1.0

q
head o f its tag Virtual Queue

for
each packet r in Encoded PktList

if Nextop(q) has r in local PktIn f o

then (prob prob 1.0

get the probability Pr f or r f rom ProbGuess

else
do

prob prob Pr
do

if
prob
<=
G

then exit loop

if (prob > G)

p p xor q

add
q to Encoded PktList
then

delete N f rom Remained NbList

tag =!tag
for each get node N in Remained NbList

prob 1.0

q
head o f its tag Virtual Queue

for
each packet r in Encoded PktList

if Nextop(q) has r in local PktIn f o

then (prob prob 1.0

get the probability Pr f or r f rom ProbGuess

else
do

prob prob Pr
do

if
prob
<=
G

then exit loop

if (prob > G)

p p xor q

add
q to Encoded PktList
then

delete N f rom Remained NbList

assemble p s xored header with in f omation f rom Encoded PktList

return (p)
COPEPriQueue call COPEs function to append the pend acks and reception reports into res pkts
cope header, no matter res pkt is a native packet or encoded one.(15, 18)
COPE get the pend acks from PendAckQueue(16, 17) and get the reception reports from PacketPool, the process of generating pend acks and reception reports will be seperately described in
implementation of PendAckQueue and PktPool(19, 20).
Until now, we have completely implemented an encoding algorithm, through which any packet send
down from upper(LL) layer must go. However, many other features like setting timers for packet retrans33

mission and periodical control packet etc. are not reflected in the above diagram.
Note that we are only considering a sub-optimal solution, which iterates all valid neighbors in {Neighbors}{NextHops} with a random order , we keep the optimal solution as an open function and may extend it in
our future works. For an optimal solution, we can design a set of packets as a best encoded choice prior
to others.

4.13 Decoding
In the same way, we can describe the decoding process by simulating a packet p received at a node and a
sequence diagram (Figure 4.7) is added to help us understand the whole process clearly:

Figure 4.7: Upside Packet Received

COPE calls its receivable(2) member function which will further call extract state report(3) to
update local packetInfo(4) and probGuess(5), then extract acks(6) to merely delete ack item with
neighbor == myn odei d in non ack queue(7). Receivable function will return false(non-decodable
or overheard packet) or true(native or decodable).
COPE then calls its decode function(8) to iterate each item but in xored header field, the passed
packets also include a copy of the original target packet, this is because if the packet is nondecodable, we can recover it back for some further operations. To execute decoding process, COPE
will check its local packetPool9 confirming whether a xored packet exist or not(10). If the target
packet is native or overheard, just return this function, otherwise, continue with other items in the
xored header. In the end, COPE clears all the xored header(11) if it is decodable.
No matter it is receivable or not, just put the result packet into PacketPool(12). We keep all nondecodable packets for a further decoding possibility, which is regarded as an extention for latter
works.

34

 Append an ack of the result packet into pendAcks if the received packet is decodable(13)
If the packet is receivable(native or decodable packet), update packetInfo for the native or decoded
packet(14), since it is obvious that the previous hop definitely has this packet.
Note that the whole decoding process has no relation with COPEPriQueue and VirQueue, because
once receiving a new packet with UP, COPE just deal with it directly rather than enqueue that packet.

4.14 Reception Report

The node knows what packets its neighbors have through reception report. Each node announces to its
neighbors the packets it stores in the Packet Pool. When a node has data packet to be sent out, it can
append the reception report got from Packet Pool if it is available. If there is no data packets to send, the
node sends the reception report periodically.

4.15 Asynchronous ACKs

In COPE, encoded packets require all nexthops to acknowledge the receipt of the associated native packets. Since the synchronous approach to coded packets one by one is highly inefficient, encoded packets
are acknowledged asynchronously and cumulatively in COPE.
Neighbors pending ACKs are stored in the AckPendQueue. When sending out a packet, the node
tries to get pending ACKs in the AckPendQueue and append them to the COPE header. If the node has
no data packets to transmit, it sends the ACKs in periodic control packets, just like the reception report.

4.16 Control Packet

1. Allocate the COPE control packet in the cope layer, with a type tag COPE CTRL/COPE DATA as the
identifier.(for cope, all other packets are regarded as normal data packet).
2. reception Report Control packet and Acks control packet are bind together, which means once one
of them is simulated to send out, the other type of field will also be assembled.
3. No need to encode the control packet, even enque it into IFq, since it is mostly probable that there
is no packet in the queue at that time.
4. Start the control packet timer when the simulator run.
5. If a node receives a control packet, after updating packet info and ack info, this packet should be
dropped

4.17 Retransmission
There are two type of retransmission in COPE. One is retransmission of data packets, another is retransmission of asynchronous ACKs.
Data Packet Retransmission When the timer for the data packet in the NonAckQueue is expired,
which means the nexthop has not sent back the acknowledgment of that data packet. After the
expiration, the NonAckTimer handler will be called to process the data packet retransmission. And
the retransmission times are limited to 2 times, after that, the node gives up and drops that packet.
So the COPE does not guarantee the reliability at link layer.

35

 Asynchronous ACKs Retransmission This is the counterpart of data packet retransmission. When
the nexthop gets a duplicate data packet, which means the previous data packet lost, so the nexthop
gets the pending ACKs from AckPendQueue, appends them to another data packet, and sends it
out. The retransmission times for data packet are limited to 2, so the retransmission times for
asynchronous ACKs should be limited (2 by default), otherwise the nexthop will wait for that lost
packet forever.

4.18 Resume a packet

After completing a packet transmission, MAC will callback the passed handlers function to resume another packet from IFq. Since COPE is a multiple inheritance from several queues, we define a new class,
COPEHandler, as the common handler to handle the resume event. When resume is called, COPEHandler calls COPEPriQueues cope prq resume function which encapsulates both queues resume operation.

4.19 TCP Reordering

In COPE, there is an ordering agent, which ensures that TCP packets are delivered in order. The agent
maintains a packet buffer and records the last TCP sequence number passed on to up layer. If the incoming
packets that do not produce a hole in the TCP sequence stream are immediately dispatched to the transport
layer, and update the state of sequence number in ordering agent. Otherwise, they are withheld in the
buffer till the gap in the sequence stream is fulled, or until a timer expires. In NS-2, this ordering agent is
implemented as copeTcpSink, which is a subclass of TcpSink class.

36

Chapter 5

Simulation and Performance

In this chapter, we evaluate the performance of TCP with COPE in different topologies using different
TCP protocols: TCP-Newreno, TCP-FeW and TCP-AP. We compare it to TCP over the baseline schemes
(without COPE, no network coding).

5.1 Simulation Setup

We used NS-2 simulator (version 2.34), which is well suited for studying and research of wireless network, as the platform of evaluation. We considered various topologies: the most simple chain topology,
shown in Figure 5.1; the classic X topology (we call it X-I topology, Figure 5.3) and X-II topology (Figure 5.5) which is the extended and enhanced version of X-I topology. All of these topologies are easy
to analyze and clearly show the interactions between network coding and TCP. In the MAC layer, we
simulated IEEE 802.11 with RTS/CTS (Request to Send/Clear to Send) enabled. For TCP traffic, FTP
(File Transfer Protocol, is a standard network protocol used to copy a file from one host to another over a
TCP-base network) traffic has been used on top of the wireless network. In all the topologies, TCP flows
start randomly between first 2sec and 3sec until the end of the simulation.

5.2 Performance Metrics

Our evaluation uses the following metrics.
Network Throughput: the measured total end-to-end throughput. The average throughput of all
flows in the network is computed as:
throughput =

received packets size 8

(kbps)
simulation time

(5.1)

Throughput Gain: the ratio of the measured network throughputs with and without COPE[13].
Throughput gain is defined as:
throughput gain =

throughputCOPE
throughputNoCOPE

(5.2)

where throughputCOPE and throughputNoCOPE are average TCP throughput when network coding
is turned on and off respectively.

37

5.3 Simulation Results

5.3.1 Chain Topology

m-1

200m
Figure 5.1: Chain Topology
The chain topology used in this thesis as shown in Figure5.1. In the chain topology, the distance of the
contiguous nodes is 200 meters, while the transmission range of each node is 250 meters, so each node
(except the first one and the last one) can only directly communicate with its two neighbor nodes around
itself. The first node n1 and the last node nm send TCP data to each other, while they have to transmit
data through the nodes between them. So the intermediate nodes would have opportunities to do network
coding. According to the formula of the network coding gain over chain topology [13]:
coding gain =

2N
N+1

(5.3)

where N is the number of hops in chain topology. When the number of hops N trends to infinity, the
theoretical gain should be 2.
We evaluated the three TCP protocols with and without COPE separately over the chain topology from
4 hops to 15 hops. As shown in Figure 5.2, the network throughput of TCP with COPE is much higher
than the one without COPE, which proves the benefits of network coding. However, there isnt any TCP
protocol that is absolutely the best one in all cases. We can see from Figure 5.2 that TCP-NewReno is the
worst choice for network coding. While TCP-AP with COPE is much better than TCP-FeW with COPE
when the number of hops is less than 11, after that, TCP-FeW with COPE achieves higher throughput.
And regardless of which TCP protocol is used, the throughput gain of this topology is less than the
theoretical coding gain 2 as shown in formula 5.3.

5.3.2 X-I Topology

The chain topology has shown that two flows traversing the reverse path of each other, the intermediate
nodes have opportunities to do network coding, and the evaluation result shows that COPE brings great
increase to network throughput. However, in the real wireless network, there might be only a small
number of this kind of topology, but one would expect many flows to intersect at a relay, and thus can be
coded together using opportunistic listening and guessing probability. To achieve this goal, we use X-I
topology (Figure 5.3) as the scenario to evaluate the overhearing function of COPE.
There isnt any gain without COPE on this topology, with 4 transmissions. But with opportunistic
listening and guessing, the middle node can code packets together and transmit the coded packet, with
only 3 transmissions. So the coding gain is 4/3 = 1.33.
Figure 5.4 shows the simulation results over X-I topology. We can see from Figure 5.4 that both
TCP-NewReno and TCP-FeW with COPE have got a little improvement of TCP performance 3% and
8%, even though the coding gain is only 1.03 and 1.08 respectively, which is not as high as the theoretical value 1.33. But they are still better than TCP-AP with COPE, which has no contribution to the
TCP performance. The reasons why TCP-AP with COPE has no throughput improvement might be the
38

300
TCPNewReno
TCPNewReno with COPE
TCPFeW
TCPFeW with COPE
TCPAP
TCPAP with COPE

Goodput (Kbit/s)

250

200

150

100

50
4

10

11

Number of Hops

12

13

14

15

Figure 5.2: Throughput in Chain Topology

following two ones. One reason is TCP-AP is based on the estimation of the current 4-hop propagation
delay and coefficient of variation of recently measured RTTs. However, this topology only has 2 hops,
which might restricts the performance of TCP-AP. The other is the rate control mechanism of TCP-AP
causes the output queue in COPE states hungry most of the time. That means TCP-AP is too proactive for
congestion control, so that there is only a few of packets in the output queue can be used to do network
coding.

5.3.3 X-II Topology

To evaluate the performance of COPE and find out the reason leads to no gain when using TCP-AP, we
extended the X-I topology to X-II topology (shown in Figure 5.5). It is similar to X-I topology except it
has four more nodes, so each TCP flow has 4 hops now, which satisfies the prerequisite of TCP-AP.
Without COPE, 16 transmissions are needed for all the flows to send one packet to the destination
node. However, if opportunistic listening and coding are permitted, the intermediate nodes have a lot of
chances to do coding process. So only 11 transmissions are necessary, the coding gain is 16/11 = 1.45.
As shown in Figure 5.6, both TCP-NewReno and TCP-FeW with COPE get worse results compared
to TCP-NewReno and TCP-FeW without COPE. Thats because TCP-NewRenos bursty behavior and to
the fact that TCP is agnostic to the underlying network coding. While TCP-FeW alleviates this bursty
situation, but still not so suitable for network coding. The same as in X-I topology, TCP-AP with COPE
still has no contribution to the TCP Performance. So we believe that this is caused by the rate control
mechanism of TCP-AP.

39

150m

200m
Figure 5.3: X-I Topology

800
Without COPE
With COPE

700

Goodput(Kbit/s)

600
500
400
300
200
100
0

TCPNewreno

TCPFeW

TCPAP

Figure 5.4: Throughput in X-I Topology

40

150m

200m

Figure 5.5: X-II Topology

300
Without COPE
With COPE

Goodput(Kbit/s)

250

200

150

100

50

TCPNewreno

TCPFeW

TCPAP

Figure 5.6: Throughput in X-II Topology

41

Chapter 6

Proposal and Evaluation

As you may note that COPE can bring some improvement to wireless networks, but not X-II topology.
And we believe that there are a lot of topologies that not suitable for network coding in the real wireless
networks, because they may be more complicated and unpredictable. However, we can firstly choose
some simple topologies, as the ones used in this thesis, to do some research.
According to the results of the simulation, we find that COPE improves the network throughput, as
well as increases the packet delay at the same time over some topologies. There would be some trade-off
to balance these two factors to achieve the best result. We proposed the following solutions to improve
the performance of COPE from the following two aspects: the mechanism of COPE and TCP protocols.

6.1 Encode Once

The main principle of coding is the receivers can decode the packet they want successfully. But there is
no guarantee that the receivers can decode successfully every encoded packet. Consequently, they will
notify sender to retransmit the decode-error packet. The sender might encode that packet again and send
it out.
During the simulation, we find that if the receiver cannot decode one packet at the first time, and then
most of the time it cannot decode it any more in spite of how many times L
that packet is retransmitted.
For example, in the X-I topology, if node n1 generates an encoded packet p1
p2 which involves native
packet p1 and p2 , then broadcasts it. Node n0 and n3 receive this packet respectively, node n0 decodes
it and get p1 . Unfortunately, node n3 cannot decode it to get packet p2 . By appending reception report,
node n3 notifies node n1 that it has not got packet p2 . Node nL
1 starts retransmission process, and encodes
native packet p2 with p3 to get another encoded packet p2
p3 and broadcasts it too. Then node n3
receives this encoded packet, but most of the time node n3 cannot decode this encoded packet involves
native packet p2 , which is the retransmission packet of COPE layer.
To overcome this problem, we modify the retransmission scheme of COPE based on the idea each
packet could only be encoded at most one time, we call it Encode Once. Specifically, COPE directly
sends out the retransmission packet as a native packet instead of encoding it again.
Figure 6.1 shows the throughput improvement of COPE with Encode Once scheme over X-I topology.
We can see from Figure 6.1 that COPE with Encode Once increases the network throughput by 5%, 4%
and 2% respectively compared to TCP-NewReno with COPE, TCP-FeW with COPE and TCP-AP with
COPE.

42

900
Without COPE
With COPE
With COPE & Encode Once

800

Goodput(Kbit/s)

700
600
500
400
300
200
100
0

TCPNewreno

TCPFeW

TCPAP

Figure 6.1: Throughput of X-I topology with Encode Once

6.2 Network Coding Aware TCP

From the study of X-I and X-II topologies, we found that when the traffic load of the network link
increases, the throughput gain of TCP-NewReno and TCP-FeW with COPE decreases, even worse than
TCP-NewReno and TCP-FeW without COPE respectively. However, TCP-AP performs stably, but still
no increase.
As we discussed in Section 2.2, TCP-AP controls the sending rate of TCP through the 4-hop propagation delay and coefficient of variation of recently measured RTTs. While TCP-FeW is based on one-hop
propagation delay, so its growth of congestion window might not so smooth as TCP-APs, especially
when the network link suffers highly congested traffic. The core idea of TCP-FeW and TCP-AP is to reduce the busty behavior of TCP-NewReno, so they both decrease the sending rate according to the RTTs
to eliminate the probability of congestion.
On the other side, COPE carries out network coding based on the packets within the output queue.
That means there should be some packets within the output queue for COPE to do network coding;
however, if the output queue is always empty or holds only one packet, there is no chance to do network
coding, consequently no improvement, like TCP-AP with COPE over X-I topology. If there are too
many packets in the output queue which might cause severe congestion, which might lead to even worse
throughput, like TCP-NewReno and TCP-FeW with COPE over X-II topology.
To solve this problem, we take TCP-AP as the baseline to make some modifications. The general
principle is adapting TCP rate based on the status of the output queue to increase the opportunity of
network coding, and then to maximize the throughput. Apparently, in X-I topology, the output queue does
not contain enough packets for encoding when using TCP-AP with COPE. To increase the number of the
packets within the output queue, we reduce the rate interval, which is the duration between successive
packet, to generate appropriate number of packets. Where the appropriate number of packets means the
number of packets is enough to let COPE do network coding on one hand, and to protect the output queue
from overflowing on other hand.
We introduced a factor for the rate interval of TCP-AP, the new rate interval is calculated as the

43

following equation.
rnew = rold

(6.1)

Where rold is the original rate interval of TCP-AP and rnew is the new rate interval used in our improvement of TCP-AP. Through various simulations and analysis, we got the experimental value of ,
when = 0.2, TCP-AP achieves the highest throughput.

700

Goodput(Kbit/s)

600
500
400
300
200
100
0

Without COPE

COPE

Encode Once

Network Coding Aware

Figure 6.2: Throughput of X-I topology with Network Coding Aware Using TCP-AP
The Figure 6.2 shows the improvement of throughput provided by network coding aware TCP-AP
with COPE. This new TCP-AP scheme brings about 12% increase of network throughput, which greatly
improves the performance of TCP-AP in COPE.
Note that, due to the time reasons of this thesis, we didnt test this new TCP-AP protocol over other
topologies. But we think that there should be a appropriate , which is suitable for TCP-AP to do network
coding in that topology.

44

Chapter 7

Conclusions and Future Work

The purpose of this chapter is to summarize the outcome of this thesis. The planned tasks have been done
and the evaluation results have been obtained using proposed scheme. After that, the problems requiring
further studies are discussed.

7.1 Conclusions
The key issue of this master thesis project, to evaluate and enhance the TCP performance over wireless
multihop networks, has been finished. We implemented COPE, which is the first practical solution for
wireless network coding, on NS-2 and evaluated it with three different TCP protocols adapted for mobile
ad hoc networks, TCP-NewReno, TCP-FeW and TCP-AP, with and without COPE respectively. We
performed several simulations over chain topology, classic X-I topology and X-II topology. The simulate
results show that both TCP-FeW and TCP-AP over chain topology could greatly improve the performance
of legacy TCP. The similar results got from the evaluation over X-I topology, except TCP-AP. There
might be two reasons. One is TCP-AP is based on the current 4-hop propagation delay and coefficient of
variation of recently measured RTTs. Another one is the rate control of TCP-AP is over proactive, which
leads to less opportunities to perform network coding. To overcome this problem and find out the reason,
I introduced X-II topology, an extended version of X-I topology, to test TCP-AP protocol. And simulation
result of X-II topology approves that the main reason is the over proactive rate control of TCP-AP.
Furthermore, to improve the current network coding gain, I proposed the following two schemes
from the following two aspects: TCP protocols and the mechanism of COPE itself. One is Encode Once
scheme for COPE, which restricts the times of encoding for each packet to one. Both schemes bring some
improvement of throughput. Another is Network Coding Aware TCP, which is a slight modification of
current TCP-AP protocol to make it less proactive and more suitable for network coding.
In the vision of wireless network coding, this thesis presents an open source solution COPE to researchers that allows every one to take part in and make some contributions. The extensive performance
evaluation of the system I provided, shows COPE largely increases network throughput.
Finally, it should be noticed that the real wireless networks are more complicated than the topologies
used in this thesis project. Thus the results might be very different.

7.2 Future Work

Although the evaluation of COPE shows that the COPE scheme could bring great improvement to wireless
ad hoc networks, it is still far away from practical applications. Many problems need to be resolved before

45

it can be applied to the real wireless networks.

COPE could increase the network throughput relays on scheme of network coding, which decreases
the number of transmissions. Thus, the key problem is how to increase the probability of coding
and decrease the probability of decoding error, especially in the complicated network scenarios, the
performance of COPE is still an open question and many related work need to be done.
There are many factors affecting the performance of COPE in the real wireless networks, such as
routing protocol, TCP protocol, and algorithm of COPE itself, etc. More research need to be done
by considering these practical facts.
When implementing COPE in NS-2 and evaluating it, we found that the biggest problem is not with
how to encode and decode, but with queue management. As introduced in Chapter 4, several queues
have been involved in both encoding and decoding process, especially the intermediate nodes, this
is one of the main factors affects the performance of COPE. When the network topology comes
to more complicated, the performance fluctuates frequently. So this is one of the subjects for the
further work, to propose a coding aware queue management scheme.
We have improved the performance of COPE by using the proposed Encode Once scheme; However, we believe that there should be some other parts need to be optimized, like the strategy of
overhearing and checking coding opportunities used in COPE right now. Memory requirements
and power consumptions are not considered in both of these strategies. The optimizations of them
are conducted by our collaborate research and will be integrated into COPE in the future.

46

Bibliography
[1] R. Ahlswede, N. Cai, S.-Y. R. Li, and R. W. Yeung, Network information flow, IEEE Trans. on
Information Theory, vol. 46, no. 4, pp. 12041216, Jul. 2000.
[2] Tracey Ho and Desmond S. Lun, Network coding: an introduction, Cambridge University Press,
Cambridge, New York, 2008.
[3] S-Y. R. Li, r. W. Yeung, and N. Cai, Linear network coding, IEEE Trans. on Information Theory,
vol. 49, no. 2, pp. 371381, Feb. 2003.
[4] T. Ho, M. Medard, and R. Koetter, A random linear network coding approach to multicast, IEEE
Trans. on Information Theory, vol. 52, no. 10, Oct. 2006.
[5] S. Zhang, S.-C. Liew, and P. P. Lam, Physical-layer network coding, in Proc. of IEEE/ACM MOBICOM, Sep. 2006.
[6] C.-C. Wang and N. B. Shroff, Pairwise intersession network coding on directed networks, To appear
in IEEE Tran. on Information Theory.
[7] S. Sengupta, S. Rayanchu, and S. Banerjee, An analysis of wireless network coding for unicast
sessions: The case for coding-aware routing, in IEEE Proc. INFOCOM, May 2007.
[8] A. Khreishah, C.-C. Wang, and N. B. Shroff, Cross-layer optimization for wireless multihop networks with pairwise intersession network coding, IEEE Journals on Selected Areas in Communications, vol. 27, pp. 606621, Jun. 2009.
[9] Y. Wu, P. A. Chou, and S.-Y. Kung, Minimum-energy multicast in mobile ad hoc networks using
network coding, IEEE Trans. on Comm., vol. 53, no. 11, pp. 19061918, Nov. 2005.
[10] D. S. Lun, N. Ratnakar, M. Medard, R. Koetter, et al, Minimum-cost multicast over coded packet
networks, IEEE Tran. on Information Theory, vol. 52, no. 6, pp. 26082623, 2006.
[11] T. Cui, L. Chen, and T. Ho, Energy efficient opportunistic network coding for wireless networks,
in INFOCOM, Phoenix, AZ, USA, Apr 2008, pp. 361365.
[12] S. Katti, S. Gollakota, and D. Katabi, Embracing wireless interference: Analog network coding,
in Proc. of SIGCOMM, Kyoto, Japan, Aug. 2007.
[13] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Medard, and J. Crowcroft, XORs in the air: Practical
wireless network coding, in Proc. SIGCOMM, Pisa, Italy, Sep. 2006.
[14] 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. 497510, Jun. 2008.

47

[15] K. Nahm, A. Helmy and C. -C. Jay Kuo, TCP over multihop 802.11 networks: Issues and performance enhancement, in Proc. ACM MobiHoc, Urbana-Champaign, IL, USA, May 2005.
[16] G. Holland and N. Vaidya, Analysis of tcp performance over mobile ad hoc networks, in Proc.
IEEE/ACM MOBICOM, Aug 1999.
[17] K. Xu, M. Gerla, L. Qi and Y. Shu, Enhancing TCP fairness in ad hoc wireless networks using
neighborhood RED, in Proc. MobiCom, San Diego, California, USA, Sep 2003.
[18] Z. Fu, X. Meng and S. Lu, How bad tcp can perform in mobile ad hoc networks, in IEEE International Symposium on Computers and Communications (ISCC02), Taormina, Italy, Jul 2002.
[19] K. Chandran, S. Raghunathan, S. Venkatesan and R. Prakash, A feedback-based scheme for improving TCP performance in ad hoc wireless networks, IEEE Pacific-Rim Conference on Multimedia, vol. 8, no. 1, Feb. 2001.
[20] H. Zhai, X. Chen and Y. Fang, Rate-based transport control for mobile ad hoc networks, in Proc.
IEEE WCNC, New Orleans, LA USA, Mar 2005.
[21] L. Ding, X. Wang, Y. Xu, and W. Zhang, Improve throughput of tcp-vegas in multihop ad hoc
networks, Elsevier Computer Communications, vol. 31, pp. 25812588, 2008.
[22] L. Ding, W. Zhang, X. Wang, L. Qian, and Y. Xu, Adaptive fractional window increment of tcp in
multihop ad hoc networks, Journals of Zhejiang University Sience A, vol. 10, no. 6, pp. 820827,
2009.
[23] L. Scalia, F. Soldo, and M. Gerla, Piggycode: a mac layer network coding scheme to improve tcp
performance over wireless networks, in Proc. GlobeCom, Washington, D.C., USA, Nov. 2007.
[24] P. Samuel David, and A. Kumar, Network coding for tcp throughput enhancement over a multi-hop
wireless network, in Proc. COMSWARE, Bangalore, Jan. 2008.
[25] J. Kumar Sundararajan, D. Shah, M. Medard, etc., Network coding meets TCP, in Proc. INFOCOM, Janeiro, Brazil, Apr. 2009.
[26] L. Ding, X. Wang, Y. Xu, W. Zhang and Y. Liu, Vegas-W: An enhanced TCP-Vegas for wireless
ad hoc networks, in Proc. ICC, Beijing, China, May 2008.
[27] S. M. EIRakabawy, A. Klemm, and C. Lindemann, TCP with adaptive pacing for multihop wireless
networks, in Proc. IEEE MobiHoc, Urbana-Champaign, IL, USA, May 2005.
[28] IEEE 802.11 WG, Part 11: Wireless lan medium access control (mac) and physical layer (phy)
specification, Standard, IEEE, Aug 1999.
[29] L. S. Brakmo, S. W. OMalley and L. L. Peterson, TCP vegas: New techniques for congestion
detection and avoidance, in Proc. ACM SIGCOMM, Oct 1994.
[30] A. Wierman, T. Osogami and Jorgen Olsen, A unified framework for modeling TCP-Vegas, TCPSACK, and TCP-Reno, in Proc. MASCOTS, Orlando, FL, USA, Oct 2003.
[31] D. Traskov, N. Ratnakar, D. S. Lun, etc., Network coding for multiple unicasts: An approach based
on linear optimization, in Proc. IEEE ISIT, Seattle, USA, Jul. 2006.
[32] T. C. Ho, Y.-H. Chan,g and K. J. Han, On constructive network coding for multiple unicasts, in
44th Allerton Conference on Communication, Control and Computing, 2006.
48

[33] T. D. Dyer and R. V. Boppana, A comparision of TCP performance over three routing protocols for
mobile ad hoc netwoks, in Proc. ACM MobiHoc, Oct 2001.
[34] S. Floyd and V. Jacobson, Random early detection gateways for congestion avoidance, IEEE/ACM
Tran. on Networking, vol. 1, no. 4, Aug 1993.
[35] H. Zhai, X. Chen and Y. Fang, Improving transport layer performance in multihop ad hoc networks
by exploiting MAC layer information, IEEE Transactions on Wireless Communications, vol. 6, no. 5,
pp. 16921701, May 2007.
[36] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang and M. Gerla, The impact of multihop wireless channel
on tcp throughput and loss, in Proc. IEEE INFOCOM, San Francisco, USA, Mar 2003.
[37] K. Chen, Y. Xue and K. Nahrstedt, On setting TCPs congestion window limit in mobile ad hoc
network, in Proc. IEEE ICC, Anchorage,Alaska, May 2003.
[38] E. Kohler, robert Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, The click modular router,
ACM Trans. Computer Systems, Aug 2000.
[39] Wikipedia, Wireless Ad Hoc Network, http://en.wikipedia.org/wiki/Wireless ad hoc network, accessed on Jan 2011.
[40] RFC 793, TRANSMISSION CONTROL PROTOCOL, http://www.faqs.org/rfcs/rfc793.html, Sep
1981.
[41] Wikipedia, Transmission Control Protocol, http://en.wikipedia.org/wiki/Transmission Control
Protocol, accessed on Jan 2011.
[42] M. Allman, V. Paxson, and M. Stevens, TCP Congestion Control, RFC 2581, Apr 1999.
[43] A. Bakre and B. R. Badrinath, I-TCP: indirect TCP for mobile hosts, in Proceedings 15th International Conference on Distributed Computing Systems (ICDCS), pp. 136-143, May 1995.
[44] K. Brown and S. Singh, M-TCP: TCP for mobile cellular networks, ACM SIGCOMM Computer
Communication Review, vol. 27, no. 5, pp. 19-42, October 1997.
[45] J. Border, M. Kojo, J. Grinder, G. Montenegro and Z. Shelby, Performance Enhancing Proxies,
INTERNET-DRAFT: http://tools.ietf.org/html/draft-ietf-pilc-pep-04, accessed on Jan 2011.
[46] P. Sinha, N. Venkitaraman, R. Sivakumar, and V. Bharghavan, WTCP: A reliable transport protocol
for wireless wide-area networks, Proceedings of ACM Mobicon99, Seattle, WA, pp. 231-241, 1999.
[47] S. Mascolo, C. Casetti, M. Gerla, M. Sanadidi, and R. Wang, TCP westwood: bandwidth estimation for enhanced transport over wireless links, ACM SIGMOBILE, pp. 287-297, 2001.
[48] S. Floyd and T. Henderson, RFC 2582: The NewReno Modification to TCPs Fast Recovery Algorithm, http://www.ietf.org/rfc/rfc2582.txt, April 1999.
[49] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang, and M. Gerla, The Impact of Multihop Wireless Channel
on TCP Throughput and Loss, in IEEE INFOCOM 03, Mar. 2003.
[50] Kitae Nahm, Ahmed Helmy, C.-C. Jay Kuo, TCP over 802.11 Multihop Networks: Issues and
Performance Enhancement, Proc. of ACM Mobihoc 2005, May 2005.
[51] S. M. EIRakabawy, A. Klemm, and C. Lindemann, TCP with Adaptive Pacing for Multihop Wireless Networks, in Proceedings of ACM MOBIHOC, pp. 288-299, May 2005.
49

[52] NS-2, http://nsnam.isi.edu/nsnam/index.php/Main Page, access on Jan 2011.

[53] S. Li, R. Yeung, and N. Cai, Linear Network Coding, in IEEE Transactions on Information Theory, Vol. 49, No. 2, pp. 371-381, 2003.
[54] T. Ho, R. Koetter, M. Medard, D. R. Karger and M. Effros, The Benefits of Coding over Routing
in a Randomized Setting, International Symposium on Information Theory (ISIT), 2003.
[55] B. Ni, N. Santhapuri, Z. Zhong and S. Nelakuditi, Routing with opportunistically coded exchanges
in wireless mesh networks, in Proc. of WIMESH 06.

50