Embed Size (px)
Citation preview
Multipath Code Casting for Wireless Mesh Networks
Bozidar Radunovic1, Christos Gkantsidis1, Peter Key1,Steluta Gheorghiu2, Wenjun Hu3, and Pablo Rodriguez4
1 Microsoft Research 2 Universitat Politécnica de CatalunyaCambridge, UK Barcelona, Spain
{bozidar, chrisgk, peterkey}@microsoft.com [email protected]
3 Cambridge University 4 Telefonica ResearchCambridge, UK Barcelona, Spain
[email protected] [email protected]
March 2007Technical ReportMSR-TR-2007-67
Microsoft ResearchMicrosoft Corporation
One Microsoft WayRedmond, WA 98052
http://www.research.microsoft.com
Abstract
Designing high throughput wireless mesh networksis a challenge, and involves solving interrelatedscheduling, routing, and interference problems. Inthis paper, we exploit the fundamental propertiesof broadcast medium and path diversity in wire-less meshes to implement multipath routing be-tween a source and destination pair. We use net-work coding for a given unicast source-destinationflow to ease the scheduling problem, exploit diver-sity, and deal with unreliable transmissions. We de-scribe multipath-forwarding algorithms, and showtheir performance benefits over existing proposals,using simulation, analysis, and a prototype imple-mentation on a small testbed. We propose a rate-scheduling protocol that relies on network coding,which gives over 30% performance improvement fora realistic topology and can double the throughputin certain cases.
1 Introduction
Wireless mesh networks offer a way of creating low-cost and efficient networking, needing no or littleinfrastructure support. They have applications indiverse settings, ranging from disaster-relief to en-abling the wireless office. Yet the inherent variabil-ity of the wireless medium, and the inter-relatedscheduling, routing, and interference problems thatneed to be solve, make the design of mesh networksthat perform well a timely challenge.
One characteristic of wireless mesh networks isthat there is usually a large number of paths con-necting each pair of source and destination nodes.Moreover, these networks are in nature broadcast: atransmission will be received by many nodes. There-fore it is natural to expect that using multiple pathscould improve the performance of the network. In-deed, this was partially shown by Biswas et al. [4].Previous work has typically used only a few parallelpaths, using the same spatial resource, and had toemploy a complicated set of scheduling algorithmsfor packet transmissions. While multipath routingand congestion controlled have been explored in
wireline networks, little has been said for wirelessnetworks.
In this work, we use network coding to ease theprocess of packet scheduling. Moreover, our schememay use many parallel paths that follow very differ-ent routes to reach the destination. Figure 1(a) illus-trates the potential improvement of our system. Inthis figure there are two paths connecting source 1to destination 4, and the capacity limitations are inthe middle of the network. For example, node 2 canforward packets for the flow 1 → 4 at an averagerate of r23, and similarly for nodes 5 and 6 with av-erage rate r56. Our goal is to guarantee average rater = r23 + r56 for the connection 1 → 2. Assume thatsource S broadcasts packets at rate ≤ r. Nodes 2and 3 will receive (potential overlapping) subsets ofthose packets. Which packets should nodes 2, 3 for-ward to their next hops? Can they decide withouthaving to synchronize among them (and avoid thesynchronization overhead)?
We use network coding to answer these questions,and achieve the desired throughput gain, by alwaysforwarding packets that are combinations of the pre-viously received packets. The motivational exampleof Figure 1 is simplistic in the sense that we havesuppressed issues that relate to the reliability of thewireless links, for instance we have not discussedthe process of guaranteeing that the destination willreceive enough packets and be able to decode theoriginal information, and we have ignored fairnessissues. We specifically address such issues in thispaper, which are connected to choosing the rate ofpackets in each route ri and dealing with retransmis-sions. (Note that we do not adapt the physical layerrate.)
The main ideas in our approach can be summa-rized in the following:
• Opportunistic routing: Instead of unicasting apacket to a predefined next-hop, a node broadcastsa packet. This packet can be received by one or afew nodes that are next-hops on different paths tothe destination. This is similar to [4].
• Load balancing and fault-tolerance: Every sourcemaintains multiple routes to the destination, andwhen one path becomes more heavily loaded, the
1
(a) Hexagon (b) Diamond
Source Destination
1 2 3 4
5 6
p12
p15
p23
p56
p34
p64Source
Destination
1 2
3
4p12
p13
p24
p34
Figure 1: Simple topologies where using multiplepaths and network coding increase the performance.In the hexagon topology assume that the bottlenecklinks are the ones connecting the intermediate nodes2 and 3, and 5 and 6. In the diamond topology, net-work coding easies the scheduling of the transmis-sions of the intermediate nodes 2 and 3, and elimi-nates the transmission of duplicate packets.
source decreases the load on that path and increasesthe load of other paths, e.g. [34]. And similarly if onepath becomes less reliable. We outline a rate adapta-tion protocol to implement such load-balancing.• Network coding: the previous two techniqueshave been used before, but require a significant pro-tocol overhead to avoid packet duplication, lost, ordelay. We introduce network coding at intermediatenodes to randomize information transmission anddecrease protocol overhead.
Using these features, we derive our protocol inSection 3. Our scheme encodes packets of the sameflow. This is unlike the opportunistic coding pro-tocol COPE [16] scheme that encodes packets frommultiple simultaneous flows that pass through aparticular node. Hence, our proposal is complemen-tary to COPE. We study the behavior of the idea andalgorithms and quantify the benefits using numeri-cal simulations (Section 4.1), ns-2 simulations (Sec-tion 4.2), and experiments with a lab test-bed (Sec-tion 4.3). The main contributions of our paper are:• We design a system that uses per-flow networkcoding to exploit the benefits of multipath and op-portunistic routing.• By controlling the rate at which encoded packetsare broadcast, we show how it is possible to imple-ment opportunistic routing, direct traffic to appro-
priate parts of the network (eg, least loaded/ mostreliable), and demonstrate how proportional fair-ness (log utility [18]) increases. We describe a pro-tocol that achieves this by implementing a form ofmaximal scheduling in a distributed manner [6].• We evaluate our ideas by simulations using a mul-tipath routing protocol (Section 4), on both sim-ple scenarios (from Figure 1)and a realistic 38-node topology from Roofnet [32]. Our simulationsdemonstrate gains of more than 30% on average,and more than 100% in some cases.• We implement a prototype as a proof of concept. Itis built on top of Virtual Ring Routing (VRR) [5], andsmall-scale experiments confirm the performancegains.
2 Motivation and Examples
We now study illustrative examples of topologies(Figure 1) where multipath routing offers advan-tage. We first look at a diamond topology, and com-pare multipath routing with and without coding,with single-path routing. We then discuss a hexago-nal topology, which allows us to introduce issues offairness.
2.1 Throughput Benefits
Consider the simple 4-node, 2-hop network shownin Figure 1(b), where node 1 is the source, 4 the desti-nation, and 2 and 3 are relay nodes. Suppose furtherthat node 1 can broadcast to nodes 2 and 3, but thatnodes 1 and 4 can not communicate with each other.Our objective is to maximize the information flow fbetween source and destination, subject to the net-work constraints, where the flow f is interpreted asthe throughput, in say unique packets received perunit time.
Specifically, we may assume that source gener-ates fresh packets at a certain rate. These packetsare transmitted over the network, encoded at relays,and eventually received by the destination. The re-ceived flow rate is the rate at which packets of thesource stream can be reconstructed. For more detailson network coding, see Appendix.
2
The routing problem asks which route packetsshould take: how many should be sent via node 2and how many via node 3. The scheduling problemdetermines the packet schedule at each node. Letαi denote the fraction of time node i is active (hence∑i αi = 1). Suppose that nodes broadcast packetsat the same rate of 1 packet per time unit, and thatpackets transmitted by i are successfully received byj with probability pij. Here 1 − pij is the erasureprobability, and incorporates the effects of the phys-ical (PHY) layer, interference, and MAC retransmis-sions. To ease the description, we set p12 = p13 = pand p24 = p34 = q with probabilities assumed inde-pendent.
We will use a model similar to the one in [25] tocharacterize the capacity region of a network withnetwork coding. Define ri J for a set J to be theinformation rate on links i J , that is the rate atwhich linearly-independent packets from i are re-ceived (and may be forwarded) by the nodes in theset J, where J is the set of nodes that can receive in-formation from i.
The ri J can be interpreted as the carried flowrate. Under our assumptions of independent erasureprobabilities, we have
ri{J} ≤ αi
1− ∏j∈{J}
(1− pij)
. (1)
(Clearly r1i ≤ α1 p and ri4 ≤ αiq for i = 2, 3.) Wenow explore throughput using different routing andscheduling policies
Multipath routing with Network CodingSince the same packets may be received by nodes
2 and 3 when node 1 broadcasts, using the unionbound (1) we have the constraint
r1,{2,3} ≤ α1
(1− (1− p)2
)= α1 pb. (2)
which is achievable, where
pbdef= 1− (1− p)2
is the probability at least one broadcast packetreaches a relay node. The optimal flow has to satisfy
f ≤ r1,{2,3}, f ≤ r24 + r34, and with the constraintsr1,{2,3} ≤ r12 + r13, r1i ≤ ri4 it is straightforward toshow that the unique solution is
fnc =pbq
pb + q, α1 =
qpb + q
. (3)
Uniqueness follows since we are effectively solv-ing a linear program — given that the p’s are as-sumed fixed, we have a linear objective functionmaximized over linear constraints, solving for non-negative variables (the αi and rij).
Networking coding is implicit in this solution, en-suring that what is received at relay nodes 2 and 3is useful to node 4; nodes 2 and 3 recode the packetsthey receive. Indeed, either directly or by adaptingthe results of [25] we can show that a random linearcoding scheme can get arbitrarily close to this rate(with arbitrarily small error probability, providedwe can look at large number of packets), where theintermediate nodes generate random linear combi-nations (over the appropriate field) of packets theyreceive.
The above relation (3) holds more generally if wehave n relay nodes instead of 2, where all links inter-fere (only one node may transmit at a time). Let 1 bethe source, n + 2 the destination, and {2, · · · , n + 1}relays, with p1,n+2 = 0, p = p1i, q = pi,n+2 andpb = 1− (1− p)n. A rate constraint on the first cut,between the source and the relays, is fnc ≤ α1 pb anda rate constraint on the second cut is (1− α1)q. Fromthere we readily obtain the maximal average end-to-end rate fnc = pbq
pb+q .Naïve multipath routingWithout network coding, intermediate relay
nodes just relay received packets, hence duplicatepackets may be received by the destination, and wehave to subtract the ‘double-counted’ packets. Asbefore, r1,{2,3} is given from the bound (2), howevernow the aggregate rate at the destination is boundedabove by (1− α1)q− α1 p2, since there are α1 p2 dupli-cate packets on the average. In this case, the (unique)maximum rate is given by
fmp =pbq
q + 2p, α1 =
qq + 2p
(4)
3
The equation generalizes when there are n relays,the average rate of duplicated packets is α1(np− pb),the rate constraint on the second cut is (1 − α1)q −α1(np − pb), hence the maximal average end-to-endrate is
fmp =pbq
q + np. (5)
Note that we have fmp ≤ fnc.Fixed RoutingWith fixed routing, we can only use one path. In
this case
f f r =pq
p + q(6)
with α = pp+q .
Even in this simple scenario, we get a benefit frommultipath routing ( fnc > f f r) provided the links tothe relays are not lossless (p < 1). The improvementratio fnc/ f f r = pb(p + q)/p(pb + q) increases with n,the number of relay nodes, and q, and decreases as pincreases— i.e., the less reliable the broadcast links,the bigger the gain. Indeed, with q = 1 and smallp (very unreliable broadcast links) the ratio is n +O(p), which illustrates the potential benefits. Thegain is bounded above by 1/2p + 1/2.
The benefit of multi-path over single-path rout-ing for various values of p and the number of re-lays is shown Figure 2, where the relative through-put ( fnc/ f f r) is plotted. As expected, we see that thebenefit is maximal when the first hop is unreliable (psmall), second hop is reliable (q large), and the num-ber of path is large. However, in most cases we canexpect over 20% improvement, even in such a sim-ple network.
This example is not particularly favorable to mul-tipath routing: in a general network, fixed routingmay not choose the best single path route, as it doesin this example.
Figure 2 also show the advantage of using net-work coding rather than naive multipath routing.The figure plots fnc/ fmp. We see that network cod-ing always make transmissions more efficient asit eliminates the redundancy, especially when thenumber of paths is large.
0.4 0.6 0.8 11
1.5
2
2.5
3
p
Rel
ativ
e im
prov
emen
t
fnc
/ffr, Diamond
fnc
/fmp
, Diamond
fnc
/ffr, 4 relays
fnc
/fmp
, 4 relays
Figure 2: Relative performance improvement usingmultipath coding over single-path and naive multi-path (q = 0.8).
2.2 Fairness and scheduling
The previous example assumes that the erasureprobabilities are known, in which case the optimalschedule and routing can be simply determined. Inpractice such probabilities are unknown and vari-able, and later we show how to construct a schedul-ing and routing protocol that implicitly estimatessuch quantities.
We shall also consider the hexagon network,shown in Figure 1 and we suppose 2 and 3 do notinterfere with nodes 5 and 6, hence links 2-3 and 5-6can transmit in parallel.
Suppose now we have an additional flow thatuses link 5-6, then how should we be fair to sucha flow? If we associate a utility function with a flow,U( f ) then seeking to maximize ∑ f U( f ) for a givennetwork is equivalent to using a fairness criterion.For example, putting U( f ) = log f give propor-tional fairness [18], and putting U( f ) = −1/ f givesTCP type fairness. It turns out that the optimiza-tion framework used above carries through if we useconcave utility functions U, and we can again showthat a unique solution to the scheduling and rout-ing problem exists. We shall implement a form offairness later by allowing nodes to generate creditsaccording to a rate derived from a utility function.
4
3 System Design
We now discuss the design choices of our systemand the performance implications. We also outlinethe core of our prototype implementation. Our de-sign strives to (a) guarantee that all packets injectedat the source arrive at the destination, (b) use the sys-tem resources efficiently to transfer the packets asfast as possible, and (c) ensure fairness among dif-ferent source - destination flows that are competingfor the same resources. To achieve these broad goals,our system uses the following components:
• Path finding and selection to identify a set of candi-date paths (Section 3.1).
• Packet encoding and decoding to divide the pack-ets into generations and code inside the generations(Section 3.2).
• Error Control to guarantee that all packets reach thedestination (Section 3.3).
• Rate Control to decide the next packet to transmitand to ensure fairness among flows (Section 3.4).
We sketch the design of the system in sufficientdetails to perform simulations and prototype-basedevaluation. However, some important protocol de-tails are left for future work, for example, we omitthe discussion of imperfect signaling. Moreover,a more detailed evaluation is necessary to studythe interaction between our system and higher-levelnetwork applications.
3.1 Path selection and multipath for-warding
Current routing algorithms are very efficient forfinding the best path (for an appropriate definitionof optimality) to route traffic from a source to a des-tination [5, 15, 30]. Many of them also discover ad-ditional (secondary) paths that are used when theprimary path fails. In contrast, we need to discovermultiple paths to use in parallel to optimize the per-formance of the routing. These paths are not neces-sarily disjoint. The use of non disjoint parallel pathshas received some attention in [4, 10] but has notbeen studied comprehensively.
For the simulations performed in the paper, weuse a heuristic algorithm described in Section 4.1for discovering such paths. Our prototype currentlyuses the underlying routing protocol (VRR) for find-ing multiple paths [5].
3.2 Packet encoding and decoding
We define a flow as an ordered collection of packetsthat need to be transferred from one wireless meshnode, the source, to another node, the destination.Observe that our flows may be composed of pack-ets from different upper layer traffic (e.g. TCP), oreven from different machines; the only requirementis that they enter and exit the wireless mesh networkfrom the same endpoints.
For the purposes of our simulation studies wehave assumed that all packets are of the same size.Our prototype pads short packets to the same size.More efficient solutions remain for future work.
Our system receives from the upper layer a se-quence of packets. Those packets are grouped ingenerations; typically a generation is composed of32 consecutive packets. The size of the generationhas both performance and design implications; forexample larger sizes allow for more encoding oppor-tunities and improve the system efficiency, but alsorequire more buffer space. Some discussion on theoptimal generation size is given in Section 4.1.1. Weencode packets that belong to the same generationonly, according to the process described in the Ap-pendix.
The destination tries to decode packets as new en-coded packets arrive (see also Appendix). In theworst case, the entire generation will be decodedwhen enough linearly independent packets fromthat generation arrive. The decoded packets are de-livered to the upper layer sequentially. If the des-tination is not able to receive enough linearly in-dependent packets, then it uses the retransmissionmechanisms described in Section 3.3.
3.3 Error control
In order to solve the linear system to recover codedpackets, it is necessary and sufficient to receive the
5
same number of linear combinations as the numberof original packets in the generation. Our system in-cludes two error control mechanisms to ensure thedestination receives enough packets - hop-by-hoplocal recovery and end-to-end retransmissions.
Local recovery is achieved by processing ‘passiveacknowledgments’. Given the broadcast medium,a sending node can potentially overhear what thenext hop transmits and determine if all the next hopshave received enough linear combinations betweenthem. If not, the sender retransmits more combina-tions.
It may happen that some native component is lostat all intermediate nodes, so end-to-end recovery isnecessary. This is expensive and should be infre-quent. We employ a ‘pseudo’ end-to-end mecha-nism. The destination unicasts a request toward thesource for more combinations for the given genera-tion. If any relay receiving the request has all com-ponents for the generation, it could intercept the re-quest and generate retransmissions. Otherwise, therelay forwards on the request toward the source.These retransmissions are also unicast toward thedestination. Unicast increases the chance that the re-quest and retransmissions are correctly received.
Note that for both the hop-by-hop and the end-to-end mechanisms, retransmitted packets are in factnew linear combinations of all packets the node hasreceived (or for the source, that the node has sentout).
A final note is due about why we have chosento implement a retransmission scheme, instead ofsending enough redundant packets (which happennaturally using network coding) so that the desti-nation will receive enough packets to decode. Wehave performed analytical and experimental studiesof a scheme without retransmissions and observedthat the redundant packets consume a lot of networkresources and effectively reduce the performance ofthe system.
3.4 Rate Control
One of the most challenging problems of imple-menting a multipath routing algorithm is to decidehow to split the rates among the multiple paths. This
rate control algorithm needs to adapt fast to vari-ations in link qualities, congestion signals comingfrom different paths, and react to packet losses.
A simple rate control design is to let the sourcedecide the rate on each path. However, this is inef-ficient as a delay in feedback from a broken or con-gested link within the network to the source may belarge. Instead, we opt for a distributed rate controlalgorithm where each relay decide which next-hopnode to use for each packet it relays.
Our distributed rate control algorithm is based onthe ideas from [24, 33], and, in addition, deals withtwo issues that are unique in our system. The firstrelates to the broadcast nature of the transmission;when a relay forwards a packet there are severalpossible next-hops for a packet and the relay doesnot know in advance which next-hop node will ac-tually receive the packet. The second issue relates tothe use of network coding. In our case every packetis a linear combination of the packets that wereavailable to the sender. As a result the relay doesnot even need to know which next-hop receivedwhat packet (observe that in unencoded transmis-sions such knowledge is important). Actually, thefact that we forward linear combinations and thatwe do not care about individual packets easies thedesign of our rate control algorithm. Note also thatwe do not adapt physical transmission rates.
With the above motivation in mind, we presenta credit-based algorithm for rate control. For eachpacket generated at the source, the source generatesone (node) credit and assigns it to the generation thepacket belongs to. A credit is further identified by itsgeneration and not by the packet itself. The featuresof the algorithm are as follows:
1. Credits are created for each packet at the sourcenode, and identified with a generation, not a specificpacket.
2. Credits are interpreted as the number of packetsto be transferred by the node for a specific flow.
3. Credits are conserved.
4. Credits are declarations of intent, and transferredby a (sending) node before packets are transmitted;
6
the receiving node only updates such credits whensuccessful packet transmission actually occurs.
5. Nodes also keep track of transmission-credits, asso-ciated with each subset J downstream nodes, whichcan be interpreted as the expected number of creditsthat must be received by at least one node in J.
6. When a credit is transferred from a node n to m,transmission credits are increased on all subsets J ofdownstream nodes that contain m.
7. When a packet is transmitted from node n to m,the transmission credits are decreased for all subsetsJ of J of downstream nodes that contain m.
8. Backpressure is used to determine where to routepackets and where to transfer credits.
We now describe the algorithm in more detail. Fornode n and flow c let DST(n, c) be the set of all next-hop (downstream) nodes of node n for flow n. Cred-its are stored at a node: list C(n, c) contains all thecredits for flow c stored at node n. Each node isresponsible for all the credits it has received, andit is obliged to forward each credit to exactly onenext-hop node. Credit losses are minimized, and asuitable retransmission scheme is developed, as dis-cussed in Section 3.3.
Transmission credits are associated with broad-cast link, as defined in [25]. For all J ⊆ DST(n, c)we define TC(n, c, J) to be the list of credits associ-ated with broadcast link (n, J). We want to guaran-tee that all credits from TC(n, c, J) will be transmit-ted to at least one of the nodes from set J.
We also define the cumulative transmission credit
CTC(n, c, m) = ∑J⊆DST(nc,c),J3m
|TC(n, c, J)|.
It will be used to define the state of congestion oflink (n, m). The higher the value of CTC(n, c, m), themore packets are waiting to be transmitted to nodem, hence the more congested the link is.
C update: At any point in time, node n checks thefollowing routing decision
RD : |C(n, c)| > |C(m, c)|+ |CTC(n, c, m)| (7)
for each m ∈ DST(n, c), and starts transferring oneof its credit for flow c to node m. If the routing de-cision is true for several next-hops, it will select oneat random, say node m. The intuition behind thisrouting decision is as follows: In order to keep net-work stable, one needs to guarantee that all creditqueues will be bounded. To achieve that, we useback-pressure. If either the set of node credit C(m, c)or the number of cumulative transmission creditCTC(n, c, m) are large, node n will not forward anymore packet to that direction, hence the queue willnot build up. We illustrate the convergence issue nu-merically by example in Section 4.1, Figure 4.
Credit updates are included in headers of actuallytransmitted packets. That means that node m willbe informed about the credits transferred to it beforetime t only after a packet, broadcast after t, is suc-cessfully received by m. At that point, it will updateits credit set C(m, c). More formally, let zn
t (n, c, m)be the list of all credits transferred from n to m un-til time t, as seen by node n, and suppose that apacket broadcast by n at time t is successfully re-ceived. Then, node m receives zn
t (n, c, m), and it willadd to its credits the set
C(m, c) = C(m, c) ∪ (znt (n, c, m) \ zm
t (m, c, n)).
Credits are added to the source node of each flowwhen fresh packets are created. The rate at whichwe generate fresh packets will define the efficiencyof the scheme and the fairness among flows. Wepropose a simple scheme, inspired by [24], in whichnode n, the source of flow c, is allowed to insertK/C(n, c) credits (and packets) per time unit, whereK is an arbitrary constant. The higher K is, the higherthe average queue size and delays in the networkwill be, but also it is less likely that an empty queuewill occur, hence the efficiency is higher. We illus-trate the performance of the flow control algorithmin Section 4.1, Figure 7.
Observe that the total number of credits changeat the sources, since the source insert credits, andat the destinations, where each packet reception re-duces the number of credits. (Credits can also be lostby node failures.) Moreover, the rate of credit inser-tion is controlled by the congestion signals. Hence,
7
the system does not enter periods of instability whencredits are inserted in the system without control.
TC update: Whenever a credit for flow c is trans-ferred from n to m, then a corresponding trans-mission credit is added to TC(n, c, J) for all J ⊆DST(n, c) such that m ∈ J.
When a packet from flow c is successfully trans-mitted from node n to node m, we remove one trans-mission credit corresponding to the packet genera-tion from TC(n, c, J) (if exists), for all J ⊆ DST(n, c)s.t. m ∈ J.
Although it may appear that TC(n, c, J) is simplya union of TC(n, c, i) for all i ∈ J, this is not alwaysthe case. We illustrate the use of TC(n, c, J) on theexample from Figure 3. Initially, |C(1, 1)| = 2, andnode 1 transfers one credit to node 2 and one to node3. Then node 1 broadcasts a packet, which is re-ceived by both nodes 2 and 3. This in turn decreasesTC(1, 1, 2) and TC(1, 1, 3) to empty sets, but we stillhave |TC(1, 1, {2, 3})| = 1. In other words, to suc-cessfully finish the credit transfer, we still need totransmit successfully one packet, either to node 2 ornode 3.
Scheduling packets: Finally, we need to describehow we transmit packets. We first introduce somenotations. Let us denote by Q(n, J) the quality met-ric of broadcast transmission from n to J. This corre-sponds to the probability, as measured by n, that atleast one node from J will receive a packet transmit-ted from n. We further define
W(n, c) = ∑J⊆DST(n,c)
TC(n, c, J)Q(n, J)
and W(n) = maxcW(n, c), c(n) = arg maxc W(n, c).When the routing decision RD is satisfied at node
n for at least one flow c and its next-hop, node n willcalculate c(n) and prepare a random linear combi-nation of the packets buffered for flow c for trans-mission, from the generation corresponding to theoldest transmission credit. Intuitively, by selectingthe flow c(n) the node will maximize its expectedreduction in the queue size, similarly to [33]. It willthen contend for transmission of the packet in thewireless medium.
CREDIT TRANSFER
3
1
2
0
1
1
0
0
1
PACKET TRANSFER
3
1
2
2
0
0
0
0
0
C(1,1)
C(2,1)
C(3,1)
1,2
1,3
1,{2,3}
TC
0
0(1)
0(1)
1
1
2
Figure 3: An illustration of rate control: Considernodes 1, 2 and 3 from the diamond topology de-picted in Figure 1(a). First node 1 transfers one creditto each of the nodes 2 and 3. Then node 1 trans-mits a packet that is successfully received by bothnodes 2 and 3. After credit transmission and beforepacket transmission, nodes 2 and 3 are not yet awareof credit transfers, thus |C2(2, 1)| = 0, |C3(3, 1)| = 0.However, |C1(2, 1)| = 1, |C1(2, 1)| = 1 (values inbrackets).
Ideally, to maximize the stability region, nodesshould be scheduled to transmit according to thequeue sizes TC and link qualities Q, as in [24,33]. This optimal scheduling is hard to implement.A simpler suboptimal scheduling, called maximalscheduling, is proposed in [6]. It is polynomial andclose to the optimal. In contrast, the scheduling im-plemented by 802.11 MAC is much more randomthan the previous two scheduling algorithms and farfrom the optimal. However, discussing differencesbetween these scheduling algorithms goes beyondthe scope of this paper. We will evaluate our ap-proach on different scheduling algorithms: maximal
8
scheduling in Section 4.1 and 802.11 scheduling inSections 4.2 and 4.3. We show that our system im-proves performance in both cases.
4 Evaluation
We analyze the performance benefits of multipathcode casting over single-path routing using severalmethods. We first simulate our protocol using nu-merical simulations in MATLAB, then we simulateit in ns-2 network simulator, and finally we test it onan experimental test-bed.
4.1 Numerical Simulations
We first want to evaluate how multipath code cast-ing (mc2) allocates rates over multiple availableroutes, and quantify the benefits of multi-path rout-ing vs. single-path routing. We also want to un-derstand the effects of different architectural param-eters on performance, such as generation size andcoding field size. We want to be able to quicklyverify these results on relatively large wireless meshnetworks (of about 40 nodes).
To achieve this, we developed a simple, event-driven simulator in MATLAB. The input to the sim-ulator is a topology matrix P = {pnm}n,m=1···N ,which defines the probability of successful transmis-sion pnm between any two nodes n, m in a networkof N nodes.
We abstract most of the signaling issues. We as-sume that a node is instantly informed about thesuccess of its transmission. However, we only trans-fer credits to next-hops once a successful transmis-sion is made. The simulator uses synchronizedscheduling. The main scheduling principle is that,if node n is scheduled, then no other node m can bescheduled for which pnm > 0 or pmn > 0. In this sec-tion, we evaluate the results using maximal schedul-ing [6] described in Section 3.4.
We used a centralized routing algorithm to findsthe best paths. We define the quality of path ρ ={n1, · · · , nk} to be C(ρ) = ∏k−1
i=1 pni ,ni+1 . We usedexhaustive search to find the best 2, 4, or 6 paths
according to this metric, for each source-destinationpair.
4.1.1 Simple Topologies
We first consider simple networks, the diamond(Figure 1-b) and hexagon (Figure 1-a) topologies. Inthe diamond topology we set p12 = p13 = p andp24 = p34 = q, and we fix q = 0.8 and we vary p,as we did in Section 2. In the hexagon topology weset p12 = p15 = p and p23 = p34 = p56 = p64 = q.We fix q = 0.8 and we vary p. Numerical results areshown in Figure 4.
The simulation results match the analysis fromSection 2, showing that the proposed matching al-gorithm achieves the optimal rate control in the caseof the diamond and hexagon topologies.
The relative improvement is higher in the case ofthe hexagon topology. This is due to the fact thatlinks 2-3 and 5-6 can transmit in parallel, and thebottleneck in the hexagon topology is on node 1.In the diamond topology all nodes contend for theMAC access, hence the improvement is less visible.As a general rule we expect that partially disjointpaths may perform better.
We also illustrate the benefit of the coding overnaive multi-path routing. Note that naive multi-path corresponds to network coding with genera-tion size 1 (thus no possibilities for coding). Wealso observe that any generation size, larger than16, performs equally well. However, on larger net-works, larger generation sizes may be needed (seeSection 4.1.2).
Finally, we illustrate the convergence speed in Fig-ure 4(c). We plot node credits for the diamond topol-ogy as a function of the iteration size. We see thatthe rate control algorithm converges in 50 iterations.However, the actual average end-to-end rate con-verges in less than 10 slots. We observe similar con-vergence speed on the Roofnet topology, describednext.
4.1.2 Roofnet
In this section we consider the Roofnet networktopology [3]. We take the loss measurements avail-
9
(a)
0.4 0.5 0.6 0.7 0.8 0.9 10
0.1
0.2
0.3
0.4
0.5
p
Ave
rage
thro
ughp
ut [p
kt/s
lot]
Multi−path with network codingNaive multi−pathSingle−path
(b)
0.4 0.5 0.6 0.7 0.8 0.9 10
0.1
0.2
0.3
0.4
0.5
p
Ave
rage
thro
ughp
ut [p
kt/s
lot]
Multi−path with network codingNaive multi−pathSingle−path
(c)
5
10
15
NC
(1,1
)
0
5
10
NC
(2,1
)
0 50 100 150 200 250 3000
5
10
NC
(3,1
)
Slot
Figure 4: Single-path vs. multi-path for diamond (a) and hexagon (b) topology. For each generation sizewe run 10 simulations, each transmitting 15MB. Confidence intervals are very small. The improvement ofmc2 is 20% in the case of diamond and almost 100% in the case of hexagon topology. In (c) we illustratethe convergence speed of node credits for the diamond topology. We plot node credits for the diamondtopology as a function of the iteration size (note C(4, 1) = 0 always).
able from the Roofnet web site [32] for differentphysical transmission rates, and we feed them to oursimulator. We randomly select source-destinationpairs. We use GF(28) field for coding, and genera-tion size of 32, unless specified otherwise.
0 0.5 1 1.5 20
0.5
1
1.5
3
4
5
6
8
910
13
14
15
17
19
21
23
29
35
[km]
[km
]
Figure 5: One sample of the Roofnet topology:source-destination pairs 5-29, 21-35, 6-14, 19-17 areconnected using solid lines. Links used by our rout-ing protocol are denoted by dotted lines. See [3] andthe references therein for the exact topology specifi-cation.
Single-flow case: We first consider the Roofnet
topology with a single flow, and we evaluate howthe performance improves when we increase thenumber of paths. The results are depicted in Fig-ure 6.
We see that if we use 2 paths, in 20% of casesthe improvement of multi-path over single-path islarger than 20%, whereas if we use 4 or 6 paths, foralmost 50% of the cases the improvement is largerthan 20%. This suggests that the optimal numberof paths for Roofnet topology is 4 paths. From Fig-ure 6(b) we see that the performance improvementfor 5.5Mbps and 11Mbps PHY broadcast rates is al-most the same.
We also see that in a small number of cases (lessthan 5%), multi-path exhibits worse performancethan the single-path. In these cases, the performancedrop is higher for a larger number of paths. This isdue to the linear dependency in the received pack-ets, as illustrated in Figure 6(c). The number of lin-early dependent packets can be reduced if the gen-eration size is increased, which in turns introducesthe amount of space needed by coefficients in eachpacket’s header. We believe that the generation size32 is a good compromise.
Multiple-flow case: The only benefit from mc2 inthe single-flow case comes from the opportunisticrouting. When there are several concurrent flows,
10
(a)
0 20 40 60 80 1000
0.5
1
1.5
2
2.5
Node pairs
Rel
ativ
e m
ulti−
path
impr
ovem
ent
2 paths4 paths6 paths
(b)
0 20 40 60 80 1000.5
1
1.5
2
2.5
3
Node pairs
Rel
ativ
e m
ulti−
path
impr
ovem
ent
5.50 Mbps11.00 Mbps
(c)
0 20 40 60 80 1000
0.2
0.4
0.6
0.8
1
Node pairs
Fra
ctio
n of
lin.
inde
p. p
acke
ts
2 paths4 paths6 paths
Figure 6: Performance of a single flows on the Roofnet topology. We consider 100 instances of the Roofnettopology with randomly selected source-destination pairs. (a) Cumulative improvement for 2, 4 and 6 pathrouting over the single-path routing, for PHY rate of 5.5 Mbps. (b) Cumulative improvement of the 6-pathsrouting over the single-path case for PHY rates of 5.5 and 11 Mbps. (c) Fraction of linearly independentpackets received at the destination for the case of 2, 4 and 6 path routings, for PHY rate of 11 Mbps.
mc2 will also improve the fairness among the end-to-end flows through load-balancing. We illustratethis for the case of 4 concurrent flows in Figure 7.
We first consider the example from Figure 5, andwe plot the rates achieved by the 4 flows in Fig-ure 7(a). When all flows use only a single path, wesee that the second flow, 21-35, achieves much lowerend-to-end rate than the other flows. We see thatas we increase the number of paths, the rate of flow21-35 significantly increases. At the same time therate of flow 19-17 slightly decreases, but still remainslarger than the rate of flow 21-35.
In order to quantify the fairness and the efficiency,we further use the following two metrics. The first isthe sum of the end-to-end rates of all the flows in thesystem, Figure 7(b), which measures the efficiency ofthe system. The second one is the log utility [18], Fig-ure 7(c), equal to the sum of logs of the end-to-endrates of all the flows in the system, which measuresboth the efficiency and the fairness of the system.
From the results we see that again in about 50% ofthe cases the sum of all the rates in the network isincreased by at least 20%. We also see that in all ofthe cases the log-utility of the system has increased.
4.2 Simulations using ns-2
The main drawback of the previous simulationsetup are the simplifying assumptions on MAC andPHY. In order to obtain more realistic model of802.11 MAC and PHY, we used the network simu-lator ns-2 to simulate the diamond and the hexagontopology.
We did not implement the full rate-control in ns-2,since there are several protocol issues that are out ofscope of this paper. Instead, we pre-calculated thecredit assignments in the MATLAB simulator andhard-coded them in ns-2.
We simulated the diamond topology for p12 =p13 = p24 = p34 = 0.5 and the hexagonal topologyfor p12 = p23 = p34 = p15 = p56 = p64 = 0.5. Weconsidered a single CBR flow, varied its rate, and welooked at the effective end-to-end rate. The resultsare depicted in Figure 8.
For the diamond topology, the system gets sat-urated at around 150kbps in the case of single-path, and at around 200kbps for the multi-path case,hence the improvement is 42%. In the hexagonalcase, the improvement is 35%. Note that the ratesin the hexagonal case is lower than in diamond; dueto inefficient 802.11 scheduling there are more MAClayer collisions in the hexagonal case.
11
(a)
1 2 4 60
0.2
0.4
0.6
0.8
1
Number of paths
Rat
es [M
bps]
Flow 1Flow 2Flow 3Flow 4
(b)
0 5 10 15 20 250.8
1
1.2
1.4
1.6
1.8
2
Node pairs
Rel
ativ
e su
m−
of−
rate
s im
prov
emen
t
2 paths4 paths6 paths
(c)
0 5 10 15 20 25−2
0
2
4
6
Node pairs
Abs
olut
e ut
ility
diff
eren
ce
2 paths4 paths6 paths
Figure 7: Performance of 4 concurrent flows on the Roofnet topology: (a) Example of end-to-end rateallocation for flows illustrated in Figure 5 (b) Cumulative relative improvement of the sum of rates for 2,4, and 6 path cases over the single-path case, for PHY rate of 5.5 Mbps. We consider 100 instances of theRoofnet topology with randomly selected source-destination pairs. (c) Cumulative absolute improvementof the log-utility for 2, 4 and 6 path cases over the single-path case, for PHY rate of 5.5 Mbps (here somenode pairs are missing as we cannot calculate the utility of a zero rate allocation).
0 100 200 300 400 5000
50
100
150
200
CBR Rate (kbps)
Des
tinat
ion
Thr
ough
put (
kbps
)
multi−path, diamondsingle−path, diamondmulti−path, hexagonsingle−path, hexagon
Figure 8: Ns-2 simulation results for the topologiesfrom Figure 1. The x-axis corresponds to the sourceCBR rate and the y-axis to the effective end-to-endrate.
4.3 Preliminary testbed evaluation
We have built a prototype system implementing abasic sets of mc2 functionalities, including multi-path forwarding, coding on multiple paths and er-ror control. We focus on small topologies like thediamond topology, where all paths from the sourceare assumed equally good and hence used simulta-neously. The coding rate is split evenly among thepaths, and is determined by the number of paths.
We evaluate the performance on a testbed resem-bling the diamond topology. All nodes are laptopsand desktop PCs equipped with Netgear 802.11a/gcards with the Atheros chipset. The experiments arerun in 802.11a mode, and the default broadcast rateof 6Mbps is used. We compare throughput of 800KUDP flow transfers for 2 parallel paths and a singlepath for two configurations of the diamond topol-ogy, with high and low loss rates between sourceand the relay nodes respectively. Different loss ratesare produced by moving source very close to or veryfar from the first hops, and the relays were about50cm apart in both configurations. For the low losscase, the 2-path scenario showed a 17% throughputimprovement, while for the high loss case the im-provement was 25%. These results are consistentwith the analysis earlier.
12
Note that the two relays are in the same con-tention domain, and future work will study the per-formance on topologies involving relays that cannothear one another. We will consider desynchronizingtheir transmissions to avoid collisions at the destina-tions.
5 Related Work
Multipath routing has a long history in telecommu-nications. In (wired) wide area networks, multi-path routing has generated research activity linkedto performance benefits in Internet [8,13] or overlays[2], with authors proposing different routing archi-tectures [20, 35, 36]. Some of these authors have pro-posed proportional splitting of traffic across multi-ple routes, or a form or randomized splitting. Therehave been recent proposals to combine multipathrouting with rate control [14, 17, 19], jointly optimiz-ing at the network and the transport layer, which isan example of cross-layer optimization [34]. To date,little has been said about how to choose routes, orhow to switch between routes when using multipathrouting. In our approach, we tie together rate controland routing, without involving the transport layerat this stage. Including and incorporating transportlayer controls (such as a TCP-like control) is an ex-tension of our work for future research.
Multipath routing in wireless networks has alsoreceived considerable attention, driven by ad-hocnetwork research. [31] looks at splitting traffic acrossmultiple paths to reduce congestion problems inwireless sensor networks. Marina et al [26] extendedAODV to a multipath version, AOMDV, allowingmultiple loop-free and disjoint paths, and the gen-eral feature of much multipath work has been toonly consider disjoint paths (e.g. [22]). The useof semi-disjoint or ‘braided’ paths is argued for inMoski et al [29] in a mesh context. Theoretical anal-ysis of wireless cross layer design with multi-pathrouting is done in [24], but without network coding.
Most of the work done in network coding con-siders multicast transmissions [1, 23,27]. Theoreticalanalysis of network coding applied on unicast trans-missions can be found for example in [25]. This re-
sult however does not discuss practical routing andrate control issues. A system that proposes a practi-cal use of network coding on unicast transmissionsis COPE [16]. Unlike COPE, we apply coding to asingle flow, hence our approaches complement.
We said little about how to select routes to choosefrom. Although our specific implementation usedVRR [5], any route discovery protocol such asAODV [30], or DSR [15] can be used, (suitably mod-ified to allow multiple possible routes, e.g. throughcaching). Draves et al [9] look at three routing met-rics to determine best routes, finding that ETX per-forms best for static configurations, while simplehop-count does better when the sender is mobile.We could use quantities such as ETX in the packetscheduling determination algorithm.
The idea of spatial diversity has been exploiteda lot in the field of opportunistic scheduling andMIMO systems. Some theoretical aspects of spatialdiversity in networking, as a generalization of multi-path, is described in [21]. Some practical imple-mentations are addressed for example in [4, 10, 28].Multi-Radio Diversity system [28] studies diversityfrom client to multiple APs and tries to recover pack-ets from corrupted versions received on both APs.[10] also explores the possibilities of recovering par-tially received packets received on multiple pathsbut in a sensor network context. Our work is closeto ExOR [4], a mesh-networks’ routing protocol thatexploits spatial diversity. Compared to ExOR, oursignalling scheme is much simpler, and in additionwe perform load-balancing and ensure fairness.
6 Conclusions
In this paper we have proposed a scheme that usesmultiple paths effectively to increase the perfor-mance of wireless mesh networks. We have usednetwork coding and a novel credit based algorithm.Network coding eases the process of schedulingpacket transmissions, since nodes do not need to co-ordinate between themselves which packets to for-ward. The credit-based algorithm ensures that pathswith better performance carry most of the traffic,and, also, ensures fairness among multiple flows.
13
The scheme is motivated by extensive analyticalwork in the literature.
We have outlined the main challenges in design-ing our system, and used analysis and simulation todemonstrate the performance improvements of ourapproach, which can can double the throughput incertain cases. We have also built a prototype, testedon a small network, that further demonstrates thefeasibility and advantages of our proposal.
There are several issues that require further inves-tigation, and are currently being planned. We need amore detailed analytical evaluation. We also requirea fuller implementation of our ideas in a real system,with a corresponding evaluation in a real environ-ment. However, we believe that our results so farare very encouraging, and more than demonstrateproof of concept and potential benefits of multipathcode casting (mc2).
References
[1] R. Ahlswede, N. Cai, S.-Y. R. Li, and R. W. Ye-ung. Network information flow. IEEE Trans. onInformation Theory, 46:1204–1216, 2000.
[2] D. Andersen, H. Balakrishnan, F. Kaashoek,and R. Rao. Improving web availiability forclients with MONET. In NSDI, 2005.
[3] J. Bicket, D. Aguayo, S. Biswas, and R. Morris.Architecture and evaluation of an unplanned802.11b mesh network. In ACM MobiCom, 2005.
[4] S. Biswas and R. Morris. ExOR: opportunis-tic multi-hop routing for wireless networks. InACM SIGCOMM, 2005.
[5] M. Caesar, M. Castro, E. B. Nightingale,G. O’Shea, and A. Rowstron. Virtual ring rout-ing: network routing inspired by DHTs. In SIG-COMM, 2006.
[6] P. Chaporkar, K. Kar, and S. Sarkar. Through-put guarantees through maximal scheduling inwireless networks. In 43rd Allerton Conference,2005.
[7] P. A. Chou, Y. Wu, and K. Jain. Practical net-work coding. In Allerton Conference on Commu-nication, Control, and Computing, Oct 2003.
[8] C. de Lanois, B. Quoitin, and O. Bonaven-ture. Leveraging Internet path diversity andnetwork performances with IPv6 multihom-ing. Technical Report RR 2004-06, Universitecatholique de Louvain Tech. report RR 2004-06,2004.
[9] R. Draves, J. Padhye, and B. Zill. Comparisonof routing metrics for static multi-hop wirelessnetworks. In SIGCOMM, 2004.
[10] H. Dubois-Ferrière, D. Estrin, and M. Vetterli.Packet combining for sensor networks. In Pro-ceedings of ACM SenSys, 2005.
[11] C. Gkantsidis, J. Miller, and P. Rodriguez.Anatomy of a p2p content distribution systemwith network coding. In IPTPS, 2006.
[12] C. Gkantsidis and P. Rodriguez. Network cod-ing for large scale content distribution. In IEEEInfocom, 2005.
[13] K. Gummadi, H. Madhyastha, S. Gribble,H. Levy, and D. Wetherall. Improving the re-liability of Internet paths with one-hop sourcerouting. In OSDI, 2004.
[14] H. Han, S. Shakkottai, C. Hollot, R. Srikant, andD. Towsley. Overlay TCP for multi-path rout-ing and congestion control. IEEE/ACM Trans.Networking, December 2006.
[15] D. Johnson and D. A. Maltz. Dynamic sourcerouting in ad-hoc wireless networks. In MobileComputing, 1996.
[16] S. Katti, H. Rahul, W. Hu, D. Katabi,M. Medard, and J. Crowcroft. XORs in the air:practical wireless network coding. In ACM SIG-COMM, 2006.
[17] F. Kelly and T. Voice. Stability of end-to-end algorithms for joint routing and rate con-trol. Computer Communication Review, 35(2):5–12, 2005.
14
[18] F. P. Kelly, A. Maulloo, and D. Tan. Rate controlin communication networks: shadow prices,proportional fairness and stability. Journal of theOperational Research Society, 49:237–252, 1998.
[19] P. Key, L. Massoulié, and D. Towsley. Combin-ing multipath routing and congestion controlfor robustness. In CISS 2006, 2006.
[20] M. Kodialam, T. Lakshman, and S. Sengupta.Efficient and robust routing of highly variabletraffic. In HotNets, 2004.
[21] J. N. Laneman and G. Wornell. Exploiting dis-tributed spatial diversity in wireless networks.In Proceedings of 38th Allerton Conference, 2000.
[22] S. Lee and M. Gerla. Split multipath routingwith maximally disjoint paths in ad hoc net-works. In IEEE ICC, 2001.
[23] S.-Y. R. Li, R. W. Yeung, and N. Cai. Linear net-work coding. IEEE Transactions on InformationTheory, 2003.
[24] X. Lin, N. Shroff, and R. Srikant. A tutorial oncross-layer optimization in wireless networks.IEEE Journal on Selected Areas in Communica-tions, 24(8):1452–1463, June 2006.
[25] D. S. Lun, M. Medard, and M. Effros. On cod-ing for reliable communication over packet net-works. In Proc. 42nd Allerton Conference, 2004.
[26] M. Marina and S. Das. demand multipath dis-tance vector routing in ad hoc networks, 2001.
[27] M. Medard, R. Koetter, and P. A. Chou. Net-work coding: A new network design paradigm.In IEEE International Symposium on InformationTheory, Adelaide, Sep 2005.
[28] A. Miu, H. Balakrishnan, and C. E. Koksal.Improving loss resilience with multi-radio di-versity in wireless networks. In Proceedings ofACM/IEEE MobiCom, 2005.
[29] M. Moski and J. Garcia-Luna-Aceves. Multi-path routing in wireless mesh networks. InWiMesh 2005. IEEE, September 2005.
[30] C. E. Perkins and E. M. Royer. Ad-hoc on-demand distance vector routing. In 2nd IEEEWMCSA, 1999.
[31] L. Popa, C. Raiciu, I. Stoica, and D. Rosen-blum. Reducing congestion effects in wirelessnetworks by multipath routing. In ICNP. IEEE,November 2006.
[32] MIT roofnet - publications and trace data.http://pdos.csail.mit.edu/roofnet/doku.php?id=publications, 2005.
[33] L. Tassiulas and A. Ephremides. Stability prop-erties of constrained queueing systems andscheduling policies for maximum throughputin multihop radio networks. IEEE Trans. on Au-tomatic Control, 37(12), 1992.
[34] W.-H. Wang, M. Palaniswami, and S. Low. Op-timal flow control and routing in multi-pathnetworks. Performance Evaluation, 52, 2003.
[35] W. Xu and J. Rexford. MIRO: Multi-path Inter-domain ROuting. In ACM Sigcomm, 2006.
[36] R. Zhang-Shen and N. McKeown. "designinga predictable Internet backbone with valiantload-balancing. In IWQoS, 2005.
We now present a quick overview of the encodingand decoding operations involved in network cod-ing. The interested reader may find more informa-tion in [1, 7, 11, 12, 23, 27] and the references therein.
With network coding information is treated as analgebraic entity on which we can perform arithmeticoperations. We view each packet as a vector of ele-ments in a finite field. For example, a packet of sizeL that is composed as bytes b0b1b2 . . . bL, is treatedas the vector (b0, b1, . . . , bL), where each bi is nowtreated as an element in a Galois Field GF(28). Forthe purposes of this discussion, we assume that allpackets have the same size.
Assume that we have n packets; we representpacket i as ~bi = (11=i12=i . . . 1n=ibi1bi2 . . . biL)T ,where bik are the bytes of the original packet, and1j=i are indicator functions that are 1j=i = 1 iff i = jand 1j=i = 0 otherwise; the indicator functions are
15
using to identify the position of the packet in thestream of n packets. The first n entries of the vector(that contain the indicator functions) are also calledthe coefficient vector.
Assume now that the source or an intermediatenode has k packets, p1 through pk and wants to gen-erate a new encoded packet. In that case, it needsto generate k random elements, say α1 through αk,from the base arithmetic field (from GF(28) in ourcase) and compute the new encoded packet as fol-lows:
pnew = α1 · p1 + . . . + αk · pk .
(The operations are performed in the base arithmeticfield.) Observe that the coefficient vector (i.e. thefirst elements of the new packet) describes the en-coding of the new packet as a linear combination ofthe original n packets.
When the destination receives n linearly indepen-dent packets, i.e. packets with linearly independentcoefficient vectors, it can reconstruct the original in-formation using a process that resembles solving asystem of linear equations. Moreover, each node candecide whether to receive and store a packet basedon the coefficients vector; if the coefficient vector ofthe received packet can be expressed as a linear com-bination of the coefficient vectors that are alreadystored by the node, i.e. the received packet is redun-dant, then the packet is dropped.
A final note is due about our choice of the basearithmetic field. We have used a Galois Field GF(28)which has a size of 256 elements. The size of thefield is large enough to guarantee good diversity (atleast for networks of sizes of a few hundred nodes)and is small enough to allow efficient encoding anddecoding operations.
16
