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

IT 11 008

Examensarbete 30 hp

February 2011

Evaluation and Enhancement of

TCP with Network Coding in Wireless

Multihop Networks

Xiaolin Bai

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 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

Abstract

Evaluation and Enhancement of TCP with Network

Coding in Wireless Multihop Networks

Xiaolin Bai

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.

Examinator: Anders Jansson Ämnesgranskare: Ping Wu Handledare: Lianghui Ding

Contents

1 Introduction 8

1.1 Problem Statement and Motivation . . . 8

1.2 Contributions . . . 9

1.3 Thesis Structure . . . 9

2 Wireless Multihop Networks and Network Coding 10 2.1 Wireless Ad Hoc Networks . . . 10

2.2 TCP in Wireless Ad Hoc Networks . . . 10

2.2.1 NewReno . . . 12 2.2.2 TCP-FeW . . . 12 2.2.3 TCP-AP . . . 12 2.3 Network Coding . . . 13 2.4 COPE . . . 14 2.4.1 Opportunistic Listening . . . 15 2.4.2 Opportunistic Coding . . . 15 2.4.3 Reception Report . . . 15 3 Network Simulator: NS-2 16 4 Implementation of COPE on NS-2 20 4.1 Opportunistic Listening . . . 20 4.2 Opportunistic Coding . . . 20 4.3 Reception Report . . . 21 4.4 Pseudo Broadcast . . . 21

4.5 Asynchronous ACK and Retransmission . . . 21

4.6 Packet Reception . . . 21

4.7 Definition of Packet Header . . . 22

4.8 Definition of COPE . . . 22 4.9 Definition of Queues . . . 23 4.9.1 COPEPriQueue . . . 23 4.9.2 NonAckQueue . . . 24 4.9.3 AckPendQueue . . . 25 4.9.4 PacketPool . . . 25 4.9.5 PacketInfo . . . 27 4.9.6 ProbGuess . . . 27 4.9.7 VirQueue . . . 30 4.10 Timers . . . 30 4.10.1 CopeTimer . . . 30

4.10.2 NonAckTimer . . . 31 4.10.3 CtrlPktTimer . . . 31 4.11 Opportunistic Listening . . . 31 4.12 Opportunistic Coding . . . 31 4.13 Decoding . . . 34 4.14 Reception Report . . . 35 4.15 Asynchronous ACKs . . . 35 4.16 Control Packet . . . 35 4.17 Retransmission . . . 35 4.18 Resume a packet . . . 36 4.19 TCP Reordering . . . 36

5 Simulation and Performance 37 5.1 Simulation Setup . . . 37 5.2 Performance Metrics . . . 37 5.3 Simulation Results . . . 38 5.3.1 Chain Topology . . . 38 5.3.2 X-I Topology . . . 38 5.3.3 X-II Topology . . . 39

6 Proposal and Evaluation 42 6.1 Encode Once . . . 42

6.2 Network Coding Aware TCP . . . 43

7 Conclusions and Future Work 45 7.1 Conclusions . . . 45

7.2 Future Work . . . 45

List of Figures

2.1 A Classic Wireless Ad Hoc Network . . . 11

2.2 Principle of Network Coding . . . 13

2.3 COPE Example . . . 14

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

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

4.1 COPE Packet Header . . . 22

4.2 COPE Structure . . . 23

4.3 Class Graph for COPEPriQueue . . . 24

4.4 Butterfly Topology . . . 28

4.5 Neighbors’ Packet Status . . . 28

4.6 Downside Packet Received . . . 32

4.7 Upside Packet Received . . . 34

5.1 Chain Topology . . . 38

5.2 Throughput in Chain Topology . . . 39

5.3 X-I Topology . . . 40

5.4 Throughput in X-I Topology . . . 40

5.5 X-II Topology . . . 41

5.6 Throughput in X-II Topology . . . 41

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

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 net-work coding. In intra-session netnet-work 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 perfor-mance 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 imple-mented using XOR (Exclusive Disjunction, also called Exclusive OR) as the operation between packets

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 perfor-mance 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 re-searchers 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 sender’s 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 connection-oriented protocol, provides end-to-end, reliable and ordered delivery of a stream of bytes between com-puters.

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].

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 precau-tion. 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. Con-sequently, 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]

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 doesn’t perform well under the condition of high packet loss, especially when there are multiple packet losses in one congestion window. That’s 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 TCP’s 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 every1_/

αRTT.

More specific, let’s assume the size of the current congestion window is Wcurrent_{, the source node}

transmits Wcurrent_{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):

Wnew= Wcurrent+ α

Wcurrent (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. That’s why TCP NewReno performs quite poorly in multihop wireless networks, as well as severe unfairness among competing TCP flows.

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 de-coding 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.

(a) Traditional Transmission

Node N / Router

)

,

,

(

x

y

z

F

)

,

,

(

x

y

z

F

)

,

,

(

x

y

z

F

Node N / Router

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

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 4 2 3 A’s packet B’s packet 1 2 3

A’s packet XOR B’s packet (a) Traditional Transmission Mode

(b) COPE Mode

Figure 2.3: COPE Example

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.

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. That’s 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 CMU’s (Carnegie Mellon University) Monarch group’s 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, pe-riodic 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 assem-bled using OTcl, which is an object oriented extension of the scripting language Tcl (Tool Command Language).

The users may use command:node-configto configure the mobile node, there are several options: ad-hoc routing protocol, link layer, MAC layer, channel, etc. Thenode-configcommands 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

LL

IFq

MAC

NetIF

Channel

Agent

Sink

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 imple-mentation 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

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 mech-anisms 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.

LL

IFq

MAC

NetIF

Channel

Agent

Sink

COPE

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 trans-ferred up to the input queue. If the node is the intended receiver, the packet will be transtrans-ferred 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

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 lever-ages 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 pland and pc, respectively, we can calculate the updated overhearing

probability as follows pu= (1 − α) × pl+ α × t (_Tt + 1) × T ×pc+ α × (1 − t (_Tt + 1) × T) × pl (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 re-transmitted immediately after receiving NACK. With COPE, the situation is complicated, the re-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.

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 acknowl-edgment 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 packet’s 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

PKT_ID NEXTHOP LOCAL_PKT_ SEQ_NUM

REPORT_NUM

SRC_ID LAST_PKT Bit Map

ACK_NUM

NEIGHBOR LAST_ACK Ack Map

MAC Header COPE Header Routing Header (Optional; depends on protocol)

IP Header Reception Report ACK Block Packets XOR-ed together

Figure 4.1: COPE Packet Header

Note that IP sequence number is totally different from the local sequence number. IP sequence num-ber is defined by the source node of a flow (the numnum-ber 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(it’s 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.

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 proto-cols, 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 Connector’s 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.

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 {

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 infor-mation related to the corresponding neighbor. AckPendQueue is implemented as a linked list, whose node’s 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 Pack-etPool 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. It’s 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

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 packet’s 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.

Garbage Collection

Without appropriate approach to clear the out-of-date packets in the pool, the pool will soon overflow. That’s why the garbage collection is used. The garbage collection is executed by COPE every few sec-onds.

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 hasn’t 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 ;

That’s 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 neighbor’s 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 neighbor’s 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 what’s the implementation idea, we can consider a simple network scenario firstly as shown in Figure 4.4:

In the above simple topology, it’s 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:

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 (D’s reception report said that he has A1, A3 but A2 in the example).

5. If a neighbor is the destination, it shouldn’t has this packet (F’s 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

be calculated similarly. As you may note, instead of evaluating each packet’s 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.

Let’s elaborate the network scenario described before. Assuming that at node E, node D’s last recep-tion report arrived at T0while the current report time is T1, and node D’s 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

T ×pc[D, A] (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 neighbor’s 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 simi-larly 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.

2. update nb id’s 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 neigh-bor, 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.

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 neighbor’s 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

se-quence number to the packet’s header(2) if this is the source node, then call COPEPriQueue’s

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 COPE’s encode function(7) with a dequed packet which is from head of COPEPriQueue(6).

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 header’s 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)

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

do                                                              prob ← 1.0

q ← head o f its tag Virtual Queue for each packet r in Encoded PktList

do                         

if Nextop(q) has r in local PktIn f o then prob ← prob ∗ 1.0

else (get the probability Pr f or r f rom ProbGuess prob ← prob ∗ Pr

if prob <= G then exit loop if (prob > G) then          p ← p xor q

add q to Encoded PktList delete N f rom Remained NbList tag =!tag

for each get node N in Remained NbList

do                                                              prob ← 1.0

q ← head o f its tag Virtual Queue for each packet r in Encoded PktList

do                         

if Nextop(q) has r in local PktIn f o then prob ← prob ∗ 1.0

else (get the probability Pr f or r f rom ProbGuess prob ← prob ∗ Pr

if prob <= G then exit loop if (prob > G) then          p ← p xor q

add q to Encoded PktList delete N f rom Remained NbList

assemble p′s xored header with in f omation f rom Encoded PktList return (p)

• COPEPriQueue call COPE’s function to append the pend acks and reception reports into res pkt’s

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 Pack-etPool, 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

retrans-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 == mynodeid 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 non-decodable, 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 non-decodable packets for a further decoding possibility, which is regarded as an extention for latter works.

• 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 pack-ets. 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 retrans-mission 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.

• 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 handler’s function to resume an-other 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, COPEHan-dler calls COPEPriQueue’s cope prq resume function which encapsulates both queues’ resume

opera-tion.

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.

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 net-work, 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 (Fig-ure 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

simulation time (kbps) (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 throughputNoCOPEare average TCP throughput when network coding