An Algorithm for Distributed Location
Management in Networks of Mobile Computers*
Svetlana Kryukovat Berna Massingillf and Beverly SandersO
University of Florida CISE Technical Report 96015
Abstract
In a network supporting mobile communication devices, a mechanism
to find the location of a device, wherever it may be, is needed. In this
paper, we present a distributed algorithm for this purpose along with its
formal specification and proof sketch. Inspired by our experiences with
Wang's algorithm [9], one goal of this paper is to demonstrate that the
process of formalization together with careful attention to abstraction and
presentation can yield significant benefits in algorithm design. In this case,
we obtained a more regular, general, and robust algorithm with a clearer
description. An incidental contribution is a useful theorem for proving
progress properties in distributed algorithms that use tokens.
1 System Description
We consider a system with a fixed network consisting of a set of nodes with
unique IDs and communication links between them, plus a large number of
mobile devices we will call portables. Routing1 between each pair of nodes in
the fixed network is provided; knowing the identity of a node is sufficient to be
able to communicate with it.
Each portable has a unique ID and is associated with a node called its home
address. Given the portable's ID, it is possible to determine the home address.
Also released as Caltech Technical Report CSTR9614
*This work was supported in part by the AFOSR under grant number AFOSR910070
and in part by the University of Florida.
tTanner Research, Inc., 180 North Vinedo Ave., Pasadena, CA 91107,
kryukova@tanner.com.
+Department of Computer Science, California Institute of Technology, m/c 25680,
Pasadena, CA 91125, berna@cs.caltech.edu.
Department of Computer and Information Science and Engineering, University of Florida,
Gainesville, FL 326116120, sanders@cis.ufl.edu.
1Routing in fixed networks has several well known solutions. See, for example, [8].
We will denote the home address for portable P as HA.P. At any given time, a
portable may be associated with a unique node of the fixed network with which
it communicates directly, typically over a wireless link. The ID of this node is
called the portable's location or actual address. The actual address of portable
P is denoted AA.P. A message can be sent to the portable via its actual address
node, which may change over time as the portable moves. Each portable is also
associated with a subset of nodes called its service area. The service area models
the region in which the system should be able to locate the portable.
In this paper we give algorithms for maintaining and querying a database
containing location information for portables. A query to the database returns
the actual address of the portable or indicates that the portable is out of its
service area or is switched off.
Although the actual address of a portable while it is communicating will
correspond to a base station2, in modeling the system we have abstracted away
from the specific devices that make up the fixed network. Indeed, we don't
even assume a onetoone correspondence between devices and nodes. For ex
ample, in order to provide fault tolerance, a node may consist of several different
physical devices that, from the point of view of our algorithms, form a single
logical entity3. On the other hand, since the system tracks when the portable
is unreachable due to being out of its service area or switched off, we intro
duce virtual nodes representing the (fictitious) "1 .. i..... of portables that are
switched off or out of their service areas, and then require that each portable
be associated with exactly one node at all times. This allows being switched on
or off and moving in and out of the service area to be handled using the same
mechanism as other movement of portables. The special nodes representing the
location of an inactive portable with home address S would be implemented by
the same physical devices) as node S.
We have also abstracted away from the particular way that nodes and porta
bles are named and routing among the fixed network is carried out. Typically,
the IDs of nodes and of portables will contain geographic information similar to
telephone numbers that can be exploited for routing and determining a node's
home address. See [7, 9] for a discussion of numbering and addressing in mobile
networks. We assume that routing in the fixed network is available, and that
given a portable's ID there is some way to determine its home address. We do
not specify exactly how this is done, since it is not relevant to our algorithms.
The algorithms are developed and verified using a variation of the UNITY
[1, 4, 5] programming method. We have attempted to give sufficient intuitive
justification and informal explanations to allow readers unfamiliar with this
formalism to understand the algorithms and follow the overall derivation. Ap
pendix A supplies necessary definitions, axioms, and theorems from UNITY.
2A base station is a node of the physical network that also engages in wireless communi
cation with portables, acting as the interface between portables and the physical network.
3Several known techniques exist for providing fault tolerance using replication [2].
2 Problem Description
In terms of our model, the problem is to give algorithms that allow the current
actual address of each portable in the system, or the fact that it is unreachable
(due to being out of its service area or switched off), to be determined. We will
give one algorithm for database maintenance and one for database queries.
The C',\ and EIA/TIA standards for mobile communications (see [6] for
an overview of location strategies in both) implement a twolevel database of
location information. For portables away from their home addresses, the home
address node maintains the location of a "visitor location r I'. that stores
the actual address of the portable. Any location change that requires a change
in the visitor location register requires that an update message be sent to the
home address node. The actual address of a portable is obtained by sending
a message to its home address node, which forwards it to the visitor location
register. This approach has the disadvantage that it doesn't scale well, and in
cases where the portable is not close (in the network) to the home address node
it can result in a significant amount of communication.
A more distributed approach, described in [9], imposes a hierarchical tree
structure on the nodes in the fixed network. Wang calls this an "intelligent
1.. i . .1 : In Wang's algorithm, the length of the path from the root of the tree
to each leaf node is constant, and each level in the tree represents a geographic
area. For example, the top level is the world, the nodes at the next level
represent countries, the next level states, and so on. Leaf nodes correspond
to (clusters of) base stations that can communicate with portables. The node
addressing scheme is based on this structure. For each portable away from its
home address, the algorithm determines a path from the portable's home address
to its current location and stores information about this path in the nodes that
comprise it. Together, these paths make up a distributed locationregistration
database.
He gives simulation results showing that better performance can be obtained
with this scheme than with the proposed EIA/TIA standard, since the hierar
chical scheme results in less message traffic and lower latency.
Our algorithm is more abstract and general than Wang's in that we logically
structure the network as an arbitrary undirected connected acyclic graph (rather
than as a tree of fixed depth), and we allow an actual address to be any node
in this graph. This abstraction is largely independent of the physical topology
of the network. This generalization allows a more regular algorithm since it
enables us to handle portables that are switched off or out of their service areas
with the same mechanism used for other location changes.
The relevant property of a connected acyclic graph is that there is a unique
shortest path along the edges of the graph between any two nodes. Most of the
messages used by the algorithm are sent along edges of the acyclic graph.
The actual address of a portable is represented by its location path: the
path in the acyclic graph from the home address node to the actual address
of the portable. The location of a portable can be determined by traversing
the acyclic graph toward the portable's home address node until the portable's
location path is intersected and then following this path to the actual address
node of the portable. The path followed by the query will intersect the location
path at the home address, if not sooner. The path from the home address
to the portable must be updated as the portable moves in such a way that
the portable can eventually be reached, even if its address is sought while it is
moving (provided the portable doesn't move too fast).
3 System and Component Models
In this section, we give a more formal description of the system and component
models and remark on notation.
3.1 Portables
For a portable P, in addition to the home address HA.P, the actual address
AA.P, and the service area, all of which were discussed in section 1, we associate
with portable P a logical clock, denoted ts.P. This clock could be implemented
with a physical clock or counter on the portable itself, or as a sufficiently syn
chronized global time implemented by the nodes of the fixed network. The
necessary property of the clock is that its value increases (at least) on move
ment of the portable to a new location. This is formally specified with the
following property:
ts.P = k AAA.P = S next (ts.P > k AAA.P = S) V ts.P > k (1)
3.2 The fixed network
The fixed network is modeled as a set of nodes organized in an undirected con
nected acyclic graph whose important characteristic is that there is a unique
shortest path between every pair of nodes. The function minPath : (node x
node)  list of node is given and fixed for any particular network. In partic
ular, minPath(N, M) is the list of nodes corresponding to the shortest path
between nodes N and M, not including N, and path(N, N) = (), the empty
list. The reason for not including N in the path is so that the concatenation
minPath(N, M) ++ minPath(M, R) makes sense. The list so obtained is a
path over the acyclic graph from N to R, although not necessarily the shortest
one (since it could contain a cycle). If it is desired to have a path representa
tion that includes N, this can be indicated using the cons operator "::" (e.g.,
N :: minPath(N, M)). Although we will often use the minPath function in
specifications, in the algorithms themselves a node will only need to determine
the next node on a path from itself to some other node. For convenience, we
define the function nextNode to return the next node.
nextNode(N, M) def head(minPath(N, M)) (2)
We observe that since minPath(N, N) = (), nextNode(N, N) is undefined.
3.3 Communication and computation
Nodes communicate with each other via asynchronous messagepassing. After a
message is sent, it will eventually be available to be received by its destination.
At each step, a node may read a message, compute and modify local variables,
and send one or more messages. Read, compute, and send are performed in a
single atomic step, and we require that all messages that are sent are eventu
ally received. We assume that routing is provided for communication between
any two points in the fixed network. In our algorithm, however, most of the
communication will be between nodes that are neighbors in the acyclic graph.
The algorithms for maintaining and querying the database are based on
tokens. Tokens are simply message records in which the first three fields are
message ID, sender, and destination. Additional fields indicating the token
type and containing additional data are also used. The predicate token holds
when a particular token is in the system, i.e.,
def
token(P, R, S, type, data) (3)
a message (P, R, S, type, data) is in transit between nodes R and S
We use underscores as an abbreviation for existential quantification:
token(P, _, type, data) d (3r, s :: token(P, r, s, type, data)) (4)
The action of receiving a token (P, R, S, Type, Data) falsifies the predicate
token(P, R, S, Type, Data). Sending a token (P, R, S, Type, Data) establishes
token(P, R, S, Type, Data). We assume that each message sent will eventually
be delivered and processed. With this assumption (discussed in more detail in
appendix B), we can write the following leadsto property:
token(P, R, S, Type, Data) . token(P, R, S, Type, Data) (5)
Additional details about the communication model are given in appendix B.
3.4 Notation
We sometimes denote application of function f to x with the notation f.x. An
example of this is the notation used for the home address of portable P: HA is
a function mapping portable IDs into node IDs, so HA.P is the node ID that
results from applying this function to P's ID. Another example is the use of
AA.P to denote the portable's actual address. Here, the function is merely
a convenient way to formalize I. .. the portable is"; moving the portable
changes the function.
We use the notation R. Var to denote local variable Var of node R.
4 The database maintenance algorithm
4.1 Overview
As discussed earlier, the idea of the algorithm is to impose on the acyclic graph
a path for each portable P from its home address to its actual address. (We
call such a path a Ppath, and we call its edges Pedges.) Each node R has
a variable R.Out that contains a set of (portable ID, node ID) pairs. In other
words, (P, S) E R.Out means that there is an edge labeled P (i.e., a Pedge)
from R to S. R.Out can also be thought of as a function on portable IDs, where
R.Out.P is the destination of an outgoing Pedge from R, or c if there are none.
We will require (in (11)) that there is at most one outgoing Pedge, so R.Out.P
is a function, defined thus:
R.Out.P de (6)
S if (P, S) E R.Out
C otherwise
Also, each node R has a set R.Registered that contains the ID of each portable
P for which R is the actual address (AA.P = R) and for which the database is
currently up to date.
When a portable P with ts.P = k moves from actual address R to actual
address T, R learns of the new destination and the value of ts.P. P is then
removed from R.Registered, and a token is created to update the database.
The token is sent along the shortest path from R to T, removing or adding
edges as necessary to establish a path from HA.P to T. When the token arrives
at T, either T is still the actual address of P and P is added to T.Registered,
or P has moved in the meantime and the update process continues.
In practice, R could be notified of the new destination by receiving a message
from the portable, or by discovering that it can no longer communicate with
a registered portable and interpreting this as meaning the portable has been
turned off. In the latter situation, node R would simply generate an update
token and send it to a virtual node representing the "1... i ..... of P when it is
switched off or out of its service area. Also, note that all actions taken by the
database update algorithm are done in response to actions initiated by the old
node. This avoids any need to synchronize actions of the old and new nodes.
4.2 Specification
We can specify the database maintenance algorithm as follows. First, if a
portable is registered at a node, it should indeed be located there. This is
given by an invariant property:
P C T.Registered = AA.P = T (7)
We also want it to be the case that if a portable's actual address is T, then
eventually P will be registered at T, unless P moves to another location before
the algorithm has time to finish updating the database. This is given by a
leadsto property:
AA.P = T P E T.Registered V AA.P T (8)
Our algorithm works by sending a token along a path, so we require that the
path be maintained properly. We define locPath.P (P's location path) as the
longest sequence of nodes that can be reached by starting at P's home address
and following Pedges:
locPath.P f HA.P :: maxPath.P.(HA.P) (9)
where
maxPath.P.x de (10)
() if x.Out.P = e
x.Out.P :: maxPath.P.(x.Out.P) otherwise
locPath.P is unique and welldefined if each node has at most one outgoing
Pedge and no Pedges to itself:
(P, S) R.Out A (P, T) R.Out = S=T A S R (11)
If P is registered at T, we require that there be a Ppath from P's home
address to T and that this path be the shortest path from HA.P to T. These
requirements are formalized with two invariants: The first says that if P is
registered at T, then the last node of locPath.P is T. The second says that
locPath.P is always the shortest path from HA.P to its last node.
P E T.Registered = last(locPath.P) = T (12)
locPath.P = HA.P :: minPath(HA.P, last(locPath.P)) (13)
From the properties of acyclic graphs, (13) holds if all nodes in locPath.P are
unique.
Also, we don't want I, edges, so we require that all Pedges be part of
locPath.P.
R.Out.P = S = R E locPath.P (14)
Together, properties (7), (8), (11), (12), (13), and (14) constitute a formal
specification of the database maintenance algorithm.
4.3 Algorithm development
Since these properties ((7), (8), (11), (12), (13), and (14)) do not give a
strong enough invariant to prove directly, we introduce additional properties
to strengthen the specification.
The database update algorithm uses update tokens. An update token has
the structure
(P, R, S, UPDATE, (t, T)) (15)
where P is the portable whose registered address needs to be updated, R is
the sender of the token, S is the immediate destination of the token, UPDATE
indicates that the token is to update the database, t is a timestamp indicating
the time (from ts.P) when P moved to T, and T indicates the final destination
of the token. At each step, the algorithm receives a token and then forwards it
to the next node on the path to T.
We can define several properties about these tokens. First, no update token
exists for a portable P exactly when P is registered at its current actual address.
token(P, _, UPDATE, ) P E (AA.P).Registered (16)
Also, at any time, there is at most one update token for P.
0 < itt., ,,(P,_, _, UPDATE, ) < 1 (17)
Our algorithm guarantees properties (16) and (17) by creating a new update
token only when a registered portable becomes unregistered and deleting a token
only when registering a portable.
Further, update tokens have the property that a token is always sent along
a path to its final argument, which is given by the last field.
token(P, R, S, UPDATE, (_, T)) 4 S = nextNode(R, T) (18)
This property is easily guaranteed.
A new update token is created when a portable moves away from the
node where it is registered. From (12), at the moment at which the token,
say (P, R, S, UPDATE, (t, T)), is created, the last node of P's location path
locPath.P is R. The idea of the algorithm is that the update token is at the
end of the current locPath.P and moves toward node T, adding or removing
edges as it goes. There are two situations: one in which locPath.P needs to be
extended to reach T, and one in which edges need to be removed. An update
will typically start out removing edges and then later enter a phase in which
edges are added. These two situations are shown in figure 1.
As can be seen from the figures, if the token (P, R, S, UPDATE, (t, T)) is
removing edges, then last.(locPath.P) = R; if it is extending locPath.P, then
last.(locPath.P) = S. The two cases can thus be distinguished by comparing
nextNode(R, T) (i.e., S) with nextNode(R, HA.P). If they are equal, then
T T
S R_
(P, R, S, UPDATE, (t,T)) R (P, R, S, UPDATE, (t,T))
R "S
(a) Path contracting. (b) Path extending.
Figure 1: (a) Token (P, R, S, UPDATE, (t, T)) removing edges from locPath.P.
(b) Token (P, R, S, UPDATE, (t, T)) extending locPath.P.
the token in transit between R and S is moving toward the home address. If
nextNode(R, T) f nextNode(R, HA.P), then the token is moving away from
the home address. Note also that if the token is moving toward the home
address, then S.Out.P = R, and if it is moving away, then S.Out.P = e. We
can state this with the following invariant.
token(P,R,S, UPDATE,(_,T)) = (19)
(nextNode(R, T) = nextNode(R, HA.P)
(last(locPath.P) = R A S.Out.P = R))
A (nextNode(R, T) nextNode(R, HA.P) =
(last(locPath.P) = S A S.Out.P = ))
When portable P, registered at R and having ts.P = t, moves to T and cre
ates an update token (P, R, S, UPDATE, (t, T)), locPath.P ++ minPath(R, T)
(where R = last(locPath.P)) forms a path from P's home address to its actual
address T, although not necessarily the shortest one. We define update.P as the
shortest path from the last node of locPath.P to the token's final destination:
update.P def (20)
minPath(last(locPath.P), T) if token(P,,, ,UPDATE, (_, T))
() if token(P,, _, UPDATE, _)
As the token moves along, update.P becomes shorter until it is empty while
maintaining the invariant that locPath.P ++ update.P forms a path, although
not necessarily the shortest one, to T. Once update.P becomes empty, we have
last(locPath.P) = T. If T is P's actual address, then P can be registered at T.
HA.P
HA.P
If P moves from T before the update of locPath.P has been completed, then
update.P will become () and last(locPath.P) will become T, even though T is
no longer the actual address of P. While clearly a database that consistently
cannot keep up with the location of the portables is not useful in practice, we
would like our algorithm to be able to handle transient situations in which this
happens. In our algorithm, the transient situation in which a portable moves
before it has been registered at its current actual address will not violate the
safety (invariant) properties of the algorithm, and the update algorithm can
always catch up if at any time the portable stops moving long enough.
There are two situations that now must be reconsidered. One is the action
taken when the portable moves from R to T when a token already exists. In this
case, which can be recognized by checking to see whether P is registered in R,
no new token should be created, but the fact that the portable has moved to T
should be reflected in the state of R. This is done with a variable at R, denoted
R.Pending.P, that contains the timestamp and destination of the latest move
from R made while P was not registered at R. R.Pending.P contains either
a (timestamp, node) pair, whose components are denoted R.Pending.P.ts and
R.Pending.P.dest respectively, or the value c. For example, suppose P moves
from R to T at a time ts.P = k when it is not registered at R. Instead of
a new update token being created, (k, T) is stored in R.Pending.P. When a
token with final destination R and timestamp t arrives, if R.Pending.P is not
empty and if t < k, (k, T) becomes the new timestamp and final destination for
the update token and R.Pending.P is set to c. The update token is forwarded
toward its new final destination, removing or adding edges as before.
It is, of course, possible for the portable to move to additional destinations
before the update token arrives, so we define a pending queue Q.P, constructed
by taking the contents of T.Pending.P, where T is the final destination of the
current token, followed by the contents of (T.Pending.P.dest).Pending.P, and
so on. The final element of Q.P is AA.P. Q.P is () if there is no UPDATE
token for P.
Since it is possible for a portable to move away from a node and then later
return to it, the contents of T.Pending.P may be overwritten, invalidating the
contents of some pending variables. While this is useful in practiceit elimi
nates cycles from Q and reduces the time needed to update the databaseit also
introduces the requirement that we distinguish relevant values of T.Pending.P
from old, invalid ones. This is the purpose of the timestamp. We require that
the timestamps associated with Q.P be increasing, and that all of them be
smaller than ts.P. Then a T.Pending.P entry with a smaller timestamp than
an arriving UPDATE token for P can be recognized as old and ignored. Q.P
is formally defined as follows:
.P de (21)
() if token(P, _, _, UPDATE, _)
QQ.P.(t,T) iftoken(P, ,_, UPDATE, (t,T))
where
QQ.P.(t, T) de (22)
) if T.Pending.P = c V
T.Pending.P = (tt, TT) A tt < t
T :: QQ.P.(tt,TT) if T.Pending.P= (tt,TT) Att > t
(Observe that we need not consider a case where tt = t; this is a consequence
of (1).)
Q.P and the pending variables satisfy invariants that the timestamp of the
portable is always larger than the timestamp for any pending update
(VT :: T.Pending.P fe : T.Pending.P.ts < ts.P) (23)
and, from the definition of Q, timestamps corresponding to the elements of Q
are in increasing order and larger than the timestamp of the UPDATE token.
One final invariant provides the essence of the reason the algorithm is correct:
last(locPath.P ++ update.P ++ Q.P) = AA.P (24)
Finally, we can add an optional optimization. To motivate its introduction,
suppose that at some point AA.P = T, and then P moves elsewhere and later
returns to T (so that AA.P = T again). If the update algorithm is very slow,
then T will appear twice in Q.P. Clearly, all successors to T in Q.P can be
removed without violating (24). This can be done by setting T.Pending.P to
c. We emphasize that this action merely performs an optimization; it could
be eliminated altogether or delayed without affecting the correctness of the
algorithm.
4.4 Algorithm
The database maintenance algorithm is given in figures 2, 3, and 4. Figure 2
shows the action that is performed when portable P changes its actual address
from node Old to node New. Figure 3 gives the action taken when an update
token from node R is received by node S. Figure 4 shows the action that
performs the optional optimization.
Initial conditions are as follows (for all portables P and nodes R):
HA.P = AA.P A (25)
P E (HA.P).Registered A
R.Out = E A
R.Pending.P = e A
token(P, _, _, UPDATE, _)
AA.P := New;
if P E Old.Registered 
ALL PREVIOUS UPDATES COMPLETED, UNREGISTER P AND LAUNCH A NEW UPDATE TOKEN
Old.Registered := Old.Registered P;
send(P, Old, nextNode(Old, New), UPDATE, (k, New));
if nextNode(Old, New) f nextNode(Old, HA.P) 
THE PATH FROM HA.P WILL BE EXTENDED, ADD AN OUTGOING PEDGE TO Old.Out
Old.Out := Old.Out U {(P, nextNode(Old, New))}
[] nextNode(Old, New)= nextNode(Old, HA.P)
skip
fi
[] P V Old.Registered 
AN UPDATE OF P'S LOCATION IS ALREADY IN PROGRESS, SAVE NEW LOCATION AND TIMESTAMP
Old.Pending.P := (k, New)
fi
Figure 2: Node Old is notified that P has moved to New at a point where
ts.P = k.
if T S
TOKEN HAS NOT YET REACHED FINAL DESTINATION, FORWARD ALONG UPDATE PATH
send(P, S, nextNode(S, T), UPDATE, (t, T));
if nextNode(S, T)= nextNode(S, HA.P) 
TOKEN MOVING TOWARD HOME ADDRESS, REMOVE EDGE
S.Out := S.Out (P, R)
[] nextNode(S, T) f nextNode(S, HA.P)
TOKEN MOVING AWAY FROM HOME ADDRESS
ADD NEW EDGE IN DIRECTION OF TOKEN, MAINTAIN SINGLE OUTGOING PEDGE
S.Out := (S.Out (P, R)) U {(P, nextNode(S, T))}
fi
[1 T=S
TOKEN AT ITS FINAL DESTINATION
if S.Pending.P f e A S.Pending.P.ts > t
THERE ARE STILL PENDING UPDATES, GENERATE UPDATE TOKEN TO NEXT UPDATE
send(P, S, nextNode(S, S.Pending.P.dest), UPDATE, S.Pending.P);
if nextNode(S, S.Pending.P.dest) = nextNode(S, HA.P)
TOKEN MOVING TOWARD HOME ADDRESS, REMOVE EDGE
S.Out := S.Out (P, R)
[] nextNode(S, S.Pending.P.dest) f nextNode(S, HA.P)
TOKEN MOVING AWAY FROM HOME ADDRESS
ADD NEW EDGE FOLLOWING TOKEN AND MAINTAIN SINGLE OUTGOING PEDGE
S.Out := (S.Out (P, R)) U {(P, nextNode(S, S.Pending.P.dest))}
fi;
S.Pending.P :=
[] S.Pending.P = e V S.Pending.P.ts < t
NO MORE UPDATES, REGISTER P
S.Registered := S.Registered U {P};
S.Out := S.Out (P, R);
S.Pending.P :=
fi
fi
Figure 3: S receives token (P, R, S, UPDATE, (t, T)) from R.
if New = AA.P 
New.Pending.P :=
Figure 4 Ne clears Pending.P.
Figure 4: New clears Pending.P.
4.5 Proof
The conjunction of the invariants that make up the formal specification ((7),
(11), (12), (13), and (14)) and those of section 4.4 can be proved in a straight
forward way by checking that it (the conjunction of invariants) holds initially
and is preserved by each action. The details are not illustrative and are omitted.
Certain properties of acyclic graphs that are needed are given in appendix D.
With this done, what remains is to prove progress property (8). Update
tokens not yet at the destination indicated in the last field are sent to the next
node in the path to that destination. This doesn't change until the token reaches
the destination. Also, Q.P does not increase unless the portable's actual address
changes. Thus we have the following easilychecked property:
(token(P, R, S, UPDATE, (t, T)) A Q.P = k A AA.P = R A S T) next (26)
(token(P, R, S, UPDATE, (t, T)) A IQ.PI < k A AA.P = R) V
(token(P, S, nextNode(S, T), UPDATE, (t, T)) A IQ.PI < k A AA.P = R) V
AA.P # R
Applying the token progress theorem (59), we get
(token(P, _, S, UPDATE, (t, T)) A IQ.P = k A AA.P = R) (27)
(token(P, _, T, UPDATE, (t, T)) A IQ.PI < k A AA.P = R) V
AA.P # R
Once the update token is at its destination, then either the portable will be
registered at its destination, or a new token will be launched and the length
of Q.P decreased, or the portable will move. This is formally indicated by the
following easilychecked property:
(token(P, S, T, UPDATE, (t, T)) A IQ.PI = k A AA.P = R) next (28)
(token(P, S, T, UPDATE, (t, T)) A IQ.PI < k A AA.P = R) V
(token(P, _, _, UPDATE, _) A IQ.PI < k A AA.P = R) V
P E R.Registered V
AA.P # R
Since all tokens must be received (5), from the PSP theorem4 we get:
(token(P, S, T, UPDATE, (t, T)) A Q.P = k A AA.P = R) . (29)
(token(P, _, _, UPDATE, _) A IQ.PI < k A AA.P = R) V
P E R.Registered V
AA.P # R
4See Appendix A for this and other axioms and theorems about leadsto used in this proof.
Applying disjunction on S, we then get:
(token(P, _, T, UPDATE, (t, T)) A IQ.PI = k A AA.P = R) . (30)
(token(P, _, _, UPDATE, _) A Q.PI < k A AA.P= R) V
P E R.Registered V
AA.P 7 R
Combining the above progress properties and using disjunction on T and
induction (on IQ.PI, which clearly is always nonnegative) we get:
(token(P, _, _, UPDATE, _) A AA.P = R) (31)
P E R.Registered V AA.P 7 R
From invariant (16),
token(P, _, UPDATE,_) A AA.P = R = P E R.Registered (32)
and hence
token(P, _, UPDATE, ) A AA.P = R ~ (33)
P c R.Registered V AA.P 7 R
Applying disjunction to (31) and (33), we get the desired result:
AA.P = R P R.Registered V AA.P A R (34)
5 The database query algorithm
5.1 Overview
A query to determine the location of a portable P is initiated by sending a
query token. The query token travels along the acyclic graph toward P's home
address until it finds a node where P is registered or where there is an outgoing
Pedge. Outgoing Pedges are followed until a node where P is registered is
found. When the address where P is registered is determined, a result token is
generated and sent back to the originator. Since we assume that routing between
all nodes in the fixed network is available, the result token is sent directly back
to the originator. This is the only token type in the algorithms presented here
that is not restricted to traveling only along edges in the acyclic graph.
A query token has the structure
(P, N, M, QUERY, Orig) (35)
where P is the ID of the token to be located, QUERY is the message type, and
Orig is the ID of the node to which the result should be sent.
A result token has the structure
(P, T, Orig, RESULT) (36)
where T is the registered address of P.
5.2 Specification
Ideally, we would like to require that it always be the case that the T field of a
result token contains the current registered address of the portable. This is too
strong for two reasons. First, it will take some time for the reply token to get
back to the originator of the lookup. Since we can't constrain the movement of
the portable, the most that can be done is to say that the reply token contains
the registered address of the portable at the instant the token was sent. Also,
if the portable moves faster than the database maintenance algorithm can keep
up with, it is not possible to expect that a correct location for the portable
can be returned. What we specify is that if at some point P E T.Registered
and there is a query token for P in the system, then eventually a reply token
indicating that P is registered at T will be generated, or P will move. Since
this must be true for all T, if P stays in one place "long enough", then a token
with its current registered address will be generated. The above requirement
can be specified with a leadsto property as follows:
P E T.Registered Atoken(P, _, QUERY, R) (37)
token(P, T, R, RESULT) V P V T.Registered
We also require that a query token remain in existence until a result token is
generated, and that the result token contain (at the moment it is generated) the
registered address. Therefore a query token that is generated when an update is
in progress will eventually be responded to once the database update algorithm
has caught up with the token position for long enough5.
token(P,_, QUERY, R) next (38)
token(P, _, _, QUERY, R) V
(3T :: token(P, _, R, RESULT) AP T.Registered)
5.3 Algorithm
Figure 5 gives the action required to generate a query token. Note that we
have not given an action for the case where the portable is registered at the
node wishing to locate the token; a local lookup suffices in this case. Figure 6
describes processing on receipt of a query token.
5Wang [9] simply assumed that this would not happen, and did not give sufficient details
to determine what would happen with his algorithm if it did.
Initial conditions are as specified in (25), plus the following (for all portables
P):
token(P, _, QUERY, _) A (39)
token(P, _, _RESULT)
if R.Out.P = E
NO OUTGOING PEDGE, CREATE QUERY TOKEN AND SEND TOWARD P'S HOME ADDRESS
send(P, R, nextNode(R, HA.P), QUERY, R)
[] R.Out.P +
CREATE QUERY TOKEN AND SEND IT ALONG P'S LOCATION PATH
send(P, R, R.Out.P, QUERY, R)
fi
Figure 5: Node R initiates query for portable P.
if P E T.Registered 
P FOUND, CREATE RESULT TOKEN
send(P, T, R, RESULT)
[] P V T.Registered 
if T.Out.P = 
No OUTGOING PEDGE, FORWARD QUERY TOKEN TOWARD P'S HOME ADDRESS
send(P, T, nextNode(T, HA.P), QUERY, R)
[] T.Out.P e 
FORWARD QUERY TOKEN ALONG P'S LOCATION PATH
send(P, T, T.Out.P, QUERY, R)
fi
fi
Figure 6: Node T receives token (P, S, T, QUERY, R).
5.4 Proof
We sketch the proof of progress property (37). First, we would like to use the
token progress theorem (59) to conclude that as long as the registered address
remains constant long enough, the query token will eventually arrive at the
registered address. We need the following:
(token(P, R, S, QUERY, R) A P T.Registered A S # T) next (40)
(token(P, R, S, QUERY, R) A P E T.Registered) V
(token(P, S, nextNode(S, T), QUERY, R) A P E T.Registered) V
P V T.Registered
This can be shown from the program text provided the following are invariant:
P T.Registered AS TA T S.Out.P= e = (41)
nextNode(S, HA.P) = nextNode(S, T)
and
P T.Registered AS & TA S.Out.P e c (42)
S.Out.P = nextNode(S, T)
These follow from invariants (12) and (13) of the database maintenance algo
rithm (which state that if P is registered at T, then the database edges labeled
P correspond to the shortest path from HA.P to T) and properties of acyclic
graphs. From the token progress theorem (59) and disjunction6 over S, we get:
token(P, _, QUERY, R) A P E T.Registered ' (43)
token(P, _, T, QUERY, R) V P V T.Registered
Now, we need it to be true that if the query token is at the registered
address, either a result token will be generated eventually, or the portable will
move. From the program text, we obtain
(token(P, S, T, QUERY, R) A P T.Registered) next (44)
(token(P, S, T, QUERY, R) A P E T.Registered) V
(token(P, T, R, RESULT) AP E T.Registered V
P V T.Registered
We combine this with (5) and the PSP theorem to get
token(P, S, T, QUERY, R) A P E T.Registered (45)
(token(P, T, R, RESULT) AP E T.Registered) V
P V T.Registered
6See Appendix A for this and other axioms and theorems about leadsto used in this proof.
We then apply disjunction on S to get:
token(P, _,T, QUERY, R) A P T.Registered . (46)
(token(P, T, R, RESULT) A P E T.Registered) V
P V T.Registered
We can then combine this with (43) (using the cancellation theorem) to get:
token(P, _, QUERY, R) A PE T.Registered ~ (47)
token(P, T, R, RESULT) V P V T.Registered
Finally, we look at safety property (38). This holds by inspection, provided the
action on receiving a query token is well defined. In particular, we need the
following to be invariant:
P V T.Registered AT.Out.P = E = T 4 HA.P (48)
This guarantees that nextNode(T, HA.P) f c and thus that sending the token
from T to nextNode(T, HA.P) is well defined. The invariant follows from the
invariants given for the database maintenance algorithm; the proof is omitted.
6 Discussion
We have given an algorithm for location update in mobile networks. Our work
was inspired by Wang's algorithm [9]. Although the hierarchical approach he
presents has much potential for scaling up to large systems, we found his pre
sentation difficult to understand. A major reason was that he included details
that are indeed important, but orthogonal to the design of the location database
itself and best considered separately. We avoided unnecessary detail by careful
abstraction in the problem formulation. For example, we do not specify the
relationship between the identification numbers assigned to portables. Instead,
we specify only what is necessary: that there is a connected acyclic graph im
posed on the nodes of the network and that, given the ID of a portable, its home
address node can be determined. While this could be decoded from the ID itself,
as in Wang's algorithm, other alternatives can also be imagined. For example,
one might imagine that in the future a portable ID would be associated with a
person for a lifetime, rather than with the geographical location of the current
home address, and the home address would be looked up in a database. Our
approach allows this problem to be solved independently from the problem of
finding the current address of the portable given its home address, and greatly
simplifies the presentation of our algorithm.
Another important abstraction we made was viewing our "intelligent net
v ..1 I as an arbitrary connected acyclic graph in which any node in the graph
could potentially be the actual address of a portable. This effectively decouples
the logical structure from the structure of the physical network, with several
significant advantages. One is that we can treat all portables, whether out of
their service areas, switched off, or active in their service areas, in a uniform
way simply by introducing a virtual node associated with each home address
node to record the status of a portable that is switched off or out of its service
area. This simplifies the algorithm and is easily implemented. Also, individual
base stations need not be the optimal granularity for location information for
portables. For example, several base stations might be combined in a region,
with connection established with individual portables by paging in the entire
region. [3] discusses the tradeoff between paging and the granularity of location
information that is maintained. Finally, our approach allows fault tolerance to
be introduced using wellknown techniques for replication. This problem can
be addressed independently of our algorithm, another example of 1I i .....
of .. I. I 
Finally, we specified, developed, and verified our proposed algorithm using
a systematic, wellfounded method and described the algorithm using a well
defined notation [1, 4, 5] with clear assumptions. This makes clear what the
algorithm is and what problems we have and haven't actually solved. For exam
ple, one potential problem area for any algorithm keeping track of the current
location of portables is what happens if the portable moves too fast for the
database to keep up with. Wang was not clear about what happens in this situ
ation in his algorithm, and does not indicate how connection requests (database
queries, in our algorithm) are handled during a database update. Our claims
for our algorithm are much more specific, and we believe our algorithm to be
significantly more robust than his. Regardless of how fast the portable moves,
all of the safety (invariant and next) properties will be satisfied. In particular, a
portable will never have an incorrect registered address. We also know that the
database algorithm will eventually catch up with a portable that stops moving.
We cannot guarantee, however, that the portable's actual address will ever be
registered if the portable perpetually moves faster than the algorithm can keep
up with. Determining whether this is likely to happen in practice requires a
performance analysis with knowledge of the expected behavior of portables and
the speed of communication and computation in the fixed network. Such anal
ysis is better carried out separately from reasoning about the correctness of an
algorithm.
Acknowledgments
The authors thank Peter Hofstee for his careful reading and valuable comments,
and Mani Chandy and Flemming Andersen for helpful discussions.
References
[1] K. M. Chandy and J. Misra. Parallel Program Design: A Foundation.
AddisonWesley, 1989.
[2] F. Cristian. Understanding faulttolerant distributed systems. Communica
lions of the AC i1, 34(2):5691, February 1991.
[3] J. G. Markoulidakis and E. D. Sykas. Method for efficient location area
planning in mobile telecommunications. Electronics Letters, '''"i') i'l.
2166, December 1993.
[4] J. Misra. A logic for concurrent programming: Progress. Journal of Com
puter and Software Engineering, 3(2):273300, 1995.
[5] J. Misra. A logic for concurrent programming: Safety. Journal of Computer
and Software Engineering, 3(2):239272, 1995.
[6] S. Mohan and R. Jain. Two user location strategies for personal communi
cations services. IEEE Personal Communications, pages 4250, 1994.
[7] E. D. Sykas and M. E. Theologou. Numbering and addressing in IBCN for
mobile communications. Proceedings of the IEEE, 7'()'):230241, February
1991.
[8] A. S. Tanenbaum. Computer Networks. PrenticeHall, 3rd edition, 1996.
[9] J. Z. Wang. A fully distributed location registration strategy for univer
sal personal communication systems. IEEE Journal on Selected Areas in
Communication, 11(6 ', 'i .iJune 1993.
A UNITY
In this section we give brief informal definitions of some key terms and state
major axioms and theorems. Refer to [1] or [4, 5] for more complete information.
A.1 Definitions
Leadsto properties. P . Q means that if at some point P holds, then eventu
ally Q will hold.
Invariants. I is an invariant if it holds initially and is preserved by every action.
If I A J is invariant, then so is I.
Next properties. P next Q means that whenever P holds, Q holds after execu
tion of the next action. Since the next action may be one that doesn't
change any variables mentioned in P (for example, an action that occurs
on some other node), this introduces the requirement that [P = Q].
A.2 Axioms
Basis for leadsto.
p ensures q (49)
p , q
(p ensures q means that ifpA q holds at some point in the computation,
then it continues to hold until q holds, and further, if p holds, then there
is some action that establishes q.)
Transitivity of leadsto.
Sis transitive (50)
Disjunction for leadsto. If S is a set of predicates:
< Vp:pES:p q >
(51)
< 3p: p ES: p > . q
A.3 Theorems
PSP (ProgressSafetyProgress).
p q, r next s
pAr (qAs)V(rAs) (52
Induction. If M is a total function from program states to W, where (W, <)
is wellfounded (for example, lessthan over the positive integers), and m
ranges over W:
< Vm ::pA(M= m) (pA(M < m)) V q > (53)
p q
Cancellation.
p qVr, r s (5
p q qVs
B Communication channels and tokens
Formally, we model a unidirectional (logical) communication channel between
nodes r and s as a bag called ch,,. In the algorithm at hand, channels are bags
that model communication channels that reliably deliver all messages sent but
may reorder them. In cases in which channels deliver messages in the order they
were sent, channels may be modeled as sequences. Formally, sending a message
corresponds to adding a message to a channel:
send(P, R, S, Data) de (55)
chRs := chRs U (P, R, S, Data)
Receiving a message (P, R, S, Data) can only occur when the message is in the
channel and has the effect of removing the message from the channel.
receive(P, R, S, Data) def (56)
if (P, R, S, Data) C chs chRs := chRs (P, R, S, Data)
[] (P, R, S, Data) V chRs skip
fi
The predicate token is defined formally as
token(P, R, S, Data) (P, R, S, Data) C chfs (57)
The following property, introduced in section 3.3 as (5), was sufficient to
prove all the other progress properties in the paper:
token(P, R, S, Type, Data) ~ token(P, R, S, Type, Data) (58)
But we need to know when this property is satisfied by an implementation. If all
messages sent are eventually delivered (which is a reasonable assumption about
the underlying system), and the algorithm has a command to handle every
message that might come through and all tokens are unique (both of which we
need to check), then we can conclude that (5) holds.
Note that if there can be more than one token with fields (P, R, S, Type, Data)
in the channel between R and S at the same time, then we cannot guarantee that
there will ever be a point at which no token with fields (P, R, S, Type, Data) is
in the channel. Thus, we need uniqueness. If tokens are not actually unique, we
can make them so by adding an auxiliary (unimplemented) data field containing
unique sequence numbers.
C Token progress theorem
Often, tokens are sent along some path in a network until a node is reached where
some condition holds. The token progress theorem is helpful in showing progress
in algorithms that use tokens. We assume that there is a connected acyclic
graph structure on the nodes of the system and that the functions minPath
and nextNode are as defined in section 3.2.
Theorem. Suppose that the following safety property is satisfied:
(token(P, R, S, data) A S # TApA q) next (59)
(token(P, R, S, data) Ap A q) V
(token(P, S, nextNode(S, T), data) Ap A q) V
'
Then
(token(P, _, S, data) Ap A q) ~ (60)
(token(P, _,T,data) A p) V q
Proof.
(59)
S { PSP theorem with (5) }
token(P,R,S,data) AS TApA q
(token(P, S, nextNode(S, T), data) A p) V q
I { disjunction on R }
token(P,, S,data) AS TApA q
(token(P, S, nextNode(S, T), data) A p) V q
S { strengthen left side }
IminPath(S, T) = k A token(P, _, S, data) A S f TAp A q
(token(P, S, nextNode(S, T), data) A p) V q
S { property of connected acyclic graphs: }
{ IminPath(S,T)=kAk >0= }
{ IminPath(nextNode(S, T), T) < k
IminPath(S, T) = k A token(P, _, S, data) A S TA p A q
(IminPath(nextNode(S, T), T)I < k A
token(P, S, nextNode(S, T), data) A p) V q
{ let 1= IminPath(S, T) if token(P, _, S, data)}
= kAtoken(P, _,S,data) AS TApAq .
(1 < k A token(P, _, nextNode(S, T), data) A p) V q
S { induction on k }
= kAtoken(P, _,S,data) AS TApAq .
(token(P, _, T, data) A p) V q
= { disjunction with }
{ token(P, _,T, data) ApAq token(P, _,T, data) Ap }
token(P, _, _, data) A p A q (token(P, _, T, data) A p) V q
= { predicate calculus }
(60)
D Properties of graphs
The proofs of our algorithms rely on the following properties of undirected
connected acyclic graphs:
For any two nodes R and S, there is a unique acyclic path between R (61)
and S. This allows us to conclude that if we have produced some acyclic
path between R and S, that path must be the shortest path between R
and S.
S :: minPath(S, T) = reverse.(T:: minPath(T, S)) (62)
S = nextNode(R, T) A (nextNode(S, T)= nextNode(S, W)) = (63)
nextNode(R, T) = nextNode(R, W)
nextNode(S, T) nextNode(S, R) (64)
minPath(S, T) is disjoint from minPath(S, R)
