Copebp Thesis

8/3/2019 Copebp Thesis

1/42

Improving Performance of Wireless Networks using

Network Coding and Back-Pressure scheduling

A Senior Honours Thesis

by

Shyam Sunder Kumar

Submitted to the Office of Honours Programs

Texas A&M University

In partial fulfilment of the requirements of the

UNIVERSITY UNDERGRADUATE

RESEARCH FELLOWS

April 2009

Major: Electrical Engineering


2/42

ABSTRACT

Improving Performance of Wireless Networks using Network Coding and

Back-Pressure scheduling

Shyam Sunder KumarDepartment of Electrical and Computer Engineering

Texas A&M University

Fellows Advisor: Dr. Alexander Sprintson

Department of Electrical and Computer Engineeringand

Graduate Mentor: Mr. Vinith Reddy

Department of Electrical and Computer Engineering

Since the seminal ideas ofnetwork codingwere first introduced by R Ahlswede et al, in

[1], there has been a lot of interest in the topic. There have been a wide variety of

discussions on the potential for the use of this idea. However, there have been few cases

of studies based on practical implementations of the idea. This lead to the proposal of

COPE as a network module to fit into existing wireless LAN modules by S. Katti et al

[5]. The practical nature of COPE has been received with relative optimism in the

research community. In our own research we tested COPE for ourselves to look for

possible enhancements. We observed from simulations that COPE had a particular scope

for improvement in finding more coding opportunities. To achieve this, we evaluated the

benefits of utilising the max-weight scheduling schemes in conjunction with COPE. This

thesis presents our implementation of this system and demonstrates that max-weight

scheduling indeed aids COPE find coding opportunities.


3/42

Table of Contents

LIST OF FIGURES

CHAPTER 1 INTRODUCTION1.1 Current Wireless Architecture and Innovations1.2 Motivation1.3 Contribution

CHAPTER 2 BACKGROUND

2.1 Network Coding2.1.1 On the Practicality of Network Coding

2.2 OPNET2.2.1 The Layers in the Node Model

2.3 COPE Architecture2.3.1 What COPE Achieves

2.4 Back-Pressure

CHAPTER 3 SYSTEM IMPLEMENTATION IN OPNET

3.1 Implementation of COPE in OPNET3.1.1 Coding Opportunities3.1.2 Shortcomings of COPE in OPNET

3.2 The Back-Pressure System Embedded in COPE3.2.1 Data Structures3.2.2 Packet Headers3.2.3 Coding Combinations

CHAPTER 4 SIMULATIONS AND ANALYSES

4.1 Discovering the Simulation Environment4.2 Cross

4.2.1 Analysing the results4.3 Chain

4.3.1 Run-1


4/42

4.3.2 Analysing Run-14.3.3 Run-24.3.4 Analysing Run-2

CHAPTER 5 CONCLUSIONS AND FUTURE WORK

APPENDIX A The Workings of XOR

APPENDIX B Packet Combination and Decoding

APPENDIX C On Opportunistic Listening

REFERENCES


5/42

List of Figures

2.1 Comparison of contemporary forwarding techniques versus network coding.

2.2 Comparison of Node Models with and without COPE

2.3 Position of COPE and Header Details2.4 Discussion on Backpressure

3.1 Backpressure: Contents of the Destination Table3.2 Backpressure: Contents of the Peer Table

4.1 - Cross Topology

4.2 Cross BP Enabled Coding Opportunities (Node Set 0-1-2)4.3 Cross BP disabled Coding Opportunities (Node Set 0-1-2)

4.4 - Cross BP Enabled Coding Opportunities (Node Set 3-1-4)

4.5 Cross - BP disabled Coding Opportunities (Node Set 3-1-4)4.6 Chain Topology

4.7 Chain BP Enabled Coding Opportunities (Node Set 0-1-2)

4.8 Chain BP disabled Coding Opportunities (Node Set 0-1-2)4.9 Chain BP Enabled Coding Opportunities (Node Set 4-0-1)

4.10 Chain BP disabled Coding Opportunities (Node Set 4-0-1)

4.11 Chain BP Enabled Coding Opportunities (Node Set 0-1-2)4.12 Chain BP disabled Coding Opportunities (Node Set 0-1-2)

4.13 Chain BP Enabled Coding Opportunities (Node Set 0-1-2)

A .1 The Truth Table for XOR

C.1 Illustrates Opportunistic Listening


6/42

CHAPTER 1

Introduction:

Wireless communication plays an important role in modern society. Individuals,

businesses, and government agencies depend on wireless networks for reliable

communication, including voice and data transmission. Due to the low cost of wireless

infrastructure, wireless networks have become very popular in the developing world, with

a special interest in rural area development. Traditionally, wireless technology has been

employed to bridge the gap between mobile users and established communication

infrastructures. Products based on the IEEE 802.11 standard connect users to local area

networks and to the Internet, while GSM and CDMA systems link mobile users to the

switched voice networks.

1.1 Current Wireless Architecture and Innovations

The 802.11 standard was developed using many wired network principles as the

basis; the main focus of the standard was to utilise air as a transmission medium.

However, this standard lacks the use of some basic features of a wireless medium that

have been demonstrated to be useful [1]. One particular feature is the broadcast nature of

such networks. Contemporary research suggests that wireless networks can be improved

using this front [1,5,7].

Another important thrust is to modify current scheduling techniques used to better

suit a wireless medium. The problem with current scheduling techniques is that it does

not effectively take care of interference that occurs when two nodes transmit

simultaneously effectively [13]. This results in loss or corruption of information.


7/42

Over the past few years, there have been some new ground-breaking research to

address some of these issues. One such example has been the advent of the theoretical

concept ofnetwork coding. Network coding focuses on combining packets together and

cleverly routeing them to satisfy multiple clients [1].

Although network coding is a promising theoretical idea, there have been few

attempts on taking this concept to practice. One practical implementation was the

proposal of a new layer called COPE [5]. Using network coding as the basis, COPE

provides opportunities to increase network throughput. COPE is indeed a promising first

step with potential for building on.

1.2 Motivation:

To study COPE, we implemented a simulation environment in OPNET. Our tests

suggested that COPE fails to smoothly interact with certain aspects of the current

wireless transmission scheduling schemes. This thesis presents our work in improving

this predicament.

To help COPE interact more fruitfully with the current set-up, we make use of the

back-pressure / max-weight scheduling scheme. The technical reasons for pursuing this

scheme is explained in later sections (sections 2.4 and 3.2). However, it is advantageous

to take a quick look at it from an overall system point of view.

Constrained by current scheduling techniques, COPE is unable to meet its goals

because of its inability to find multiple packets that need to be sent to multiple

destinations. This is a result of the fact that currently, information is sent out as and when

an opportunity is found. But for COPE to be successful, packets destined to different


8/42

places need to be collected at one point and then combined together. An important note is

that this should be achieved without causing congestion.

Back-pressure scheduling is an effective scheduling scheme that does just this. It

innately stops packets from being transmitted until there is sufficient load faced by the

output queues. We present a detailed reasoning in section 3.2.

1.3 Contributions:

The thesis shows that embedding COPE with back-pressure scheduling enhances

the working of COPE. Simulation studies are presented to show that COPE finds more

opportunities to combine packets together. The implications of this (theoretically at first)

are significant. Combining packets in a transmission increases the average number of

packets sent per transmission. This results in fewer transmissions for the same amount of

data which results in faster networks. Furthermore, we can also easily see that fewer

transmissions results in the reduction in the consumption of power by the antennae.


9/42

CHAPTER 2

Background

2.1 Network Coding:

Network Coding was first introduced in the paper titled Network Information

Flow [1] presented by Ahlswede et al. Since then the idea has been of interest to various

research groups working on anything from wireless networks [3] to improving route-

ability in VLSI circuits [2]. The innovative idea of Network Coding is to combine data in

intermediate nodes in a flow such that the receiving nodes can decode this information.

The following example briefly explains the relevant features of network coding

(seefigure2.1). In this example, Alice and Bob are two wireless network users and want

to exchange packets. Alice has packet A and wants packet B and Bob has packet B and

wants packet A. Both Alice and Bob can hear the router and the router can hear them.

However, packets from the two nodes need to pass through the router to reach their

respective destinations.

Contemporary transmission techniques require Alice and Bob to send these

packets to the router serially and the router forwards these packets to A and B in two

transmissions (as illustrated infigure2.1.a). Network Coding demonstrates that the router

could instead combine (using XOR represented as ) these two packets and transmit this

combined packet. This results in the two packets A and B being sent out in one

transmission. This capability alone improves the throughput (average rate of successful

packet delivery) of wireless networks.


10/42

Figure 2.1.a Figure 2.1.b

Figure 2. 1 Comparison of contemporary forwarding techniques versus

network coding.

There are some assumptions made in this example. Firstly, both Alice and Bob

are assumed to keep copies of A and B in their packet pools (even after they have

transmitted them) which would allow them to read packets B and A respectively, from

AB. This is a reasonable assumption to make as Alice and Bob just sent out these

packets. Appendices-A and B discuss the XOR operator and illustrate how XOR enables

combining and decoding of packets.

Secondly, we assume that both Alice and Bob can hear transmissions from the

router simultaneously. However, this feature, also called broadcasting, is intrinsically

available in our target networks wireless networks and therefore this assumption is

valid.

Bob

Bob

Bob

Bob

Alice

Router

Traditional Method

Alice

Alice

Alice

Router

Router

RouterA

A A

B

BB

A

B

AxorB AxorB

Network Coding

Alice Bob

Alice

Alice

Bob

Bob

Router

Router

Router


11/42

2.1.1 On the Practicality of Network Coding:

As discussed in the previous section, network coding promises significant

throughput improvements in contemporary wireless communications. The idea of

network coding is very simple packets required by more than one client are combined

together and distributed to satisfy multiple clients. However, a practical implementation

of this concept raises a variety of issues [6,8].

Firstly, in order to ensure the successful decoding a coded packet, transmitting

nodes need to have comprehensive information about the intended destinations. But this

problem can be dealt with by using packet pools to store information about packet

repositories in other nodes in the network. But, we have to limit the maximum size to

take into account the limit of memory available.

Given this information, there are many possible coding schemes that can be

employed. This leads to the issue of how transmitting nodes will decide the best possible

combination of coded packets [6]. To maximise the amount of information (coded-packet

with most number of packets that can be successfully decode by its recipients) sent out,

requires the transmitting node to run through all the possible coding schemes. This

process takes exponential amounts of time to be completed [7]. There have been many

heuristic algorithms that have been suggested to compute this ideal coded packet

combination [7,9].

Other issues include compatibility with current communications systems. Later

sections (section - 2.3) will discuss the introduction of a novel experimental network

module called COPE that was designed explicitly to apply network coding ideas to


12/42

contemporary wireless systems. The next section deals with introducing the simulator

that is used in our experiments.

2.2 OPNET:

The choice of simulator for running experiments and testing ideas can be a tricky issue.

There are a set of features (like efficiency, ease of use, and others) that a simulator needs

to have. The following are the qualities of OPNET that stand out. OPNET is a powerful

commercial network simulation environment created by OPNET Technologies. OPNET

is used by various commercial enterprises such as Comcast Cable, Deutsche Telekom and

others [11]. OPNET has node models for many network devices such as servers, routers,

workstations and other components manufactured by the likes of Cisco, 3M and others. It

has facilities to model transmitter / receiver models for antennae, satellite communication

models for inter-city global communications, adversary models for wireless channel

security analysis and many more network functionalities. OPNETs feature rich simulator

also has an extremely versatile kernel platform which enables users to manipulate node

models to test very specific cases. Users can also define custom flow models hence

giving a very comprehensive control over simulation studies.

The feature of interest in our project is the fact that, standard network node

models implemented by OPNET may be modified to implement novel, untested and

theoretical node models to test for compliance, operability and potential benefits when

added on-to current standards.

For our purposes, this is the feature that is also most useful. We use the current

wireless-workstation model using 802.11 standards to embed COPE. However,

modifying the existing 802.11 implementation provides the user with the task of


13/42

understanding the working of the layers immediately attached to COPE (see figure 2.2 for

a structure of the node models in OPNET). In our case, these layers are the MAC and the

ARP layers.

Figure 2.2.a Figure 2.2.b

Figure - 2.2 - Comparison of Node Models with and without COPE The

model in 2.2.a represents the Wireless_Lan_Workstation_Adv model

available as a standard OPNET node model. Model 2.2.b represents thesame with the COPE layer embedded. Observe that the names of the ARP

and MAC process in the original model have been changed. This was done

to enable the ARP and MAC layers to recognise the new COPE layer.

2.2.1 The Layers in the Node Model:

Application: This layer controls the generation of data. This is where data begins itsjourney and this also where information ends. Application level is usually controlled


14/42

by protocols like HTML, SMTP and others. In OPNET, this layer simulates these

controls.

TCP: OPNET uses TCP for wireless with option to use one of the various TCPflavours such as TCP Reno and Vegas.

IP: The IP layer in OPNET implements the wireless standard for IP_v4.The remaining layers have been modified specifically to house COPE and Back-Pressure

modules. Implementations of these are discussed comprehensively in section-3.

2.3 COPE Architecture:

COPE was designed as a practical incarnation of the up-to then largely theoretical

network coding idea. COPE was proposed by Sachin Katti et al. in their paper XORS in

The Air: Practical Wireless Network Coding [5]. In this paper, the authors discuss this

new layer in the 802.11 wireless standard. The authors also discuss the results of their

experimental implementation of COPE in MITs roof-top network. In this thesis we

include a brief discussion on the various features that COPE offers, the intricacies of the

model that are relevant to the goals of the project and a summary of their results. This

discussion is relevant to this thesis as our attempt was to improve the performance of our

own simulator for COPE. As mentioned earlier, we achieved this by using ideas from the

max-weight scheduling process discussed by Shakkotai and Srikant in [10].

2.3.1 What COPE Achieves:

As a practical set-up, COPE primarily aims to incorporate network codingwithin

the current 802.11 wireless standard. To achieve this, it utilises the broadcast nature of

wireless networks. As a result of adding broadcasting to the toolbox, COPE brings in


15/42

opportunistic listening and opportunistic coding (these concepts are explained in

Appendix-B) of packets as well.

Furthermore, to solve the problem of determining the best coding combination,

COPE uses coding combinations to be decoded after every hops. This means that every

node using COPE would need to store information about packets available at nodes in its

clique set only peers that can hear the source-nodes transmissions. It is important to

note that this single-hop coding would require packet-decoding to take place at every

node in its clique set. However, it is possible that in certain scenarios a neighbour is not

meant to receive information and in this case it will discard the packet only if it is unable

to decode the information; but if it is capable of extracting any information, uses this new

information to update its packet pool.

Additionally, to implement a practical set-up for a new theoretical idea in a pre-

existing architecture requires many changes or additions to the packet structure. To this

end, COPE was primarily implemented as a new layer between the IP and MAC layers of

802.11. COPE has its own packet header (see figure 2.3 for the packet format for this

module).

In this header, COPE stores information in four blocks. The first block houses

information about the total number of packets stored in the XORed packet, Packet_IDs of

each of the packets stored and also their respective next_hops.

The second block plays a crucial role in the working of COPE. This block is used

to send reception reports of overheard packets that exist in the packet pool of the source

node. This information will be added to the packet pool of the receiving node. This


16/42

information will also be used during the coding-combination process to determine which

packets should be coded together.

ENCODED_NUM

PKT_ID

(Similar entries for other packets)

Reception Reports (RR) of Overheard Pkts

Number of RRs

NEXT_HOP

Packets available in the XORed packet

SRC_IP LAST_PKT BIT-MAP

Acknowledgements

NUMBER OF ACKNOWLEDGEMENTS

PKT SEQUENCE NUMBER

NEIGHBOR LAST_ACK ACK-MAP

(Similar entries for other sources)

(Similar entries for other neighbours)

Cope Packet

Format

PACKET INFORMATION

TCP / UDP

IP

COPE

MAC

Higher Layers

(Appln. Level et al.)

Physical Layers

(Transmitter/Receiver)

Where lies

COPE?

Figure 2.3 Position of COPE and Header Details

The third block contains acknowledgements for packets received from the

different intended neighbours. These acknowledgements are asynchronous in nature and

are stored together in an ACK pool. These ACKs are then compiled together and sent to

the TCP. ACKs are not directly sent to the TCP else the TCP will interpret non-sequential

ACKs as network congestion.

The fourth and final block contains the information, may it be in coded or un-

coded format.


17/42

2.4 Backpressure:

Wireless networks, unlike their wire-line counterparts, have always faced an issue

in scheduling links. In wireless networks, when a node is transmitting, another node may

not be available to transmit due to interference of their signals. This creates a lot of

collision in wireless networks. The need for better scheduling techniques to address this

issue was first pointed out by Tassiulas et al in [13]. The Max-Weight Scheduling

algorithm (Back-Pressure Scheduling) is shown to be an optimal scheduling technique

[13, 10].

Now we demonstrate how Back Pressure (BP) controls transmission scheduling in

networks using a simple example.

Consider three nodes node1, node2, node3.Let there be two flows f1 and f2 such that,

f1 flows from node1 to node3, and,

f2 flows from node3 to node1.Also, node1 and node3 are not connected by a wireless link and must relay

information through node2.

This results in the following scenario (figure 2.4)

Figure - 2.4 Discussion on Backpressure This figure shows the various

queues in the different nodes that are required for backpressure calculations.The two flows in this scenario are f1 from node1 to node_3 and f2 from node3 tonode_1. Note that node_2 simply acts as a relay for the two flows and is not asource by itself.


18/42

Now, node 1 will have an output queue with packets destined to node3 andconversely, node3 has packets destined to node1 in its output queue. But observe

that node2 has packets destined to both nodes node1 and node2 in its output

queue; Given the queue length information, Back Pressure (a.k.a. max-weight ) is

calculated thus:

dp

ds

ds QQBPessureBack =,Pr

here, d stands for the destinations is the source node

p is the next-hop for that packet

ab

Q is the queue length of packets destined to node a from node b

Observe that in a larger network, each source node will have multiple BP values,

one for each destination.

The Back Pressure values of each of these queues reflect on the back-log of

packets each node needs to transmit. Higher the Back Pressure value for a queue, more

the information that needs to be sent. Using this fact, nodes with higher Back Pressure

value in a clique can be allocated more contention slots at the MAC level. Higher

contention slots results in that node having a higher chance of capturing the medium and

hence reducing the load in its queues. Conversely, a node with relatively empty queues

will have lower BP values. This will result in the node acquiring fewer contention

window slots; this will directly affect the chances of the node capturing the medium.

Thus, BP manages to intrinsically control the scheduling of nodes in a wireless network.

This is a distributed congestion control scheme.

The equation governing contention window slots as proposed in [14] is given by

the following transformation:

( ) minminmax

maxminmax * CW

BPBP

BPBPCWCWCWavg +

=


19/42

here, CWmin and CWmax are user defined upper and lower bounds for the numberof contention window slots

BPmax and BPmin are the maximum and minimum backpressure values in

the clique of the transmitting node, while,

BP is the backpressure of the transmitting node

Observe that this transform is inversely related to the backpressure value of thenode.

This transformation function is used in our implementation of back pressure embedded

COPE module to control how packets are transmitted.

CHAPTER 3

System Implementation in OPNET

3.1 Implementation of COPE in OPNET:

COPE was implemented in OPNET as a research project by Vinith Reddy in the

summer of 2008. This was done in order to have a more accessible simulation

environment to test new ideas or improvements to the COPE module originally presented

in [5]. With this aim, COPE was built with particular attention given to maintaining the

principles and design of the original COPE module. However, a few changes for the sake


20/42

of convenience were made. The change that affects the functioning of the back-pressure

addition has been listed.

While selecting packets from the virtual output queue, COPE maintains a

probability of packets available in the packet pool(recall that the packet pool stores

information about over-heard packets). This probability enables to COPE to calculate the

ability of the receiving nodes to successfully decode the coded packets. In [5], it is

proposed to calculate the overall coded packet probability as the product of individual

packet probability. The final coded packet would be the combination of all the packets

with highest probabilities as long as this coded packet, has a probability of successful

decoding above a threshold value. However, the current implementation of COPE in

OPNET does not dynamically change these probabilities on any factor. COPE instead

allows for a potentially future addition of this idea but for the present, uses a constant

probability of 1. This implies that any packet in the packet pool, would always be

considered for coding.

3.1.1 Coding Opportunities:

The term coding opportunities is the metric we use to measure the success of our

experiments. Coding opportunities is the number of chances the COPE layer in the

particular node gets to combine packets. As we discussed above, if the output queue does

not have packets that can satiate multiple recipients, or if the packet pools indicate

successful decoding is not probable for any coding-combination, then the COPE layer

will act like a normal wireless node; it discards the opportunistic coding philosophy and it

will send packets to one node at a time. A high value of coding opportunities indicates

that COPE actively finds ways to combine packets so as to satisfy multiple peers. This


21/42

higher value in return will reduce the overall number of transmissions required to get the

same number of packets transmitted. This indirectly implies a rise in the throughput of

the network. failure

3.1.2 Shortcomings of COPE in OPNET and Aim of Experiments:

This implementation of COPE in OPNET was simulated under constant bit-rate

circumstances. Constant bit-rate ensures a constant availability of packets in the output

queues; this will in theory provide nodes with opportunities to combine packets.

However, simulations (graphs shown under the simulations section) have shown that this

COPE implementation provides too few coding opportunities to be worth the CPU

processing required to code and decode packets.

The reason behind this failure, as introduced earlier, is the fact that current 802.11

scheduling schemes attempt to flush out packets from the queues as and when a chance

arrives. This results in relay nodes lacking packets destined to multiple recipients in their

queues. This means we need an over-haul of the scheduling scheme such that packets

controlled so as to benefit COPE. The following section discusses the max-weight

scheduling scheme, a potential fix to this problem.

3.2 The Back Pressure System Embedded in COPE:

This section focuses on the details of the Back pressure implementation in conjunction

with COPE. We implemented the Back Pressure system in OPNET using principles from

a previous implementation made in NS2 by Anthony Halley in [14]. We use this

implementation due to the fact that it can be easily added on-to COPE; particularly, this

implementation enables us to put both COPE and backpressure in the same layer rather


22/42

than having a separate layer for back pressure. This simplifies a lot of the inter-layer

communication issues that we would face otherwise.

3.2.1 Data-Structures:

There are two major data structures that we maintain to store information. This

information is ultimately used to calculate specific node-destination backpressure values.

Firstly, we have a structure to store information about a particular destination.

This structure contained the IP address of the destination, a queue containing Packet IDs

of each packet destined to it and finally the BP value associated with this source-

destination combination. Individual objects of this data structure is stored in a table

(figure 3.1).

Figure 3.1 Backpressure: Contents of the Destination Table

Figure 3.2 Backpressure: Contents of the Peer Table

A second necessity for calculating back pressure values is the queue length of

packet queue to the same destination in the next-hop. For this purpose, we create another

data structure containing the MAC address, a queue containing the various destination

queue lengths and the destination IDs and additionally the maximum back pressure value

of all node-destination combinations in the next-hop. To clarify, the maximum back

Destn. IP Qlength Packet_ID Q BP

MAC addr. Destn ID-Qlength Q Max BP


23/42

pressure value, will be used to compute the minimum and maximum clique back pressure

values which is ultimately required for setting contention window sizes in the MAC

layer. These objects are collated in a peer table (figure 3.2).

3.2.2 Packet Headers:

When packets are transmitted, an additional block of header information is added

to the packet. This header information will then be extracted by the receiving node to

compile its peer table. Therefore, elements in this header block will consist of destination

IDs, the corresponding queue length information and also the maximum BP of the source

node. This will modify the over all COPE packet as shown infigure 3.4.

Figure 3.4 Backpressure in COPE and the new COPE header format


24/42

3.2.3 Coding Combinations:

Obtaining the right Coding Combinations is probably the most important part of

the whole exercise. If the coding combinations are not suitable, then this will result in

poor packet decoding rates and fall in throughput. It is therefore important for

backpressure to use the right scheme.

It can be trivially shown that the general back pressure scheduling scheme can be

successfully extended to network coding. In this extension, a coded packet serving

multiple recipients may be considered a hyperlink. Applying the utility maximisation

frameworks outlined in [10], result is interpreted as:

The back pressure associated with the coded packet is the sum of the back

pressure values for each individual node-destination pair that the coded packet

serves.

This means, to maximise the back pressure of a given node, the packet

combination should consist of packets going to all the destinations with high BP values

associated with it, constrained only by the threshold probability of successful decoding.

However, since the COPE module does not have an active probability update scheme, the

back pressure add-on is implemented in a modified manner.

In this implementation, the packet from the destination queue associated with the

highest BP is de-queued. This packet is then passed on to the COPE encoding process

which uses information from the packet pools to decide the coding combination. This

process at no point checks to remain better than the successful decode threshold


25/42

probability. However, the maximum BP for the source will still be the sum of all the

constituent node-destination BP values.

CHAPTER 4

Simulations and Analyses:

4.1 Simulation Environment:

The simulation Environment consists of two main items. One is the network

topology and the second is the flows. The flow type used for these simulations are

Constant Bit-Rate (CBR) flows that mimic UDP behaviour. There are two topologies

used. Other relevant metrics to keep track are:

1. Contention Window: For certain experiments, we change the contention window sizesto observe the differences in results.

2. Inter-request Time: The amount of time between requests. For all simulations, thisvalue was set to a constant of 0.5s

3. Packets per Request: The number of packets sent per request was set to a constant of1 packet per request.


26/42

4. Packet Size: This is the size of the packet given up-on request. This is set at a constantof 512 bytes per packet.

5. Output QueueSize: This gives the number of packets an output queue in the COPElayer can store. If more packets arrive, they are dropped.

6. Packet Pool Size: This determines the number of packets that can be put in the over-heard packet pool. This quantity affects the rate of successful decoding.

7. CBR: This is the flow model that we use. CBR or Constant Bit-Rate provides a steadyflow of packets in the nodes with a constant information packet size, constant number

of requests per second and constant inter-request time.

8. Coding Centre: This is the node were coding can take place. Coding centres need tohave at least two peer nodes.

In the following sections, we discuss the flows, and the results with and without active

back pressure calculations.

4.2 Cross:

This scenario consists of five wireless-stationary nodes. The nodes are placed in the

formation of a cross as shown in figure 4.1. There is a node at the centre of the cross

and there are four corner nodes. The corner nodes can hear transmissions from only the

centre node. There are a total of four active information flows in the scenario. The flows

in the network are depicted by coloured arrows.

Output Queue Size: 32 packets

Packet Pool Size: 100 packets

Contention Window: 31255 slots


27/42

Figure - 4.1 - Cross Topology The flows are shown by the arrows. Observe that

there is only on coding centre (node1). Also, note that, the corner nodes can

hear transmissions from the central node only.

4.2.1 Analysing the results:

The graphs infigure 4.2 and figure 4.4 show that when the back pressure calculations are

enabled, Node 1 is able to find around an time_average of 0.4 coding opportunities that

node0 and node2 can successfully decode and similarly, 0.3 coding opportunities that

node3 and node4 can successfully decode. Figure 4.3 and figure 4.5 on the other hand,

graph the same values for scenarios where back pressure calculations are disabled. The

decidable coding opportunities fall dramatically and in effect 0 for all four nodes. This

shows that Back Pressure is successful in providing COPE with more opportunities to

combine packets in a cross topology.


28/42

Figure 4.2 Cross BP Enabled Coding Opportunities (Node Set 0-1-2) The

graph shows the curves for successful decoded packets (red and yellow) and thefailed decoded attempts (cyan and dark blue). These quantities are plotted asan average per time interval. The green line, on top, is 1 whenever there is acoding opportunity in the central node.

Figure 4.3 Cross BP disabled Coding Opportunities (Node Set 0-1-2) The

graph shows the curves for successful decoded packets (red and yellow) and thefailed decoded attempts (cyan and dark blue). These quantities are plotted asan average per time interval. The green line, on top, is 1 whenever there is acoding opportunity in the central node. As we can see, when backpressure


29/42

calculations are not used, there are fewer coding opportunities in the centralnode and the success in decoding in the corner nodes per time is similarly low.

Figure 4.4 - Cross BP Enabled Coding Opportunities (Node Set 3-1-4) The

graph shows the curves for successful decoded packets (yellow and green) andthe failed decoded attempts (cyan and red). These quantities are plotted as anaverage per time interval. The blue line, on top, is 1 whenever there is acoding opportunity in the central node. In this case, failures average higherthan successes! This most likely due to small packet-pool sizes.

Figure 4.5 Cross - BP disabled Coding Opportunities (Node Set 3-1-4) The

graph shows the curves for successful decoded packets (red and yellow) and thefailed decoded attempts (cyan and dark blue). These quantities are plotted asan average per time interval. The green line, on top, is 1 whenever there is acoding opportunity in the central node. As we can see, when backpressure


30/42

calculations are not used, there are fewer coding opportunities in the centralnode and the success in decoding in the corner nodes per time is similarly low.

4.3 Chain:

This scenario consists of five wireless-stationary nodes. The nodes are placed in the

formation of a chain as shown in figure 4.6. There is a node at the centre of the chain

and two on either side. Nodes can only hear adjacent nodes.

Output Queue Size: 32

Packet Pool Size: 100

Node 4 Node 3

Node 1

Node 0

Node 2

Chain

Figure 4.6 Chain Topology The flows are shown by the arrows. Also, there

are three coding centres Node 0, Node 1, Node 2In the cross topology, there was only one coding centre (node 1). This scenario is aimed

to test the COPE-BP pair for its robustness in cases where there are more than one coding

centres next to each other. With two runs with different contention window settings, this

topology is also aimed at testing the effect of larger contention windows on coding

opportunities as well as successful decoding rates. Analysis of the two runs follows.


31/42

4.3.1 Run1:

Contention Window: 31..255

Figure 4.7 Chain BP Enabled Coding Opportunities (Node Set 0-1-2) The

graph shows the curves for successful decoded packets (yellow and red) and thefailed decoded attempts (cyan and blue). These quantities are plotted as anaverage per time interval. The red line, on top, is 1 whenever there is acoding opportunity in the node1.


32/42

Figure 4.8 Chain BP disabled Coding Opportunities (Node Set 0-1-2) The

graph shows the curves for successful decoded packets (red and yellow) and thefailed decoded attempts (cyan and dark blue). These quantities are plotted asan average per time interval. The green line, on top, is 1 whenever there is acoding opportunity in the central node. As we can see, when backpressurecalculations are not used, there are fewer coding opportunities

4.3.2 Analysing Run-1

In this scenario, we focus on two details. One is to see how much more successful

decoding back pressure provides to the nodes. Secondly we also want to focus on the

difference between successful and failed decoding attempts.

The first set of nodes we focus on are node0, node 1 and node2. In this

combination, the coding centre is node1. Comparing figure 4.9 and figure 4.10, it is

quickly clear that back pressure maintains its ability to provide significantly more

successfully decoded (~0.45) coding opportunities than COPE by itself. However, when

we look atfigure 4.9 closely, we notice that the number of failed decoding (0.4) attempts

are not too far away from successful decoding attempts. As discussed in an earlier

section, if the decoding process fails, it results in a decrease in throughput due to the need


33/42

to re-transmit the packets in sequence rather than in combination. This is a potential

fallback as the losses seem to nullify the gains.

The nodes node1, node0 and node4 with coding centre at node0 demonstrate a

similar predicament. Here also, back pressure is more successful than COPE by itself.

But once again, the number of failed decoding attempts are too many. So this is indeed a

cause for concern.

Another interesting fact is that the node2 can find no coding opportunities and

does not assume the role of coding centre. There were no plots available here as there

were absolutely no opportunities that node2 could find.

In this run we learn that although the back pressure may provide an overall benefit

in terms of successful coding opportunities, it is still hampered by in ability to decode.

The second run tries to show that stretching the CW limits could possibly help.


graph shows the curves for successful decoded packets (yellow and red) and the


34/42

failed decoded attempts (cyan and green). These quantities are plotted as anaverage per time interval. The blue line, on top, is 1 whenever there is acoding opportunity in the central node.


graph shows the curves for successful decoded packets (red and yellow) and thefailed decoded attempts (cyan and dark blue). These quantities are plotted asan average per time interval. The green line, on top, is 1 whenever there is acoding opportunity in the central node. As we can see, when backpressurecalculations are not used, there are fewer coding opportunities.


35/42

4.3.3 Run2:

Contention Window: 31..1023


graph shows the curves for successful decoded packets (yellow and red) and thefailed decoded attempts (cyan and blue). These quantities are plotted as anaverage per time interval. The red line, on top, is 1 whenever there is acoding opportunity in the node1.


36/42


graph shows the curves for successful decoded packets (red and yellow) and thefailed decoded attempts (cyan and dark blue). These quantities are plotted asan average per time interval. Once Again, when backpressure calculations arenot used, there are fewer coding opportunities

Figure 4.13 Chain BP Enabled Coding Opportunities (Node Set 0-1-2) This

graph shows the curves for coding opportunities in node0 and node2(blue andcyan [overlapped with blue]) , the successful decode attempts (green) and thefailed decoded attempts (red) in node 1. This shows that all three nodes[0,1,2] have found coding opportunities with a larger contention window frame.This implies that in the previous run, there still were collisions thatprevented node 2 from finding coding opportunities.

4.3.4 Analysing Run-2:

Run-2 has just one different setting from run-1. Here the CW window limits are set as

31..1023 slots. In run-2 we aim to study the effect of a larger contention window setting

on the successful to failed decoding ratio. Looking at figure 4.11, we can see that

successful decoding stabilises at around 0.5 while failed decoding average stabilises at

0.3. This clarifies that increasing the window not only increases the successful decoding

average (by 0.05) but it also decreases the failure rate (by 0.15). Additionally, we now

have coding opportunities at node 2 (as implied byfigure 4.13).


37/42

This overall change illustrates the contention-window limits play an important role in the

success of backpressure.

Chapter 5

Conclusions and Future Work:

This work was aimed at testing the advantages that the max-weight scheduling

scheme could bring to the COPE architecture. To test this, we embedded new

functionality to the COPE layer to calculate backpressures at every node. Once we

implemented this, we ran simulations to quantify any advantages it offers. We ran

simulations under two test topologies with constant bit-rate flows.

The test results clearly show that COPE embedded with back pressure provides a

lot of promise to improve the throughput of a wireless network. The success rates

attained in the chain and cross topologies are far greater than what was achieved earlier

when using COPE by itself.

However, there is still a lot more work that can be done to potentially offer more

benefits to COPE. Firstly, we should aim at using a probability scheme to decide on

coding combinations. This alone could reduce the failure rate.

Furthermore, the current BP-COPE model is inclined to perform better under

constant bit-rate (CBR) settings. CBR is UDP like setting. True TCP flows have not been

tested and this avenue for testing will be an important next step. To this end, perhaps the

TCP congestion schemes could be modified to be in synch with this new backpressure

capability of the node.


38/42

Appendix-A

The Workings of XOR:

The Exclusive-OR (XOR) operator plays an important role in our work. It is the

operator of choice in combining packets together. The following appendix discusses the

functioning of XOR and how XOR is used to combine and decode packets.

XOR is Boolean operator symbolised by . XOR is represented by the

following truth-table:

A B XOR

0 0 0

0 1 1

1 0 1

1 1 0

Figure A .1 The Truth Table for XOR


39/42

Appendix-B

Packet Combination and Decoding:

XOR is a bit-by-bit operator. This means that given to Boolean variables A&B, XOR will

be applied on the bits of these variables one-by-one. Packets in communication networks

are a combination of 1s and 0s. The following example discusses packet combination and

its decoding:

.

0100

10111111

:,

:cov

1111

01001011

01001011

,4,,

BPacketiswhich

AP

doweBPacketgetTo

APacketoftyavailabilitheassumesBPacketerretoPDecoding

APackethavePofreceivertheLet

BAPPacketCombined

BandALet

bitssizeofeachBandAPacketstwobethereLet

combined

combined

combined

combined

=

=

=

=

=

==


40/42

Appendix-C

On Opportunistic Listening

Opportunistic listening is a distinctive feature of wireless networks that is a

consequence of the broadcast nature of wireless transmission. In a wireless network,

several surrounding nodes can receive each packet transmitted by a source node [5].

Thus, broadcasting a packet to all neighbours requires the same amount of energy as

transmitting a packet to an individual neighbour. The neighbours that are not meant to be

the destination can cache these over-heardpackets for short periods of time (figure C.1 ).

Figure C.1 Illustrates Opportunistic Listening shows howbroadcasting allows neighbour nodes to listen on the packets to other

nodes. This allows the neighbours to store this information for atemporary while. This storage can serve as caching of packets from

other nodes allowing a better knowledge of other nodes packet pools

Opportunistic listening can increase the robustness of wireless networks. These non-

receiving neighbours, can re-transmit this in the case that the original source fails.

Opportunistic listening is very useful in dynamic on-field sensor networks[12].


41/42

Reference:

[1] R. Ahlswede, N. Cai, S. R. Li, and R. W. Yeung. Network Information Flow. InIEEE Transactions on Information Theory, 2000.

[2]

K. Gulati, N. Jayakumar, S. Khatri, A. Sprintson. Network Coding for RoutabilityImprovement in VLSI. In Proceedings of the 2006 IEEE/ACM international

conference on Computer-aided design, 2006.

[3] M.A.R. Chaudhry, S.Y. El Rouayheb, A. Sprintson. On the Minimum Number ofTransmissions in Single-Hop Wireless Coding Networks. In IEEE Information

Theory Workshop, 2007.

[4] The Network Coding Home Page http://www.ifp.uiuc.edu/~koetter/NWC/ asof 20 April 2009.

[5]

J. Crowcroft, W. Hu, D. Katabi, S. Katti, M. Medard, H. Rahul. XORs in TheAir: Practical Wireless Network Coding. In ACM SIGCOMM 2006.

[6] C. Fragouli, J-Y. le Boudec, J. Widmer. Network Coding An Instant Primer. InACM SIGCOMM Computer Communication Review, 2006.

[7] M. A. R. Chaudhry and A. Sprintson. Efficient algorithms for index coding. InInfocom08 student workshop, 2008.

[8] M. Wang, B. Li. How Practical is Network Coding?. In Proc. of 14th IEEEInternational Workshop on Quality of Service, June 2006.

[9] V. Aggarwal, M. Kim, M. Mdard, U-M. OReilly. IEEE MilitaryCommunications Conference, 2007.

[10] S. Shakkottai and R. Srikant. Network Optimization and Control. NOWpublications - Vol. 2, No. 3 (2007) 271379

[11] OPNET Technologies, Inc. - Clients:http://www.opnet.com/corporate/clients.html as of 19 April 2009

[12] C. Westphal. Opportunistic Routing in Dynamic Ad Hoc Networks: the OPRAHProtocol. IEEE International Conference on Mobile Adhoc and Sensor Systems,October 2006.

[13] A. Ephremides, L. Tassiulas. Stability properties of constrained queuing systemsand scheduling policies for maximum throughput in multihop radio networks.IEEE Transactions on Automatic Control, 1992.


42/42

[14] A. J. Halley A Simple Distributed Backpressure-Based Scheduling AndCongestion Control System. UIUC Graduate degree Thesis. 2006

Copebp Thesis

Documents