COM3190/COM6116 Theory of Distributed Systems Mike Stannett Department of Computer Science The University of Sheffield
[email protected] Spring Semester 2013–2014
Pi-Caculus Model of a Mobile Phone Network Imagine moving around the country while using a mobile phone. When you move out of range of the local phone mast, how does your call manage to stay connected? Presumably another mast has to take over, but how does this work in practice? And what if you’re within range of two or more masts – how does the system ensure your message isn’t being relayed by all the masts at once, causing the listener to hear your voice overlapped with itself several times over? This lecture considers a hypothetical protocol for handling the situation. You may be able to think of a better one.
1
The Scenario
Each Phone agent talks via a network of communication Mast agents, and the towers themselves relay their messages via a central MainMast. There is never any direct Phone-Phone communication; they always communicate via the MainMast. As a Phone moves around, it monitors the signal strength it’s receiving from the Mast it’s currently using; when the signal strength drops below some threshold, the Phone broadcasts a signal to all the local Masts, hoping to find one that can take over the job of relaying its messages. If none is available, it receives a Busy message, and the call gets cut off if it goes out of range of its current Mast. If a new Mast is available and willing to handle the Phone’s conversation, it says so. The phone then handles the changeover from one Mast to the next. • Phone monitors the signal strength from Mast1. • When low, the Phone broadcasts a message to find out who can take over. The phone is using two different channels at the same time – one for relaying the conversation, and one for negotiating a new Mast2. • If no new Mast2 is available, life gets difficult, otherwise we receive confirmation from Mast2 that it’s prepared to take over. • The Phone starts talking via two different Masts at the same time, both of which relay the conversation to the MainMast. Until told otherwise by the Phone, however, the 1
MainMast will ignore the messages from Mast2, and only pass on messages from the old one. • The Phone sends a message via Mast2 telling MainMast that it’s now using Mast2. The MainMast starts relaying messages received via Mast2 instead of those received via Mast1, and then sends back an acknowledgement to the Phone. • The Phone now knows that it’s safe to cut the connection with Mast1, and does so.
2
The Model
The model below reflects the choices expressed in this informal specification. In particular, it is obvious we’ll need to model three types of basic agent: Phones, Masts and MainMast. The first stage in developing a model of this kind is to identify the channels used by each agent (Figure 1).
Figure 1: The mobile phone network before hand-over To keep things simple, we’ll assume that the diagram shows the entire mobile phone system. There are two phones (these are both in use, and their users are talking to each other). Each phone is connected via a Mast to the MainMast relay station. We’ll assume that the phones are never connected to the same Mast.
2.1
Channels
The various channels have the following purposes:
2
2.2
negA, negB
Each phone owns a negotiation channel. It uses this to negotiate with a new Mast whenever it finds itself going out of range of its current one. It will recive details of the new talk and signal channels it has to use, and will also use it to send details of the old Mast’s connections, so they can be relayed to MainMast (so that MainMast can stop relaying messages via the old Mast).
2.3
talk1, talk2, talk3
Each Mast owns the various channels it uses for relaying conversations to and from each phone. When a phone negotiates to use the Mast, the Mast allocates the appropriate talk channel.
2.4
signal1, signal2, signal3
These channels are “virtual” – they’re used to represent the idea that the phone can detect the strength of the signal its receiving from the Mast. In real life, the phone would determine this by examining the signal arriving down the talk channel, but we need to separate out the two types of information so we can respond to different situations in different ways. Accordingly, whenever a Mast allocates a talk channel, it also allocates the corresponding signal channel. The signal channel is only ever used to send the message “signal strength has dropped dangerously low, so go off and find a new Mast” to the phone it’s connected to.
2.5
relay1, relay2, relay3
The Mast uses this channel to relay conversations to and from the MainMast relay station.
2.6
control1, control2, control3
Masts use these channels to communicate control-related messages to and from the MainMast relay station. If a Mast receives an unexpected control message it regards this as an instruction to become Idle.
2.7
bcast
This is a global channel shared by all phones and all Masts. When a phone finds its current signal strength is dropping dangerously low, it sends out a general broadcast to all available Masts, trying to find one that can take over relaying its conversation.
2.8
Behaviours
Now that we know what channels are available to each process, we can start to define their behaviours. • A typical phone has access to a negotiation channel (n), a talk channel (t) and a signal channel (s). It can receive or transmit conversation without changing its general behaviour; it can also receive a pulse along its signal channel warning it that signal
3
strength is low – it responds by becoming a BroadcastingPhone. Like all phones and Masts, it also has access to a general broadcast channel (b). To save time later, we’ll assume that when the “low signal” message arrives, it includes details of the old Mast’s control frequency (c); this will allow the phone to relay this information to MainMast after establishing a link with the new Mast, so that MainMast can then use c to turn off the old Mast. Phone(tsbn) = t.Phone(tsbn) + t.Phone(tsbn) + s(c).BroadcastingPhone(tsbnc) • A BroadcastingPhone repeatedly sends out a general broadcast until it receives a confirmation message from a Mast that’s willing to take over. To make this work, the responding Mast has to know the phone’s negotiation frequency, so the phone has to include this information in its broadcast. Essentially, it’s sending out the message “If any Masts can take over my conversation, please give me a call on the following number, n”. Of course, a BroadcastingPhone is still able to handle conversations. When the phone receives a confirmation message from a Mast, it receives details of the new talk (t0 ) and signal (s0 ) channels it will need to use, and then becomes a NegotiatingPhone. BroadcastingPhone(tsbnc) = t.BroadcastingPhone(tsbnc) + t.BroadcastingPhone(tsbnc) + bhni.BroadcastingPhone(tsbnc) + n(t0 s0 ).NegotiatingPhone(tsbnct0 s0 ) • For a phone to become a NegotiatingPhone, it has to have interacted with an IdleMast. What happens to the IdleMast as a result of this interaction? Clearly, it has gained access to the phones negotiation channel, and is now a NegotiatingPhone. It has also granted the phone access to its talk and signal channels. IdleMast(tsbrc) = b(n).nhtsi.NegotiatingMast(tsbrcn) It’s instructive at this point to see how the picture of communications channels has changed (Figure 2). At this point, the phone has become a NegotiatingPhone, and the IdleMast has become a NegotiatingMast. In doing so, the Phone and IdleMast have shared three channels. According to our protocol, the phone now sends a message to MainMast via the new Mast, telling it to stop relaying messages via the old Mast. At the same time, of course, it remains a phone, so continues to handle conversations. However, until it receives convirmation that MainMast knows about the changeover, it send its conversation out via both of the Masts. Having sent MainMast the relevant control-channel frequency, the phone becomes a WaitingPhone; it no longer cares about the control frequency information it’s just forwarded, so forgets it. NegotiatingPhone(tsbnct0 s0 ) = t.NegotiatingPhone(tsbnct0 s0 ) + t.t0 .NegotiatingPhone(tsbnct0 s0 ) + nhci.WaitingPhone(tsbnt0 s0 ) The NegotiatingMast passes the phone’s message to MainMast and gets an acknowledgement back (in the form of a pulse along the control channel). It forwards the acknowledgement 4
Figure 2: The mobile phone network during Phone-Mast negotiation to the phone, and then settles down to behave like an ordinary everyday relay Mast (it’s finished negotiating, so forgets about the phone’s negotiation channel). NegotiatingMast(tsbrcn) = n(c0 ).chc0 i.c.n.Mast(tsbrc) The WaitingPhone receives the acknowledgement pulse from the Mast, and knows that it’s safe to drop the connections to the first Mast. It becomes an ordinary everyday phone, but using the second Mast instead of the first. WaitingPhone(tsbnt0 s0 ) = t.WaitingPhone(tsbnt0 s0 ) + t.t0 .WaitingPhone(tsbnt0 s0 ) + n.Phone(t0 s0 bn) The standard behaviour of a Mast is to relay conversations in either direction, and possibly to emit a “low signal strength” warning. If it receives a control message from MainMast, it regards this as an instruction to become idle (it means that MainMast has received a message from the phone telling it to use Mast2 instead). Mast(tsbrc) = t.r.Mast(tsbrc) + r.t.Mast(tsbrc) + shci.Mast(tsbrc) + c.IdleMast(tsbrc) Lastly, the behaviour of MainMast needs to be explained. Since MainMast has 6 channels (2 for each Mast), we need to write it as MainMast(r1c1, r2c2, r3c3), where the commas are for clarity. Notice that the first pair and third pair are initially related to Masts 1 and 3, where the Phones are connected. If MainMast receives a message from Mast2, it uses the control frequency contained in that message to kill off one of the other Masts, and uses the new Mast
5
in its place (this is modelled by changing the order of the parameters, below). Otherwise, MainMast simply relays messages between Masts 1 and 3. MainMast(r1c1, r2c2, r3c3) = r1.r3.MainMast(r1c1, r2c2, r3c3) + r3.r1.MainMast(r1c1, r2c2, r3c3) + c2(c).c. ([c = c1]MainMast(r2c2, r1c1, r3c3) +[c = c3]MainMast(r1c1, r3c3, r2c2))
3
The Combined System
Finally, of course, we need to put all the bits together. We have a model of the MobilePhoneNetwork given by MobilePhoneNetwork = Phone(talk1, signal1, bcast, negA) |
Phone(talk3, signal3, bcast, negB)
|
Mast(talk1, signal1, bcast, relay1, control1)
|
IdleMast(talk2, signal2, bcast, relay2, control2)
|
Mast(talk3, signal3, bcast, relay3, control3)
|
MainMast(relay1, control1, relay2, control2, relay3, control3)
Of course, we may also choose to restrict various of these channels to ensure no external interference in communications. Typically, we’d argue that all of the channels are private to the phone network, so we’d define the system as (new bcast, t1, t2, t3, s1, s2, s3, negA, negB, r1, r2, r3, c1, c2, c3) (Phone(t1, s1, bcast, negA) | Phone(t3, s3, bcast, negB) | Mast(t1, s1, bcast, r1, c1) | IdleMast(t2, s2, bcast, r2, c2) | Mast(t3, s3, bcast, r3, c3) | MainMast(r1, c1, r2, c2, r3, c3)) Notice that since the channels are hidden, it doesn’t matter whether we call them signal1 or s1 (or anything else for that matter, because we’re allowed to replace bound names without altering the behaviour of the system). Other modellers might argue that the talk and signal channels are private to each Mast-Phone combination (since they allocate them), and the negotiation channels are initially private to each phone, whence the model should instead be
6
(new bcast, r1, r2, r3, c1, c2, c3) ( ((new ts)((new neg) Phone(t, s, bcast, neg)|Mast(t, s, bcast, r1, c1)) | ((new ts)((new neg) Phone(t, s, bcast, neg)|Mast(t, s, bcast, r3, c3)) | ((new ts) IdleMast(t, s, bcast, r2, c2)) | MainMast(r1, c1, r2, c2, r3, c3)
)
Writing the system this way shows that the phones really are behaving identically, as are the two connected Masts; the only differences between them are caused by the relay and control connections to the MainMast. Ultimately, however, the choice has to be up to you, as designer. As long as you can justify your model, that’s good enough.
7
