Routing in a Delay Tolerant Network
Sushant Jain
University of Washington
sushjain@cs.washington.edu
Kevin Fall
Intel Research, Berkeley
kfall@intel.com
Rabin Patra
University of California, Berkeley
rkpatra@cs.berkeley.edu
ABSTRACT
We formulate the delay-tolerant networking routing problem,
where messages are to be moved end-to-end across a connec-
tivity graph that is time-varying but whose dynamics may be
known in advance. The problem has the added constraints of
finite buffers at each node and the general property that no con-
temporaneous end-to-end path may ever exist. This situation
limits the applicability of traditional routing approaches that
tend to treat outages as failures and seek to find an existing
end-to-end path. We propose a framework for evaluating rout-
ing algorithms in such environments. We then develop several
algorithms and use simulations to compare their performance
with respect to the amount of knowledge they require about
network topology. We find that, as expected, the algorithms
using the least knowledge tend to perform poorly. We also find
that with limited additional knowledge, far less than complete
global knowledge, efficient algorithms can be constructed for
routing in such environments. To the best of our knowledge
this is the first such investigation of routing issues in DTNs.
Categories and Subject Descriptors:
C.2.2: Routing Protocols
General Terms: Algorithms, Performance
Keywords: Routing, Delay Tolerant Network
1. INTRODUCTION
In this work, we look at the problem of routing in a de-
lay tolerant network (DTN)[8]. Such networks are assumed to
experience frequent, long-duration partitioning and may never
have an end-to-end contemporaneous path. This problem con-
trasts with routing in conventional data networks which typ-
ically selects a shortest policy-compliant path in a connected
graph without considering availability of intermediate buffer-
ing and bandwidth capacity.
In graph theoretic terms, our problem is a form of the “quick-
est transshipment problem” in which both edge capacities and
transit delays along an edge can vary (down to zero) as a func-
tion of time and nodes have finite buffers [12]. In practical
terms, DTNs arise in networks with known connectivity pat-
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’04, Aug. 30–Sept. 3, 2004, Portland, Oregon, USA.
Copyright 2004 ACM 1-58113-862-8/04/0008 ...$5.00.
terns such as Low-Earth Orbiting Satellites (LEO) or those
with unpredicted, opportunistic connectivity (e.g., communi-
cation among PDAs when brought into close proximity [5]).
Here, we focus on the former case.
The routing problem in a DTN may at first appear as the
standard problem of dynamic routing but with extended link
failure times. This is not the case. For the standard dynamic
routing problem, the topology is assumed to be connected (or
partitioned for very short intervals), and the objective of the
routing algorithm is to find the best currently-available path
to move traffic end-to-end. In a DTN, however, an end-to-
end path may be unavailable at all times; routing is performed
over time to achieve eventual delivery by employing long-term
storage at the intermediate nodes. The DTN routing problem
amounts to a constrained optimization problem where edges
may be unavailable for extended periods of time and a stor-
age constraint exists at each node. This formulation reveals
DTN routing to be a considerably different and more challeng-
ing problem.
In this paper, we make several contributions: we first moti-
vate and formulate the DTN routing problem when the connec-
tivity patterns are known, then provide a framework for evalu-
ating various routing algorithms, and finally show a simulation-
based comparison of several of our own algorithms. We also
include an optimal algorithm based on a linear programming
approach to serve as a basis for comparison with the simula-
tions. Finally, we outline the future work to be accomplished
in the area.
2. EXAMPLE: CONNECTING A REMOTE
VILLAGE
The problem of providing data communications to remote
and rural areas is beginning to attract the attention of the
computer systems research community [23]. While many rural
connectivity projects involve attempts to provide conventional
Internet access to remote areas, a small number of projects are
taking an alternative approach which focuses on asynchronous
messaging in order to greatly reduce the cost of connectivity [25,
20, 23]. For example, the Wizzy Digital Courier service pro-
vides asynchronous (disconnected) Internet access to schools in
remote villages of South Africa [25]. In this system, a courier
on a motorbike, equipped with a USB storage device, travels
from a village school to a large city which has permanent (rea-
sonably high-speed) Internet connectivity. Typically, it takes a
few hours for the courier to travel from the village to the city.
In consideration of this scenario, we realize that several other
connectivity options may be available (e.g. satellites, either
LEO or GEO, possibly telephone), but are not likely to be cost
Session 4: Wireless and Delay-Tolerant Networks
145
Village
City
Bike
Dialup
Telephone
Internet
LEO
Satellite
Figure 1: Scenario illustrating a variety of connectivity op-
tions between a remote village and a city. Even in this
simple scenario, many route choices are possible.
effective or of sufficient capacity to handle all of the traffic.
Conversely, for some traffic, such as high-priority alerts, low
latency may be sufficiently important to justify using a higher-
cost communication system offering smaller delay. Thus, we
consider a simple extended scenario, based on this real-world
example, that motivates the DTN routing problem.
Figure 1 shows a hypothetical village served by a digital
courier, a wired dialup Internet connection, and a store-and-
forward LEO satellite (e.g. PACSAT). These satellites have
low to moderate bandwidth (around 10 Kbps) and are visible
for 4-5 short periods of time (“passes”) per day (lasting around
10 minutes per pass, depending on the orbit inclination and
location on Earth). We call the opportunity to communicate
a contact (as in [8]), which is characterized by a duration of
time, a capacity, and a propagation delay (assumed to remain
constant during the contact duration). In addition, depending
on the type of connection used, buffering constraints may also
need to be considered.
1
The digital courier service represents a
high-bandwidth, high-latency contact, the dialup represents a
low-bandwidth, low-latency contact, and the LEO satellite rep-
resents a moderate-bandwidth, moderate-latency contact. The
problem of selecting which contacts to carry messages and when
represents an instance of the DTN routing problem. Route se-
lection may depend on a variety of factors including message
source and destination, size, time of request, available contacts,
traffic in the system, or other factors (e.g. cost, delay, etc.).
In the next sections we develop a set of definitions and a
framework for evaluating DTN routing algorithms. We then
propose several of our own routing algorithms and use the
framework in conjunction with simulations to evaluate their
performance in the context of this village scenario.
3. DTN NETWORK MODEL
Nodes and Edges
The DTN graph is a directed multi-graph,
in which more than one edge (also called link) may exist be-
tween a pair of nodes (see Figure 2). The reason for using a
multigraph is straightforward: it may be possible to select be-
tween two distinct (physical) connection types to move data be-
tween the same pair of nodes. Furthermore, the link capacities
(and to a lesser extent, propagation delay) are time-dependent
(capacity is zero at times when the link is unavailable). Thus,
the set of edges in the graph must capture both time-varying ca-
pacity and propagation delay as well as multiple parallel edges.
A simple example of an edge captured by this description
involves a ground station and a LEO satellite rising, passing
directly overhead, and setting at the opposite horizon. As it
1
The PACSAT satellite systems have limited file storage.
u v
e
1
e
2
e
3
e
n
=((u,v)
n
,c(t),d(t))
b
u
storage
capacity
b
v
source
desitnation
Figure 2: Edges in a DTN graph. Nodes may be con-
nected by multiple edges, representing different physical
links. Each node j performs store-and-forward routing, and
has finite storage capacity (b
j
). An edge is parameterized
by its source and destination nodes plus a capacity (c(t))
and delay function (d(t)).
rises, its channel capacity will generally increase until it is di-
rectly overhead and will decrease for the remaining time of the
pass. This is because noise is minimal when the satellite is
directly overhead but increases at lower elevations. Another
example would be a bus (carrying a wireless access point) pass-
ing by a village. The throughput of the wireless link would
depend upon the distance of the bus from the village. When no
communication is possible, the edge is assigned zero capacity.
Contact
A contact is an opportunity to send data over an
edge. More precisely, it is a specific edge and a corresponding
time interval during which the edge capacity is strictly positive.
Messages
Communication demands are represented by mes-
sages. A message is a tuple (u, v, t, m), where u is the source
of the message, v is the destination, t is the time at which the
message is injected into the system and m is its size (messages
can be of arbitrary size). The set of all messages is called the
traffic demand.
Storage The nodes in a DTN have finite long-term stor-
age (buffers) used for holding in-transit data or data waiting
to be consumed by the application at a destination node. In
our model, the storage is exclusively used for holding in-transit
data. Destination nodes are assumed to have sufficient capacity
for holding data to be consumed by an application.
Routing Routing occurs in a store and forward fashion.
The routing algorithm is responsible for determining the next
edge(s) that a message should be forwarded along. Messages
not immediately forwarded wait until they are assigned to con-
tacts by the routing algorithm.
4. DTN ROUTING ISSUES
In this section, we consider a number of important issues in
any routing algorithm: the routing objective, the amount of
knowledge about the network required by the scheme, when
routes are computed, the use of multiple paths, and the use
of source routing. We focus on how these issues arise in the
context of the DTN routing problem.
4.1 Routing Objective
The routing objective of traditional routing schemes has been
to select a path which minimizes some simple metric (e.g. the
number of hops). For DTN networks, however, the most desir-
able objective is not immediately obvious.
One natural objective is to maximize the probability of mes-
sage delivery. Messages could potentially be lost due to creation
of a routing loop or the forced discarding of data when buffers
are exhausted. As an approximation, we focus on minimizing
the delay of a message (the time between when it is injected
and when it is completely received).
146
While DTN applications are expected to be tolerant of delay,
this does not mean that they would not benefit from decreased
delay. Furthermore, we believe this metric is an appropriate
measure to use in exploring the differential evaluation of sev-
eral routing algorithms in an application-independent manner.
Minimizing delay lowers the time messages spend in the net-
work, reducing contention for resources (in a qualitative sense).
Therefore, lowering delay indirectly improves the probability of
message delivery. This is validated by our simulation results.
4.2 Proactive Routing vs. Reactive Routing
In proactive routing, routes are computed automatically and
independently of traffic arrivals. Most Internet standard rout-
ing protocols and some ad-hoc protocols such as DSDV (Des-
tination Sequenced Distance Vector) and OLSR (Optimized
Link-State Routing) are examples of this style [4]. In a DTN,
these protocols are capable of computing routes for a connected
subgraph of the overall DTN topology graph. They fail when
asked to provide paths to nodes which are not currently reach-
able. Despite this drawback, proactive network-layer routing
protocols may provide useful input to DTN routing algorithm
by providing the set of currently-reachable nodes from which
DTN routing may select preferred next hops.
In reactive routing, routes are discovered on-demand when
traffic must be delivered to an unknown destination. Ad-hoc
routing protocols such as AODV (Ad-hoc On-demand Distance
Vector) and DSR (Dynamic Source Routing) are examples of
this style [4]. In these systems, a route discovery protocol is
employed to determine routes to destinations on-demand, in-
curring additional delay. These protocols work best when com-
munication patterns are relatively sparse. For a DTN, as with
the proactive protocols, these protocols work only for finding
routes in a connected subgraph of the overall DTN routing
graph. However, they fail in a different way than the proac-
tive protocols. In particular, they will simply fail to return a
successful route (from a lack of response), whereas the proac-
tive protocols can potentially fail more quickly (by determining
that the requested destination is not presently reachable).
In a DTN, routes may vary with time in predictable ways and
can be precomputed using knowledge about future topology dy-
namics. Employing a proactive approach would likely involve
computing several sets of routes and indexing them by time.
The associated resource requirements would be prohibitive un-
less the traffic demand is large and a large percentage of the
possible network nodes exchange traffic. Otherwise, a reactive
approach would be more attractive.
A related issue is route stability, a measure of how long the
currently-known routes are valid. Route stability depends on
the rate of topological change. With relatively stable routes one
can employ route caching to avoid unnecessary routing protocol
exchanges. With future knowledge about topology changes,
caching could be especially effective in a DTN because it may
be possible to know ahead of time exactly when to evict existing
cached route entries.
4.3 Source Routing vs Per-hop Routing
In source routing the complete path of a message is deter-
mined at the source node, and encoded in some way in the
message. The route is therefore determined once and does not
change as the message traverses the network. In contrast, in
per-hop routing the next-hop of a message is determined at
each hop along its forwarding path. Per-hop routing allows
a message to utilize local information about available contacts
and queues at each hop, which is typically unavailable at the
+
Zero
Knowledge Oracles
Performance
Increasing knowledge
Algorithms
Queuing
Contacts
Contacts
EDLQ
Contacts
+
Queuing
+
Traffic
Demand
ED
Summary
Contacts
EDAQ
LP
FC
MED
Figure 3: Conceptual performance vs knowledge trade-off.
The x-axis depicts the amount of knowledge (increasing in
the positive direction). The y-axis depicts the expected
performance that can be achieved using a certain amount
of knowledge. The figure shows that more knowledge is
required to attain better performance. Labels on top show
algorithms developed in this paper using the corresponding
oracles.
source. Thus, per-hop routing may lead to better performance.
Unfortunately, due to its local nature, it may lead to loops when
nodes have different topological views (e.g. due to incomplete
or delayed routing information).
4.4 Message Splitting
A message is split when forwarded in such a way that dif-
ferent parts (fragments) are routed along different paths (or
across different contacts on the same path). This technique
may reduce the delay or improve load balancing among multi-
ple links. It is particularly relevant in DTNs because messages
can be arbitrarily large and may not fit in a single contact.
However, splitting complicates routing because, in addition to
determining the sizes of the fragments, we also have to deter-
mine corresponding paths for the fragments.
5. ROUTING EVALUATION FRAMEWORK
5.1 Knowledge Oracles
The DTN routing problem has many input variables such
as dynamic topology characteristics and traffic demand. Com-
plete knowledge of these variables facilitates the computation
of optimal routes. However, with partial knowledge, the abil-
ity to compute optimal routes is hampered, and the perfor-
mance of the resultant routing is expected to be inferior. To un-
derstand this fundamental trade-off between performance and
knowledge, we create a set of abstract knowledge oracles, each
able to answer questions we ask of them. These oracles are
notational elements used to encapsulate particular knowledge
about the network required by different algorithms.
A key objective of our study is to understand the relationship
between algorithm performance and the use of these oracles.
Figure 3 illustrates this conceptually by showing the expected
performance and oracle requirements for each proposed routing
algorithm:
Contacts Summary Oracle
This oracle can answer questions
about aggregate statistics of the contacts. In particular, the
contacts summary oracle provides the average waiting time un-
til the next contact for an edge. Thus, the contacts summary
oracle can only respond with time-invariant or summary char-
acteristics about contacts.
Contacts Oracle This oracle can answer any question regard-
ing contacts between two nodes at any point in time. This is
147
equivalent to knowing the time-varying DTN multi-graph. The
contacts summary oracle can be constructed using the contacts
oracle, but not vice versa.
Queuing Oracle
This oracle gives information about instan-
taneous buffer occupancies (queuing) at any node at any time,
and can be used to route around congested nodes. Unlike the
other oracles, the queuing oracle is affected by both new mes-
sages arriving in the system and the choices made by the routing
algorithm itself. We expect it to be the most difficult oracle to
realize in a distributed system.
Traffic Demand Oracle This oracle can answer any question
regarding the present or future traffic demand. It is able to
provide the set of messages injected into the system at any
time.
5.2 Routing Algorithm Classes
We now present different routing algorithms (Table 1 gives
an overview). They fall into the following three classes, based
upon the amount of knowledge they need to compute routes.
Zero knowledge These algorithms do not utilize any oracles.
Not surprisingly, they perform poorly. They define the minimal
extreme of the knowledge-performance relationship in Figure 3.
Complete knowledge
This class consists of algorithms that
utilize all the oracles (contacts, queuing and traffic demand).
The Linear Programming formulation of the DTN routing prob-
lem falls into this category and is discussed in Section 8. While
these assumptions are far too strong to operate in a widely dis-
tributed, dynamic routing environment envisioned by DTNs,
we believe this to be the first full formulation of the problem
and is, therefore, an important step to establish a deeper un-
derstanding and baseline for performance comparisons.
Partial knowledge
These algorithms route in the absence of
the traffic demand oracle and use one or more of the other ora-
cles (congestion, queuing). Messages are routed independently
of the future traffic demand. This is a more practical assump-
tion from an implementation perspective. Therefore, we devote
most of our attention to algorithms in this class.
6. ROUTING WITH ZERO KNOWLEDGE
Algorithms in this class route with almost no assistance from
any knowledge oracle. We explore one very simple such algo-
rithm that in effect routes randomly using any available con-
tact. Its main purpose is to provide one extreme point in the
knowledge-performance relationship space of Figure 3.
Algorithm: First Contact (FC)
Oracles: None
A message is forwarded along an edge chosen randomly among
all the current contacts. If all edges are currently unavailable,
the message waits for an edge to become available and is as-
signed to the first available contact.
Properties FC performs poorly in nontrivial topologies be-
cause the chosen next-hop is essentially random and forwarding
along the selected edge may not make any progress toward the
destination. A message may also oscillate forever among a set
of nodes (especially when frequent contacts are present among
a small set of nodes) or be delivered to a dead end. It has no
provision to route around congestion. Clearly, FC requires only
local knowledge about the network and is trivial to implement.
Improvements The basic approach can be enhanced in many
ways. One is to incorporate a sense of trajectory between the
source and the destination so that the message is routed in a
direction closer to the destination [17]. To prevent loops, a path
vector type of approach can be used.
7. ROUTING WITH PARTIAL KNOWLEDGE
The algorithms in this category compute paths using one or
more of the following oracles: contacts summary, contacts, and
queuing. Further, each message is routed independently of the
future demand because the traffic oracle is not used. These al-
gorithms are all based upon assigning costs to edges and com-
puting a form of minimum-cost (“shortest”) path. Costs are
assigned to edges (by consulting the available oracles) to reflect
the estimated delay of the message in taking that edge. The
challenge and sophistication lies in assigning costs such that
the assigned costs are close to the delay that will actually be
encountered when a message is forwarded across the DTN.
The reasons for considering only cost-based algorithms in this
class are two-fold. First, they provide a convenient and common
way to utilize the different knowledge oracles (thereby, identi-
fying to what extent global knowledge is necessary). Second,
they correspond naturally to traditional shortest-path based
routing problems which are well-understood and for which sim-
ple computationally-efficient distributed algorithms are known.
This simplicity, however, comes at the price of imposing certain
restrictions on the nature of routing paths determined. One key
limitation is that only a single path to a destination is derived.
As argued earlier, for DTNs it may be important to use multi-
ple paths (with splitting) to achieve near-optimal performance.
Interestingly, the basic ideas introduced here can be used to find
multiple routes and good split sizes. This is discussed briefly
at the end of this section.
7.1 Computing Shortest (minimum cost) Paths
To model the forwarding delay of a message in a DTN, we
consider three delay components: 1) queuing time: time until a
contact becomes available, 2) transmission delay: time to inject
a message completely into an edge, and 3) propagation delay.
Queuing time includes both the time waiting for an edge to
become available (waiting time) plus the time to drain messages
already scheduled for departure on that edge. Queuing time can
be large because edges may be unavailable for long periods of
time. Given that edge capacities and propagation delays vary
with time, we also expect route selection to vary with time.
When edge costs are time-invariant, shortest paths can be
computed using Dijkstra’s shortest path algorithm. However,
if the costs are changing with time the straightforward approach
does not work. We must make two modifications to overcome
this problem. First, the time a message will arrive at a par-
ticular node must be predicted. Second, the predicted arrival
time must be used to determine the cost of taking subsequent
edges. This would, in turn, affect the time the message arrives
at neighboring nodes. Interestingly, Dijkstra’s algorithm can be
adapted to compute the shortest paths for this case. Pseudo-
code for the modified algorithm is given in Algorithm 7.1.
The key difference between this algorithm and the traditional
Dijkstra’s algorithm is the definition and the use of the w (cost)
function. It takes into account the time a message arrives at a
node. This time is then used to compute the cost of travers-
ing edges emanating from that node (lines 7 and 8 of Algo-
rithm 7.1).
The modified Dijkstra’s algorithm requires the cost function
for all edges to have the FIFO property. This property ensures
that a message can not arrive earlier at the destination of an
edge by simply waiting longer at the source of the edge (i.e. you
will not travel more quickly over an edge if you wait to use it).
Formally, it means that for all edges e and all pairs of time t
1
, t
2
with t
1
< t
2
, w(t
1
, e) + t
1
≤ w(t
2
, e) + t
2
. When considering
148
Abbr. Name Description Oracles Used
FC First Contact Use any available contact None
MED Minimum Expected Delay Dijkstra with time-invariant edge costs
based on average edge waiting time
Contacts Summary
ED Earliest Delivery Modified Dijkstra with time-varying
cost function based on waiting time
Contacts
EDLQ Earliest Delivery with
Local Queue
ED with cost function incorporating lo-
cal queuing
Contacts
EDAQ Earliest Delivery with
All Queue
ED with cost function incorporating
queuing information at all nodes and
using reservations
Contacts and Queuing
LP Linear Program - Contacts, Queuing and Traffic
Table 1: Overview of different routing algorithms. All Dijkstra-based algorithms incorporate a cost function sensitive to
edge propagation and transmission delays. Costs are ascertained by consulting the respective oracles.
Input: G = (V, E), s, T , w(e, t)
Output: L
1: Q ← {V }
2: L[s] ← 0 , L[v] ← ∞ ∀ v ∈ V s.t v 6= s.
3: while Q 6= {} do
4: Let u ∈ Q be the node s.t L[u] = min
x∈Q
L[x]
5: Q = Q ← {u}
6: for each edge e ∈ E, s.t. e = (u, v) do
7: if L[v] > (L[u] + w(e, L[u] + T )) then
8: L[v] ← L[u] + w(e, L[u] + T )
9: end if
10: end for
11: end while
Algorithm 1: Dijkstra’s Algorithm modified to use time-
varying edge costs. s is the source node. T is the start time.
L : V → R is the array returning the cost of the shortest path for
all nodes. The cost function w : E × R
+
→ R
+
, gives the cost
as a function of edge and time. The interpretation of w(e, t) is the
following: Let e be an edge from node u to node v. Given a message
at u at time t, w(e, t) is the cost (delay) of sending it to v. Therefore,
if e is taken the message will reach v at time t+w(e, t). The algorithm
also works if the network topology is a multigraph. The unmodified
Dijkstra’s algorithm (for time invariant costs) is the same except that
the cost function w(e, L[u] + T ) is replaced by w(e) in lines 7 and 8.
different cost assignments, we make sure the above condition
holds. In practice it does because, in a single physical link, any
message would not be able overtake other messages sent earlier.
The above property does not prevent a message from waiting
at a node in order to reduce the overall delay. For example,
consider a case in which two nodes have two edges between
them with different propagation delays. The algorithm may
prefer to wait for the lower propagation delay link over the
other even if it is currently unavailable.
7.2 Algorithms with Time-Invariant Costs
Algorithm: Minimum Expected Delay (MED)
Oracles: Contacts Summary
The cost of an edge is the sum of the average waiting time,
propagation delay and transmission delay. The route of a mes-
sage is independent of time so a proactive routing approach
can be used. MED uses the same path for all messages with
the same source-destination pair. No mechanism is employed
to route around congestion or avoid message drops if storage
space is unavailable.
Properties
The key property of MED is that it minimizes the
average waiting time. It fails to exploit superior edges which
become available after the route has been computed. For exam-
ple, a direct contact to the message destination arises when the
message is waiting for the pre-computed next-hop to become
available. In this case, the new contact would not be used.
Improvements
Finding multiple disjoint paths with similar
costs and randomly selecting among them could improve load
balancing and reduce congestion [16]. The precomputed route
could be modified in-transit if a superior contact becomes avail-
able. This would, in effect, make it a form of loose source rout-
ing, with a somewhat reactive behavior.
7.3 Algorithms with Time-Varying Costs
The w function varies with both edge and time. In addition,
it depends on the size of the message under consideration (be-
cause of transmission delay). It may also depend on the node
assigning costs because costs may depend on its local queue
occupancy. Therefore, for sake of uniformity, we represent the
cost function w(e, t) in the following form:
w(e, t) = w
0
(e, t, m, s)
Here, e is the edge, t is the time for which we are comput-
ing the cost, m is the size of the message under consideration
and s is the node assigning the costs (and invoking Dijkstra’s
algorithm). The w
0
function is now defined as:
w
0
(e, t, m, s) = t
0
(e, t, m, s) − t + d(e, t
0
)
where,
t
0
(e, t, m, s) = min{t
00
|
t
00
x=t
c(e, x) dx ≥ (m + Q(e, t, s))}
The functions c(e, t) and d(e, t) are the capacity and the prop-
agation delay functions for the DTN topology (given by the
contacts oracle). The function Q(e, t, s) is the queue size at the
source of edge e at time t as predicted by the node s. The pa-
rameter s in Q(e, t, s) is used to distinguish between local and
global queuing. We now explain how w
0
models the delay that
will be seen by the message when sent over the edge e starting
at time t.
t
0
is the earliest time the queued data at edge e and the mes-
sage under consideration can be unloaded into the network for
transmission (assuming FIFO queuing). The integral captures
149
