XORs in The Air: Practical Wireless Network Coding
Sachin Katti
†
Hariharan Rahul
†
Wenjun Hu
Dina Katabi
†
Muriel M´edard
†
Jon Crowcroft
†
MIT CSAIL
Univ. of Cambridge
ABSTRACT
This paper proposes COPE, a new architecture for wireless mesh
networks. In addition to forwarding packets, routers mix (i.e., code)
packets from different sources to increase the information content
of each transmission. We show that intelligently mixing packets
increases network throughput. Our design is rooted in the theory
of network coding. Prior work on network coding is mainly theo-
retical and focuses on multicast traffic. This paper aims to bridge
theory with practice; it addresses the common case of unicast traf-
fic, dynamic and potentially bursty flows, and practical issues facing
the integration of network coding in the current network stack. We
evaluate our design on a 20-node wireless network, and discuss the
results of the first testbed deployment of wireless network coding.
The results show that COPE largely increases network throughput.
The gains vary from a few percent to several folds depending on the
traffic pattern, congestion level, and transport protocol.
Categories and Subject Descriptors
C.2.2 [Computer Systems Organization]: Computer-
Communications Networks
General Terms
Algorithms, Design, Performance, Theory
Keywords
Network Coding, Wireless Networks
1. INTRODUCTION
Wireless networks are indispensable; they provide the means for
mobility, city-wide Internet connectivity, distributed sensing, and
outdoor computing. Current wireless implementations, however,
suffer from a severe throughput limitation and do not scale to dense
large networks.
This paper presents COPE, a new forwarding architecture that
substantially improves the throughput of wireless networks. COPE
inserts a coding shim between the IP and MAC layers, which iden-
tifies coding opportunities and benefits from them by forwarding
multiple packets in a single transmission.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SIGCOMM’06, September 11–15, 2006, Pisa, Italy.
Copyright 2006 ACM 1-59593-308-5/06/0009 ...
$5.00.
(a) Current Approach
(b) COPE
Figure 1—A simple example of how COPE increases the throughput. It
allows Alice and Bob to exchange a pair of packets using 3 transmissions
instead of 4 (numbers on arrows show the order of transmission).
To give the reader a feel for how COPE works, we start with a
fairly simple example. Consider the scenario in Fig. 1, where Alice
and Bob want to exchange a pair of packets via a router. In current
approaches, Alice sends her packet to the router, which forwards
it to Bob, and Bob sends his packet to the router, which forwards
it to Alice. This process requires 4 transmissions. Now consider
a network coding approach. Alice and Bob send their respective
packets to the router, which XORs the two packets and broadcasts
the XOR-ed version. Alice and Bob can obtain each other’s packet
by XOR-ing again with their own packet. This process takes 3 trans-
missions instead of 4. Saved transmissions can be used to send new
data, increasing the wireless throughput.
In fact, COPE leads to larger bandwidth savings than are apparent
from this example. COPE exploits the shared nature of the wireless
medium which, for free, broadcasts each packet in a small neighbor-
hood around its path. Each node stores the overheard packets for a
short time. It also tells its neighbors which packets it has heard by
annotating the packets it sends. When a node transmits a packet, it
uses its knowledge of what its neighbors have heard to perform op-
portunistic coding; the node XORs multiple packets and transmits
them as a single packet if each intended nexthop has enough infor-
mation to decode the encoded packet. This extends COPE beyond
two flows that traverse the same nodes in reverse order (as in the
Alice-and-Bob example), and allows it to XOR more than a pair of
packets.
COPE’s design is based on two key principles.
• COPE disposes of the point-to-point abstraction and embraces
the broadcast nature of the wireless channel. Network design-
ers typically abstract the wireless channel as a point-to-point link,
then adapt forwarding and routing techniques designed for wired
networks for wireless. In contrast, COPE exploits the broadcast
property of radios instead of hiding it under an artificial abstrac-
tion.
• COPE employs network coding. Our work is rooted in the theory
of network coding, which allows the routers to mix the informa-
tion content in the packets before forwarding them. Prior work
on network coding is mainly theoretical and focuses on multicast
traffic [2, 26, 20, 24, 17, 18, 27, 11]. Ours bridges theory with
practice; it addresses the common case of unicast traffic, dynamic
and potentially bursty flows, and practical issues facing the inte-
gration of network coding in the current network stack.
We have introduced the idea of opportunistic wireless network
coding in an invited paper in Allerton 2005 [23]. This paper departs
from our previous paper and all prior work on network coding in
three main ways:
(1) This paper presents the first system architecture for wireless net-
work coding. It articulates a full-fledged design that integrates seam-
lessly into the current network stack, works with both TCPand UDP
flows, and runs real applications.
(2) The paper also implements the design in the Linux kernel and the
Roofnet platform [1]. The implementation is deployed on a 20-node
wireless testbed, creating the first deployment of network coding in
a wireless network.
(3) The paper studies the performance of COPE, and reveals its in-
teractions with the wireless channel, routing, and higher layer pro-
tocols. Our findings can be summarized as follows:
• Network coding does have practical benefits, and can substan-
tially improve wireless throughput.
• When the wireless medium is congested and the traffic consists of
many random UDP flows, COPE increases the throughput of our
testbed by 3-4x.
• If the traffic does not exercise congestion control (e.g., UDP),
COPE’s throughput improvement may substantially exceed the
expected theoretical coding gain. This additional gain occurs be-
cause coding makes a router’s queue smaller, reducing the prob-
ability that a congested downstream router will drop packets that
have already consumed network resources.
• For a mesh network connected to the Internet via an access point,
the throughput improvement observed with COPE varies depend-
ing on the ratio between total download and upload traffic travers-
ing the access point, and ranges from 5% to 70%.
• Hidden terminals create a high collision rate that cannot be
masked even with the maximum number of 802.11 retransmis-
sions. In these environments, TCP does not send enough to utilize
the medium, and thus does not create coding opportunities. With
no hidden terminals, TCP’s throughput increases by an average of
38% in our testbed.
2. BACKGROUND AND RELATED WORK
The idea underlying network coding is usually illustrated using
the famous butterfly example [2]. Consider the network in Fig. 2,
where source S
1
wants to deliver the stream of messages a
i
to both
R
1
and R
2
, and source S
2
wants to send the stream of messages b
i
to the same two receivers. Assume all links have a capacity of one
message per unit of time. If routers only forward the messages they
receive, the middle link will be a bottleneck, which for every time
unit, can either deliver a
i
to R
1
or b
i
to R
2
. In contrast, if the router
feeding the middle link XORs the two messages and sends a
i
⊕ b
i
(or any linear combination of a
i
and b
i
), as shown in the figure, both
receivers obtain two messages in every time unit. Thus, network
Figure 2—A simple scenario showing how network coding improves
throughput. All links have a capacity of one message per unit of time.
By sending the XOR of a
i
and b
i
on the middle link, we can deliver two
messages per unit of time to both receivers.
Term Definition
Native Packet A non-encoded packet
Encoded or XOR-ed
Packet
A packet that is the XOR of multiple native
packets
Nexthops of an En-
coded Packet
The set of nexthops for the native packets
XOR-ed to generate the encoded packet
Packet Id A 32-bit hash of the packet’s IP source ad-
dress and IP sequence number
Output Queue A FIFO queue at each node, where it keeps
the packets it needs to forward
Packet Pool A buffer where a node stores all packets heard
in the past T seconds
Coding Gain The ratio of the number of transmissions re-
quired by the current non-coding approach, to
the number of transmissions used by COPE to
deliver the same set of packets.
Coding+MAC Gain The expected throughput gain with COPE
when an 802.11 MAC is used, and all nodes
are backlogged.
Table 1—Definitions of terms used in this paper.
coding, i.e., allowing the routers to mix the bits in forwarded mes-
sages, can increase network throughput.
Work on network coding started with a pioneering paper by
Ahlswede et al. [2], who showed that having the routers mix infor-
mation in different messages allows the communication to achieve
multicast capacity. This was soon followed by the work of Li et
al., who showed that, for multicast traffic (e.g., the butterfly sce-
nario), linear codes are sufficient to achieve the maximum capacity
bounds [26]. Koetter and M´edard [24] presented polynomial time
algorithms for encoding and decoding, and Ho et al. extended these
results to random codes [17]. Some recent work studied wireless
network coding [11, 31]. In particular, Lun et al. studied network
coding in the presence of omni-directional antennae and showed that
the problem of minimizing the communication cost can be formu-
lated as a linear program and solved in a distributed manner [28].
All of this work is primarily theoretical and assumes multicast traf-
fic. A few papers study specific unicast topologies showing that,
for the studied scenario, network coding results in better throughput
than pure forwarding [39, 16, 37]. This paper aims to bridge the gap
between the theory of network coding and practical network design
and provide an operational protocol for general unicast traffic.
Finally, a rich body of systems research has tackled the problem
of improving the throughput of wireless networks. The proposed
solutions range from designing better routing metrics [10, 5, 12]
to tweaking the TCP protocol [33], and include improved routing
and MAC protocols [6, 22, 15]. Our work builds on these founda-
tions but adopts a fundamentally different approach; it explores the
utility of network coding in improving the throughput of wireless
networks.
(a) B can code packets it wants to send (b) Nexthops of packets in B’s queue (c) Possible coding options
Figure 3—Example of Opportunistic Coding; Node B has 4 packets in its queue, whose nexthops are listed in (b). Each neighbor of B has stored
some packets as depicted in (a). Node B can make a number of coding decisions (as shown in (c)), but should select the last one because it maximizes
the number of packets delivered in a single transmission.
3. COPE OVERVIEW
We introduce COPE, a new forwarding architecture for wireless
mesh networks. It inserts a coding layer between the IP and MAC
layers, which detects coding opportunities and exploits them to for-
ward multiple packets in a single transmission. Before delving into
details, we refer the reader to Table 1, which defines the terms used
in the rest of the paper.
COPE incorporates three main techniques:
(a) Opportunistic Listening: Wireless is a broadcast medium, cre-
ating many opportunities for nodes to overhear packets when they
are equipped with omni-directional antennae. COPE sets the nodes
in promiscuous mode, makes them snoop on all communications
over the wireless medium and store the overheard packets for a lim-
ited period T (the default is T = 0.5s).
In addition, each node broadcasts reception reports to tell its
neighbors which packets it has stored. Reception reports are sent
by annotating the data packets the node transmits. A node that has
no data packets to transmit periodically sends the reception reports
in special control packets.
(b) Opportunistic Coding: The key question is what packets to
code together to maximize throughput. A node may have multiple
options, but it should aim to maximize the number of native packets
delivered in a single transmission, while ensuring that each intended
nexthop has enough information to decode its native packet.
The above is best illustrated with an example. In Fig. 3(a), node
B has 4 packets in its output queue p
1
, p
2
, p
3
, and p
4
. Its neighbors
have overheard some of these packets. The table in Fig 3(b) shows
the nexthop of each packet in B’s queue. When the MAC permits B
to transmit, B takes packet p
1
from the head of the queue. Assuming
that B knows which packets each neighbor has, it has a few coding
options as shown in Fig. 3(c). It could send p
1
⊕ p
2
. Since node C
has p
1
in store, it could XOR p
1
with p
1
⊕ p
2
to obtain the native
packet sent to it, i.e., p
2
. However, node A does not have p
2
, and so
cannot decode the XOR-ed packet. Thus, sending p
1
⊕ p
2
would be
a bad coding decision for B, because only one neighbor can benefit
from this transmission. The second option in Fig.3(c) shows a better
coding decision for B. Sending p
1
⊕ p
3
would allow both neighbors
C and A to decode and obtain their intended packets from a single
transmission. Yet the best coding decision for B would be to send
p
1
⊕ p
3
⊕ p
4
, which would allow all three neighbors to receive their
respective packets all at once.
The above example emphasizes an important coding issue. Pack-
ets from multiple unicast flows may get encoded together at some
intermediate hop. But their paths may diverge at the nexthop, at
which point they need to be decoded. If not, unneeded data will
be forwarded to areas where there is no interested receiver, wasting
much capacity. The coding algorithm should ensure that all nex-
thops of an encoded packet can decode their corresponding native
packets. This can be achieved using the following simple rule:
To transmit n packets, p
1
,..., p
n
,ton nexthops, r
1
, ...,r
n
,
a node can XOR the n packets together only if each
next-hop r
i
has all n − 1 packets p
j
for j = i.
This rule ensures that each nexthop can decode the XOR-ed version
to extract its native packet. Whenever a node has a chance to trans-
mit a packet, it chooses the largest n that satisfies the above rule to
maximize the benefit of coding.
(c) Learning Neighbor State: But how does a node know what
packets its neighbors have? As explained earlier, each node an-
nounces to its neighbors the packets it stores in reception reports.
However, at times of severe congestion, reception reports may get
lost in collisions, while at times of light traffic, they may arrive too
late, after the node has already made a suboptimal coding decision.
Therefore, a node cannot rely solely on reception reports, and may
need to guess whether a neighbor has a particular packet.
To guess intelligently, we leverage the routing computation.
Wireless routing protocols compute the delivery probability between
every pair of nodes and use it to identify good paths. For e.g.,
the ETX metric [10] periodically computes the delivery probabili-
ties and assigns each link a weight equal to 1/(delivery probability).
These weights are broadcast to all nodes in the network and used by
a link-state routing protocol to compute shortest paths. We lever-
age these probabilities for guessing. In the absence of deterministic
information, COPE estimates the probability that a particular neigh-
bor has a packet as the delivery probability of the link between the
packet’s previous hop and the neighbor.
Occasionally, a node may make an incorrect guess, which causes
the coded packet to be undecodable at some nexthop. In this case,
the relevant native packet is retransmitted, potentially encoded with
a new set of native packets.
4. UNDERSTANDING COPE’S GAINS
How beneficial is COPE? Its throughput improvement depends
on the existence of coding opportunities, which themselves depend
on the traffic patterns. This section provides some insight into the
expected throughput increase and the factors affecting it.
4.1 Coding Gain
We defined the coding gain as the ratio of the number of transmis-
sions required by the current non-coding approach, to the minimum
n
0
n
1
n
2
n
N-1
n
N
(a) Chain topology; 2 flows in reverse directions.
(b) “X” topology (c) Cross topology
2 flows intersecting at n
2
. 4 flows intersecting at n
2
(d) Wheel topology; many flows intersecting at the center node.
Figure 4—Simple topologies to understand COPE’s Coding and Cod-
ing+MAC Gains.
number of transmissions used by COPE to deliver the same set of
packets. By definition, this number is greater than or equal to 1.
In the Alice-and-Bob experiment, as described in §1, COPE re-
duces the number of transmissions from 4 to 3, thus producing a
coding gain of
4
3
= 1.33.
But what is the maximum achievable coding gain, i.e., what is
the theoretical capacity of a wireless network that employs COPE?
The capacity of general network coding for unicast traffic is still
an open question for arbitrary graphs [38, 16]. However, we ana-
lyze certain basic topologies that reveal some of the factors affecting
COPE’s coding gain. Our analysis assumes identical nodes, omni-
directional radios, perfect hearing within some radius, and the signal
is not heard at all outside this radius, and if a pair of nodes can hear
each other the routing will pick the direct link. Additionally, we
assume that the flows are infinite and we only consider the steady
state.
T
HEOREM 4.1. In the absence of opportunistic listening,
COPE’s maximum coding gain is 2, and it is achievable.
We prove the theorem by showing that the coding gain of the chain
in Fig. 4(a) tends to 2 as the number of intermediate nodes increases.
The complete proof is in Appendix A.
While we do not know the maximum gain for COPE with op-
portunistic listening, there do exist topologies where opportunistic
listening adds to the power of COPE. For example, consider the
“X”-topology shown in Fig. 4(b). This is the analogy of the Alice-
and-Bob topology, but the two flows travel along link-disjoint paths.
COPE without opportunistic listening cannot achieve any gains on
this topology. But with opportunistic listening and guessing, the
middle node can combine packets traversing in opposite directions,
for a coding gain of
4
3
= 1.33. This result is important, because
in a real wireless network, there might be only a small number of
flows traversing the reverse path of each other `a la Alice-and-Bob,
but one would expect many flows to intersect at a relay, and thus can
be coded together using opportunistic listening and guessing.
The “X” and Alice-and-Bob examples can be combined to further
improve the benefits of coding, as in the cross topology of Fig. 4(c).
Without coding, 8 transmissions are necessary for each flow to send
one packet to its destination. However, assuming perfect overhear-
ing (n
4
and n
5
can overhear n
1
and n
3
, and vice versa), n
2
can XOR
4 packets in each transmission, thus reducing the number of trans-
missions from 8 to 5, producing a coding gain of
8
5
= 1.6.
We observe that while this section has focused on theoretical
bounds, the gains in practice tend to be lower due to the availability
of coding opportunities, packet header overheads, medium losses,
etc. However, it is important to note that COPE increases the actual
information rate of the medium far above the bit rate, and hence its
benefits are sustained even when the medium is fully utilized. This
contrasts with other approaches to improving wireless throughput,
such as opportunistic routing [6], which utilize the medium better
when it is not fully congested, but do not increase its capacity.
4.2 Coding+MAC Gain
When we ran experiments with COPE, we were surprised to see
that the throughput improvement sometimes greatly exceeded the
coding gain for the corresponding topology. It turns out that the
interaction between coding and the MAC produces a beneficial side
effect that we call the Coding+MAC gain.
The Coding+MAC gain is best explained using the Alice-and-Bob
scenario. Because it tries to be fair, the MAC divides the bandwidth
equally between the 3 contending nodes: Alice, Bob, and the router.
Without coding, however, the router needs to transmit twice as many
packets as Alice or Bob. The mismatch between the traffic the router
receives from the edge nodes and its MAC-allocated draining rate
makes the router a bottleneck; half the packets transmitted by the
edge nodes are dropped at the router’s queue. COPE allows the bot-
tleneck router to XOR pairs of packets and drain them twice as fast,
doubling the throughput of this network. Thus, the Coding+MAC
gain of the Alice-and-Bob topology is 2.
The Coding+MAC gain assumes all nodes continuously have
some traffic to send (i.e., backlogged), but are limited by their MAC-
allocated bandwidth. It computes the throughput gain with COPE
under such conditions. For topologies with a single bottleneck,
like the Alice-and-Bob’s, the Coding+MAC gain is the ratio of the
bottleneck’s draining rate with COPE to its draining rate without
COPE.
Similarly, for the “X” and cross topologies, the Coding+MAC
gain is higher than the coding gain. For the “X”, the Coding+MAC
gain is 2 since the bottleneck node is able to drain twice as many
packets, given its MAC allocated rate. For the cross topology, the
Coding+MAC gain is even higher at 4. The bottleneck is able to
send 4 packets out in each transmission, hence it is able to drain
four times as many packets compared to no coding. This begs the
question: what is the maximum Coding+MAC gain? The maxi-
mum possible Coding+MAC gains with and without opportunistic
listening are properties of the topology and the flows that exist in
a network. Here we prove some upper bounds on Coding+MAC
gains.
T
HEOREM 4.2. In the absence of opportunistic listening,
COPE’s maximum Coding+MAC gain is 2, and it is achievable.
Topology Coding Gain Coding+MAC Gain
Alice-and-Bob 1.33 2
“X” 1.33 2
Cross 1.6 4
Infinite Chain 2 2
Infinite Wheel 2 ∞
Table 2—Theoretical gains for a few basic topologies.
The proof is in Appendix B.
T
HEOREM 4.3. In the presence of opportunistic listening,
COPE’s maximum Coding+MAC gain is unbounded.
The proof, detailed in Appendix C, uses the wheel topology in
Fig. 4(d). Assuming N edge nodes, with COPE the bottleneck node,
in the center of the wheel, XORs N packets together, and conse-
quently drains its queue N times faster than without COPE. As the
number of edge nodes increases, i.e., N →∞, the gain becomes in-
finite. While the previous example is clearly artificial, it does illus-
trate the potential of COPE with opportunistic listening to produce
a several-fold improvement in throughput, as in §7.3.
Table 2 lists the gains for a few basic topologies.
5. MAKING IT WORK
In order to integrate COPE effectively within the current network
stack, we need to address some important system issues.
5.1 Packet Coding Algorithm
To build the coding scheme, we have to make a few design deci-
sions. First, we design our coding scheme around the principle of
never delaying packets. When the wireless channel is available, the
node takes the packet at the head of its output queue, checks which
other packets in the queue may be encoded with this packet, XORs
those packets together, and broadcasts the XOR-ed version. If there
are no encoding opportunities, our node does not wait for the arrival
of a matching codable packet. COPE therefore lets the node oppor-
tunistically overload each transmission with additional information
when possible, but does not wait for additional codable packets to
arrive.
Second, COPE gives preference to XOR-ing packets of similar
lengths, because XOR-ing small packets with larger ones reduces
bandwidth savings. Empirical studies show that the packet-size
distribution in the Internet is bimodal with peaks at 40 and 1500
bytes [29]. We can therefore limit the overhead of searching for
packets with the right sizes by distinguishing between small and
large packets. We might still have to XOR packets of different sizes.
In this case, the shorter packets are padded with zeroes. The receiv-
ing node can easily remove the padding by checking the packet-size
field in the IP header of each native packet.
Third, notice that COPE will never code together packets headed
to the same nexthop, since the nexthop will not be able to decode
them. Hence,while coding, we only need to consider packets headed
to different nexthops. COPE therefore maintains two virtual queues
per neighbor; one for small packets and another for large packets
(The default setting uses a threshold of 100 bytes). When a new
packet is added to the output queue, an entry is added to the appro-
priate virtual queue based on the packet’s nexthop and size.
Searching for appropriate packets to code is efficient due to the
maintenance of virtual queues. When making coding decisions,
COPE first dequeues the packet at the head of the FIFO output
queue, and determines if it is a small or a large packet. Depending
on the size, it looks at the appropriate virtual queues. For example,
if the packet dequeued is a small packet, COPE first looks at the
virtual queues for small packets. COPE looks only at the heads of
the virtual queues to limit packet reordering. After exhausting the
virtual queues of a particular size, the algorithm then looks at the
heads of virtual queues for packets of the other size. Thus for find-
ing appropriate packets to code COPE has to look at 2M packets in
the worst case, where M is the number of neighbors of a node.
Another concern is packet reordering. We would like to limit re-
ordering packets from the same flow because TCP mistakes it as a
congestion signal. Thus, we always consider packets according to
their order in the output queue. Still, reordering may occur because
we prefer to code packets of the same size. In practice, this reorder-
ing is quite limited because most data packets in a TCPflow are large
enough to be queued in the large-packet queue, and thus be consid-
ered in order. We will see in §5.4, however, that reordering might
arise from other reasons, particularly the need to retransmit a packet
that has been lost due to a mistake in guessing what a neighbor can
decode. Thus, we choose to deal with any reordering that might hap-
pen inside the network at the receiver. COPE has a module that puts
TCP packets in order before delivering them to the transport layer
as explained in §5.5.
Finally, we want to ensure that each neighbor to whom a packet
is headed has a high probability of decoding its native packet. Thus,
for each packet in its output queue, our relay node estimates the
probability that each of its neighbors has already heard the packet.
Sometimes the node can be certain about the answer, for example,
when the neighbor is the previous hop of the packet, or when the
reception reports from the neighbor state so. When neither of the
above is true, the node leverages the delivery probabilities computed
by the routing protocol; it estimates the probability the neighbor has
the packet as the delivery probability between the packet’s previous
hop and that neighbor. The node then uses this estimate to ensure
that encoded packets are decodable by all of their nexthops with
high probability.
In particular, suppose the node encodes n packets together. Let
the probability that a nexthop has heard packet i be P
i
. Then, the
probability, P
D
, that it can decode its native packet is equal to the
probability that it has heard all of the n − 1 native packets XOR-ed
with its own, i.e.,
P
D
= P
1
× P
2
× ...× P
n−1
.
Consider an intermediate step while searching for coding candi-
dates. We have already decided to XOR n − 1 packets together,
and are considering XOR-ing the n
th
packet with them. The coding
algorithm now checks that, for each of the n nexthops, the decod-
ing probability P
D
, after XOR-ing the n
th
packet with the rest stays
greater than a threshold G (the default value G = 0.8). If the above
conditions are met, each nexthop can decode its packet with at least
probability G. Finally, we note that for fairness we iterate over the
set of neighbors according to a random permutation.
Formally, each node maintains the following data structures.
• Each node has a FIFO queue of packets to be forwarded, which
we call the output queue.
• For each neighbor, the node maintains two per-neighbor virtual
queues, one for small packets (e.g., smaller than 100 bytes), and
the other for large packets. The virtual queues for a neighbor A
contain pointers to the packets in the output queue whose nexthop
is A.
• Additionally, the node keeps a hash table, packet info, that is
keyed on packet-id. For each packet in the output queue, the table
indicates the probability of each neighbor having that packet.
Whenever the MAC signals a sending opportunity, the node executes
the procedure illustrated in Alg. 1.
