Denotational semantics of channel mobility in UTP-CSP

In this paper, we present the denotational semantics for channel mobility in the Unifying Theories of Programming (UTP) semantics framework. The basis for the model is the UTP theory of reactive processes, precisely, the UTP semantics for Communicating Sequential Processes (CSP), which is extended to allow the mobility of channels—the set of channels that a process can use for communication (its interface), originally static or constant (set during the process's definition), is now made dynamic or variable: it can change during the process's execution. A channel is thus moved around by communicating it via other channels and then allowing the receiving process to extend its interface with the received channel. We introduce a new concept, the capability of a process, which allows separating the ownership of channels from the knowledge of their existence. Mobile processes are then defined as having a static capability and a dynamic interface. Operations of a mobile telecommunications network, e.g., handover, load balancing, are used to illustrate the semantics. We redefine CSP operators and in particular provide the first semantics for the renaming and hiding operators in the context of channel mobility.


Introduction
In a network, channel mobility is concerned with the movement of a channel from one component to another, where channels are used by components to exchange messages.We will use the term dynamic network system (or simply dynamic network) to refer to mobile systems in which channels can move.By symmetry, we will use the term static system to refer to a static network system (or simply static network).
Pi-calculus [Mil99] is the first process algebra for reasoning about channel mobility.Pi-calculus represents programs as processes, whose semantics are operational; channel mobility is achieved by sending channels as messages through other channels, from one process to another.CSP [Hoa85,Ros10] is another popular process algebra for reasoning about concurrency in general, and networks in particular.However, CSP is limited to static networks.CSP has both operational and denotational semantics.
We are interested in CSP denotational semantics, precisely, UTP-CSP [HoaHe98,Chap. 8], an alternative presentation of CSP based on Unifying Theories of Programming (UTP) [HoaHe98], a framework whose aim is to unify the semantics of various programming languages and paradigms.UTP notably extends CSP with a richer notion of state and provides a mechanism for linking UTP theories using notions of Galois connections [HoaHe98,Chap. 5].
In this paper, we present mobile CSP, which extends static UTP-CSP [HoaHe98,CavWoo06] with the semantics of channel mobility.In mobile CSP, channels are treated as concrete entities and can thus be moved as messages between processes.Traces are enriched to record, in addition to the events history, the interface history of a process.We call the new traces dynamic alphabetised traces (DATs).We introduce a new concept, the capability of a process, which represents the universal set of channels and models the statement a process knows of the existence of channels (outside its interface).This allows us to refine the meaning of the interface as modelling the statement a process owns a given channel (in its interface).Mobile processes are characterised as having a static capability and a dynamic interface, formalised by new healthiness conditions.We redefine static CSP operators to reflect the changes in semantics due to channel mobility.The main updates concern input and output prefix operations, and parallel composition.Other processes such as assignment are updated only with regard to healthiness conditions.Two operators are particularly difficult to define in the presence of channel mobility, namely renaming and hiding.We present the first definition of static renaming and static hiding in the context of channel mobility-"static" here indicates that the operators work as in static CSP, i.e., the operators apply to the interface of a process provided initially, before any execution of the process.
This paper significantly extends [Ek16a], which contains many elements of the formalisation reproduced here.The following elements are presented in this paper and not in [Ek16a]: many operators, notably parallel composition, renaming and hiding; all the examples; a new healthiness condition, MC4. 1  The next section briefly introduces the semantics of UTP-CSP processes.Section 3.1, presents the formalisation of dynamic network systems in UTP; Sect.3.2 contains the semantics of mobile processes, Sect.3.2.4presents static renaming, and Sect.3.2.5 static hiding.We discuss refinement and issues related to the interrupt operator in Sect. 4. Finally, in Sect.5, we compare our results and their implications to related works, followed by the Conclusion, in Sect.6.

Generalities
UTP is a formal semantics framework for reasoning about programs, programming theories and the links or encodings between theories.The semantics of a program are given by a relation between the initial (undecorated) and final (decorated) observations that can be made of the variables that characterise the program behaviour.
A UTP theory is a collection of predicates and consists of three elements: an alphabet, containing only those variables that the predicates of the theory may mention; a signature, which contains the operators of the theory, and healthiness conditions, which are laws constricting the set of legal predicates to those that obey the properties expressed by the conditions.Healthiness conditions determine hence what predicate belongs to (can be defined/implemented in) a theory.
Healthiness conditions generally have the form: NAME P = f (P ), for some idempotent function f (i.e., f • f (x ) = f (x )).NAME stands for the name of the healthiness condition and is also used as an alias for f , i.e., we write P = NAME(P ) and we say that P is NAME-healthy.
A number of programming constructs and paradigms have been formalised using UTP.The most basic UTP theory is the theory of Relations [HoaHe98, Chap.2], which notably allows us to specify most of the constructs of sequential programming (cf.Appendix A).
In what follows we present the UTP theory of Reactive Processes, which allows representing concurrent programs and serves as a basis for defining UTP-CSP.

Reactive processes
The UTP theory of Reactive Processes [HoaHe98,CavWoo06] permits modelling programs that may interact with their environment.Reactive programs are defined as processes, i.e., predicates that allow us to characterise the intermediate states of a program, between initialisation and termination.
The alphabet of a reactive process consists of the following: Reactive processes must also satisfy the following healthiness conditions: R1 states that the occurrence of an event cannot be undone, viz., the trace can only get longer.R2 states that the initial value of tr may not affect the current observation.R3 states that a process does nothing when its predecessor has not yet terminated.II CSP is the process that changes nothing: If not started, ok = false, then only trace expansion can be observed; otherwise the values of the variables remain unchanged.
A reactive process is one that satisfies all three healthiness conditions above.We also say that it satisfies the healthiness condition R = R1 • R2 • R3.Note that the order of the composition is irrelevant (cf.[CavWoo06]).A particular model for reactive processes is provided by the CSP process algebra [Hoa85,Ros98], presented subsequently.

UTP-CSP processes: syntax and semantics
UTP-CSP processes (or simply CSP processes below) are reactive processes that obey the following additional healthiness conditions: CSP1 states that if a process has not started (ok = false) then nothing except for trace expansion can be said about its behaviour.Otherwise the behaviour of the process is determined by its definition.CSP2 states that a process can always terminate.It characterises the fact that divergence can never be required.
A CSP process is one that satisfies the healthiness conditions R, CSP1 and CSP2.We also say that it satisfies the healthiness condition CSP = R • CSP1 • CSP2.Again, the order of the composition is irrelevant.The syntax and semantics of some CSP processes are given in Appendix B.
CSP processes permit the representation of static systems only, i.e., systems whose network topology does not change during their activation.For that reason the model for CSP processes presented so far will be referred to as the static model of CSP or static CSP.In order to represent mobile systems, a number of changes need to be provided to that static model; they are presented hereafter.

Mobile UTP-CSP
In what follows, we present mobile CSP.The mobility model has three main characteristics: • channels are 'localised' in processes (viz., their interface); • channels can be communicated as messages amongst processes, hence channels are concrete entities; • the interface of a process (denoted by I hereafter) changes as a consequence of channel mobility.First, we discuss the formalisation of dynamic networks in UTP.

Definition of concepts
We will study channel mobility from the point of view of the processes involved, not that of the specifier.We assume that channels are unique, thus, a name clash between a process and its environment should not occur.If it occurs, then this will be considered an error.The Internet Protocol addressing schemes IPv4 and IPv6 and object identification in Object-Oriented Programming illustrate systems in which system elements, IP addresses and object identifiers respectively, are unique.Capability vs. Interface.In UTP-CSP, the interface of a process is a constant.In particular, it models the statement a process owns a channel, viz., the process can actually use that channel for its communications.Channel mobility implies that the interface of mobile systems must be a variable: it changes with the movement of channels.Let us talk of either static interface or dynamic interface, accordingly.
Where do new channels come from?For static systems, all the channels that are owned are defined for once: in the interface.Since new channels are not owned yet, we introduce a new set called the capability of a process to define channels that 'might' be moved.We thus separate ownership, entirely determined by the interface, from knowledge-of existence, determined by the capability.Unlike the interface, the capability is static.
Definition 3.1.1(Capability -MCh) Let MCh denote the capability of a process, the set of channels whose existence is known by the process.Its value cannot change.
In this paper, we will assume that every mobile CSP process has the same capability.This implies that there is no limit to what channel a process can acquire.This assumption may be broken without loss of generality, viz., it would not fundamentally affect the semantics presented subsequently.Channel names.In static CSP, channel names are just abstract identifiers in the sense that a channel name ch ∈ I represents/models a logical concept, 'the occurrence of a communication on the channel named ch', and not the channel itself.For channel mobility, channels must rather be modelled explicitly, as data elements: they will also be represented by channel names.For this purpose, it suffices to override the interface of processes to now contain concrete channels.The following variable will denote the interface of a mobile process.
Definition 3.1.2(mChans) mChans, mChans : P MCh, is the variable that contains the set of channels that have been acquired before the current observation, and are hence authorised.mChans contains the channels that will be authorised next.mChans (resp.mChans ) denotes the dynamic interface of a process.
Events of mobile channels.In static CSP, the interface of a process can be obtained only from its actions set A, i.e., I = {ch | ∃ e • ch.e ∈ A}.With channel mobility, on the contrary, we start with the channels since they are the ones that may be moved, and then we obtain the corresponding set of events.Hence, we define the set MCev that contains events related with mobile channels only, i.e., events of the form c.m where c ∈ MCh.
Definition 3.1.3(MCev ) Let MCev denote the set of events (or actions set) obtained from MCh.

MCev = {ch.e | ch ∈ MCh}
In static CSP, the empty trace records that no event has occured.In mobile CSP, it will be more convenient to represent the null event explicitly.
Definition 3.1.4(Null event) Let nil denote the null event.It represents that no event has occured.
That is, both and nil denote the empty trace (were nil used in static CSP).The following definition summarises the actions set for mobile processes, denoted by Σ. Definition 3.1.5(Σ) Let A denote the actions of a process, viz., it does include communication events from static channels only and other kinds of events.Let Σ denote the actions set for mobile processes, then: The previous definition assumes the possibility of defining some channels as static, but this is not essential and is not enforced in the subsequent semantics.
is the initial interface of a process.

Refusals.
Let dref denote the refusals set for mobile processes.The static type for dref will be P Σ.Then, it is necessary to restrict the value of dref such that owned events only may be refused.This can be achieved by means of a healthiness condition (cf.MC3 below).
Snapshots.The observation of a dynamic network may be divided according to its different topologies.A process is said to have a static (or fixed) network/topology when its interface is the same whatever the elements of its DAT.Formally:  A process must have at least two distinct snapshots (viz., must be the concatenation of at least two distinct SN processes) to be considered of having a dynamic topology.In other words, at least two consecutive elements of its trace must have different (but not disjoint) interfaces.Formally: Definition 3.1.11(DN) P has a dynamic network topology or simply P is dynamic if P = DN(P ).That is, ∃ k : mChans k = mChans k +1 , where mChans k and mChans k +1 are not disjoint.
Example 3.1.1Consider the network of three processes P , Q and R connected as shown in Fig. 1(left).Another possible topology for such a network can be obtained by removing the link ch 1 between P and Q, then using ch 1 to connect P and R instead, as shown in Fig. 1(right).The left and right networks define two snapshots.

Healthiness conditions
The guarantee that a process must use only channels that it already owns is expressed by the following healthiness condition: Definition 3.1.12(MC1) MC1 P = P ∧ ∀ s : P MCh, e : Σ • (s, e) ∈ dtr ⇒ e ∈ s MC1 states that every event e that is recorded must belong to the dynamic interface s (the associated actions set) valid at the time of the recording.
By definition, the mobility of a single channel (or of many together) induces a snapshot dichotomy between the topology before the movement and the one after.So, for a trace (s 1 , e 1 ), (s 2 , e 2 ) , where s 1 = s 2 , (s 1 , e 1 ) would belong to the first snapshot and (s 2 , e 2 ) to the second.That is, in a single step, it should only be possible to release the whole of the actual interface at once, but not to acquire a new channel at the same time.This is expressed by the following healthiness condition: Definition 3.1.13(MC2) MC2 also translates the idea that the dynamic interface is always fixed (or completely determined) before entering a new snapshot, and that it is the previous snapshot (process) that fixes it.
The healthiness condition expressing that owned events only can be refused is given below.

Definition 3.1.14 (MC3) MC3
Note that mChans is used above for economy of notation, to denote the corresponding set of events, say mCev .MC3 corresponds to a law on refusals for static CSP processes (cf.[Hoa85, §3.4,L8]).3Earlier we introduced the nil notation to denote that no event has occured.The events history of a process can be empty.In contrast, the interface history should not be empty as we expect it to contain at least one element, the value of the initial interface.What about the final value of the interface history?Initially, mChans = mChans = last π 1 (dtr ), i.e., the last value of the interface history, last π 1 (dtr ), coincides with mChans .However, it is possible to acquire a new channel, say newch, without simultaneously updating the interface history, as in ..., ({in}, in.newch) ; whereas a simultaneous update would give the trace ..., ({in}, in.newch), ({in, newch}, nil ) instead.The condition mChans = last π 1 (dtr ) implies that the interface history must mirror the value of mChans at all times, which is desirable.The values of mChans and π 1 (dtr ) would thus be redundant.If we try and remove the redundancy by eliminating mChans, mChans from our model, the previous condition would need to be changed.We think it better to keep the history separate from what it records, so we will keep using mChans, mChans .
DATs lead us to reconsider the healthiness conditions R1, R2, R3, CSP1, and CSP2 (cf.§ 2.2).The main issue here is substituting the symbols tr , tr , ref , ref for dtr , dtr , dref , dref , respectively.Semantically however, there is not much change.For readability, each Rk healthiness condition will be renamed RkM.Definition 3.1.16(CSPM) where Definition 3.1.17(MCr1, MCr3, MCcsp1) Let mtr = π 1 (dtr ) denote the interface history of a process, let tr = π 2 (dtr ) denote its events history.Then, when replacing dtr by tr in the equations above (Def.3.1.16),we obtain the traditional CSP healthiness conditions.We also obtain three new healthiness conditions when replacing dtr by mtr in the condition dtr ≤ dtr , namely: where MCr1 means that the interface history only ever grows.MCr3 means that when a process is waiting for its predecessor to terminate (wait = true) and the predecessor is not stable (ok = false), then we can observe the interface history growing.MCcsp1 means that when a process is not stable (ok = false), we can yet observe its interface history growing.
We now provide some important properties of the previous healthiness conditions.

The semantics
In this section we present the denotational semantics of channel mobility.As every UTP theory, it must have three elements: an alphabet, a signature and healthiness conditions.The highlight of this section is the semantics of the operations that may change the interface of a process during its activation, channel-passing input and output prefixes.We also provide the first semantics for renaming and hiding in the context of channel mobility.
The following definition summarizes the previous discussions.

Some mobile processes
Assignment, SKIP.The following definitions are similar to their static CSP formulation, but made healthy for mobile CSP.In particular, local assignments to mChans are forbidden as the interface should grow and shrink as the result of channel passing communications only (see below).Hence mChans = mChans and MC4 holds.MC3 ensures that we get the right value of dref , dref .Since dtr = dtr , no modification of the value of the trace is possible, hence assignment is vacuously MC1 and MC2 healthy.

obeys all assignment laws. SKIP obeys all skip laws [Hoa85]-see also Appendices A and B.
Proof One way of proving this theorem may be to apply Def.3.2.2 to every law in Appendices A and B and see if it holds.Here instead, we show that our definition is additive in the sense of Abrial [Abr84], then it preserves all the laws of the formula that it extends.Let [| P |] th denote the encoding or semantics of a given predicate P in a given UTP theory th.Let rel and csp denote the UTP theories of Relations [HoaHe98, Chap.2] and CSP [HoaHe98, Chap.8]-see also Sect.2; and let mob denote mobile CSP.We have: That is, for assignment, csp extends rel , viz., there is an additive transformation that extends theory rel to yield theory csp.We now see how this implies law-preservation.We show similarly that, for assignment, mob extends csp.Recall, mtr = π 1 (dtr ), tr = π 2 (dtr ). [ From what precedes, we trivially have: Unchanged definitions.The semantics of STOP and CHAOS remain unchanged.The semantics of the following operators are also unchanged: iteration (b * P ), substitution (P [e/x ]), sequential composition ( ), conditional ( b ), internal choice ( ), and external choice (2)-cf.Appendix B. Prefix.In static CSP, the occurrence of an action a is denoted by the predicate do A (a).For an alphabetised event (s, e) we want to record the dynamic interface s as well as the event e, thus enforcing MC1.The value of s may be given by the value of the variable mChans at the time of the recording, thus enforcing MC4.We apply MC2 to constrain the values of mChans, mChans , and MC3 for dref .The process that is ready to engage in event a and then increments its DAT when a has occurred, or simply records the current dynamic interface (to serve as the valid interface for the next process) is denoted by do Σ (a).Theorem 3.2.2Def.3.2.3obeys all the laws of prefix [Hoa85]-see also Appendix B.

Channel-passing
Moving a channel has different effects depending on whether the channel is being moved out (released) or moved in (acquired).Release.Moving out/sending out a channel implies that the channel must no longer be authorised, viz., it must be removed from mChans.Clearly, any attempt of moving out a channel, say oldch, not already owned must fail.The release event is recorded as in do Σ , whence MC1 holds.Because of MC4, the new value of mChans must be recorded into the trace, e.g., (mChans, rel .oldch)(mChans , nil ) .Then, any future refusal may not contain the event that has just been removed.This further means that all of the events related to the released channel must be removed from dref as well (if they were already in dref ), to avoid chaotic behaviour-MC3.We apply MC2 to constrain the values of mChans, mChans .Definition 3.2.4(Channel-passing output prefixes) Let oldch be the channel to be released; let α oldch denote the corresponding set of events.When the sending process moves out oldch and loses its value, we talk of move or copy-then-delete semantics: When the sending process moves out oldch but still retains its value, we talk of copy or clone semantics: Moving in /receiving a channel newch requires that the receiving process must not own newch prior to receiving it.The value of mChans is incremented with newch and then recorded into the trace-for reasons invoked previously, the following definition is MC134 healthy.

Parallel composition
The semantics of the parallel composition operator are similar to the static CSP definition, except that the trace merge must take into account the new structure of the events.The aim is to preserve the merge of events histories as defined in static CSP, and specify only that of the associated interfaces histories.
Channel-passing operations (cf.§ 3.2.2) perform two actions that are somewhat causal: the input or output of a channel and then the record of the next interface.That is, the operations yield events of (loosely) the form (i 0 , mov .ch)&(i 1 , nil ), viz., the events always go together and in that order.This ordering is guaranteed by the definitions of the channel passing operations, but may be broken in the presence of interleaving.Hence, any correct interleaving must preserve the expected ordering.For illustration, we would expect the following: The following definition also ensures that we never have sequences (i , a) & (i , nil ), since (i , nil ) elements mark the beginning of a new snapshot and should not occur after any other event within that snapshot.
Definition 3.2.6 (DAT parallel merge) Let s and t be two traces.Let E (s) denote the set of events in s.Let a, b, c, d be (pairwise distinct) events such that: . Then, we define the (DAT) trace merge for parallel composition by recursion as follows: Definition 3.2.7 (Parallel composition) Since a process cannot create a channel by itself, the interface of a parallel composition cannot grow of its own.

Renaming
The interaction of renaming (resp.hiding) and channel mobility gives rise to a number of issues, e.g., it should not be possible to rename (resp.hide) in advance a name not yet acquired.This section is concerned with the semantics of renaming.The semantics of hiding will be presented in Sect.3.2.5.

Formalisation and semantics
Let P = a → SKIP .P [b ← a] = b → SKIP is the process that engages in action b whenever P engages in action a.Let f : I P → I f (P ).Then (in static CSP): f (P ) = P [I f (P ) ← I P ].Renaming applies to channels as well, when we would like to define the process P [ch 2 ← ch 1 ] that engages in a given channel ch 2 whenever P engages in a distinct channel ch 1 .Let Renaming works here since ch 1 ∈ IP .In contrast, P [ch 2 ← ch 3 ] = P is vacuous since ch 3 ∈ IP .A number of issues arise, however, in the presence of channel mobility.
Let Q = in??x → x !v → SKIP .Name mismatch occurs when one tries the renaming Q[ch 2 ← ch 1 ], in anticipation that x = ch 1 (foresight).If Q never inputs ch 1 then the intended renaming is vacuous, otherwise, it would be unhealthy for two reasons: (1) unknown names, which occur in applications where it is actually impossible of knowing in advance what channels will be acquired in the future; nonetheless, since renaming must defined over P MCh, (2) name collision can occur if a substitue name coincides with an acquired name.E.g., let R = ch 1 !w → Q and assume x = ch 2 , then R[ch 2 ← ch 1 ] = ch 1 !w → ⊥ is unhealthy.This indicates that channel mobility provides a scope or limit to the application of renaming such that renaming should not apply to acquired names.

Static renaming
Let mChans k (k ∈ N) denote the k -th value of mChans recorded in a given trace (Def.3.1.8).If, for all k , mChans k = mChans k +1 , then, the corresponding process is static and none of the issues mentioned above can occur.The semantics of renaming is thus strictly identical to the definition in static CSP.Else, if there exists a k , mChans k = mChans k +1 , then, we are in the presence of channel mobility and we must deal with the issues mentioned previously.
Syntactically, the only operation that implies mChans k = mChans k +1 and which should concern us is channel passing input prefix-channel passing output prefix would render renaming vacuous for the removed channel.We can then avoid name mismatch or foresight by using the following definition: (no-foresight) guarantees the following postcondition for the renaming operation: if f (mChans 0 ) is defined (viz.f is defined over channels in mChans 0 ) then for all k > 0, f (mChans k +1 − mChans k ) = mChans k +1 − mChans k (viz.f should be undefined over channels in mChans k +1 − mChans k ; however, because f must be injective to avoid undefinedness, f behaves like the identity function over future names).
We must further ensure that if ch ∈ mChans 0 and ch ∈ (mChans k +1 − mChans k ), then f (ch) is defined/renamed upto the snapshot [k , k +1], from which f (ch) = ch.That is, channel mobility limits the scope of the application of renaming.(no-foresight) does not guarantee scope restriction, because it is based on syntax.We must impose (renaming) scope restriction on the semantics of renaming, viz., rename−scope condition is also sufficient to ensure that renaming has no effect on mobility.
Let Amc denote the set of all acquired mobile channels during a given observation.Then, mChans 0 −Amc denotes initial channels that are not later released-then-acquired.These are the only channels that can be renamed.Definition 3.2.8(Acquired mobile channels) Let E (t) denote the set of all the elements of a given trace t, e.g.E ( ..., (s k , e k ), ... ) is composed of elements (s k , e k ).
We now give the definition of static renaming in the presence of channel mobility.In static CSP, a renaming function f is defined over a constant set, the interface I.In mobile CSP, it must be defined over the variable set mChans such as to obey rename−scope.We thus define renaming in terms of the substitution operation (cf.Appendix B) as follows: Definition 3.2.9(Static renaming) Let u = {dtr , dref , mChans}.Let f : P MCh → P MCh be an injective function.Let f | B : B → P MCh denote the restriction of f on a given (non-empty) set B ∈ P MCh.
Notation.Subsequently, for convenience, the notation [ch] will be used denote the variable that has (presumably received) channel ch for value.

Example 3.2.2 (Renaming scope restriction)
More generally, f is a valid static renaming function iff

Hiding Formalisation
A process does not need to know at all whether or not a channel is silent (i.e., hidden from the environment, does not appear in the interface).Indeed, the knowledge of a channel confers a communication functionality (over the given channel), not an abstraction functionality.It is hiding (the operator) that provides the abstraction functionality.Thus, communication concerns should be separated from abstraction concerns.In other words, for a given process P , the specification of its interface IP only signifies that P may communicate through a given channel ch ∈ IP .It does not matter how and when and if ch was acquired at run-time.It is hiding, P \ X , that specifies in X what channel is to be considered silent.Channel mobility opens up the possibility for hiding acquired channels at run-time.The corresponding operation will be called dynamic hiding, is common in both telecommunications network and computer networks.For example, some channels can be leased for private use by a network operator, thus forming a Private Branch eXchange (PBX).Other users in the network cannot access the PBX, and many PBXs can be created throughout the lifetime of the network, thus constituting instances of dynamic hiding.Dynamic hiding can also occur in a client-server application when, for example, a new server is added into the network for load balancing.The link between the old server and the new one is generally invisible to the clients, thus constituting an instance of dynamic hiding.In this paper, we will limit ourselves to the semantics of hiding as defined in static CSP, henceforth called static hiding.Dynamic hiding requires first extending (mobile) UTP-CSP theory, which is beyond the scope of this paper.
Channel mobility initroduces the possibility of name collision between a newly acquired channel and a silent one.This is unhealthy.As for renaming earlier, channel mobility restricts the scope of application of hiding such that hiding should not apply to acquired names.

Static hiding
In static CSP, hiding applies to the channels in the interface only, viz., P \ X = P \ X ∩ IP .In mobile CSP, we must ensure that hiding applies to channels in the initial interface only.Since in mobile CSP a channel in the initial interface may be released then acquired, hiding must not apply to an acquired name, independently of its release/acquisition history.That is, only channels in X ∩ (mChans 0 − Amc) can be hidden.

Example 3.2.3 (Hiding scope restriction)
Notice the similarity with the static CSP process (a → SKIP ) \ {a} a → P .In fact, we have an equivalence if we also hide the channel passing actions as follows:

Example: a mobile telecommunications network
A mobile telecommunications network has three main elements: a user/client (caller or receiver); a base station or BTS and a control station or BSC-see Fig. 2. -Client: dials a number and then waits for the acquisition of a (new) transmission channel; then, it engages in a conversation for some time.At the end of the conversation, it releases the channel acquired previously; during the conversation, it may receive a handover request (through signalling channels) in which case it releases its current transmission channel and waits for the acquisition of a new one.Note that we are interested in the hard handover in which the client can hold a single transmission line only.talk and listen are the channel ends received by a client, Client, through the channel carrier alloc.The event hangup models the action of a client that puts an end to a transmission-this is the normal termination of a call.Then, the client releases its talk and listen channels through the channel carrier release and is again ready to dial a number.A client also releases its talk /listen channels when it receives a handoff request, modelled by the handoff event; this time however, the client waits for another talk /listen channels before resuming its conversation.
-Base Station (or Base Transceiver Station or BTS): is composed of a limited number radio (or transmitter/receiver or TRE) stations and is in slave-master relation with a BSC.Let maxTRE ≥ 2 denote the maximum number of TRE that a BTS can contain.Each TRE is either idle, then it is waiting for a communication with some Client, or it is transmitting, or it is faulty.A faulty TRE can no longer communicate; it is defined as the process that has disposed of its channel (ends).
TRE receives messages from a client and forwards them to another.Above, a fault occurs randomly, then TRE behaves like FltyTRE .FltyTRE disposes of the faulty channel through the dispose channel and then does nothing.The definition of TRE may be refined by using the interrupt operator iev [McEw10] instead.Then, it is the ocurrence of an interrupt event iev that would cause TRE to behave like FltyTRE .Notice the use of listen?x (resp.talk !y), instead of [listen]?x(resp.[talk ]!y), since talk and listen channels belong to the BTS already, whilst a client needs to acquire them instead.
BCSslave receives commands from the BSC, then it releases its communication links with a Client.cmdallocate makes the BTS allocate a channel to a client; cmdretrieve makes the BTS retrieve a channel from a client.When the client hangs up, the BTS automatically retrieves its communication links, without prior receiving a command cmdretrieve from a BSC.retrieve is the channel carrier used by the BTS for retrieving a transmission channel that was previously sent to a client; it is also the counterpart of the release channel used by the client when releasing an acquired channel.
-Control Station (or Base Controller Station or BSC): may communicate with a limited number of assigned BTSs through signalling/command links, cmdallocate, cmdretrieve.Let maxBTS ≥ 2 denote the maximum number of BTSs that can be supervised by a single BSC.BSC = j <maxBTS j .cmdallocate→ (BSC HandOver LoadB LoadB 2) A handover operation occurs on two instances.In the first instance, the handover is due to a client changing its coverage area: this is modelled by the process HandOver (viz.handoff event).In the second instance, the handover is due to load balancing (the client has not changed its coverage area, but the latter is full): this is modelled by the process LoadB (viz., loadb event).Load balancing may occur before the attribution of channels to a client, when the client is in an area that was full before the client initiated its call: this is modelled by process LoadB 2. After either a handoff or a loadb event, the BSC commands the current BTS to release its communication links and another BTS to communicate to the client.
-User-Network Interface (or UNI): the part of a telecommunications network composed principally of clients and BTSs.Below we define a subnetwork covered by a single BSC.Let BTS n denote a collection of a given number n of BTS.
where n ≤ maxBTS Note that when a channel fault occurs, say on the nth BTS, -In the previous definitions, the BTS had a static number of TREs which could decrease in case of a faulty channel.In what follows we describe the case where the BTS may acquire new TREs.Let BTS k denote a BTS containing a given number k of TRE.

Further considerations
Interrupt.The interrupt operator, P Q, models the behaviour of a process P whose execution may be interrupted by a process Q.An interrupt event, denoted by i , is then used to model the occurrence of an interrupt.In UTP, McEwan et al. [McEw10] define semantics of the interrupt operator (for reactive processes) based on sequential composition.That is, in modified P (i → Q) = P i Q, Q is allowed to start executing if P is in a waiting state; whilst in traditional sequential composition, P must terminate before Q is allowed to start.Different semantics may be given to the interrupt.In particular, the interrupt operator can be defined based on parallel composition.Then, explicit representation of time is often used.In modified P i → Q = P i → Q, an analysis of the time stamps of the events from P and the occurrence of the interrupt event i allows recovering the final trace as follows: 4 From what precedes, it comes that the occurrence of an interrupt event has of itself no effect on channel mobility: the interrupt will occur either before the channel-passing action or after.
There is a case, however, where interrupt can have an interesting effect on channel mobility: when process migration or code mobility occurs.Process migration [Fug98] can be defined as the interruption of an executing unit (process, source), followed by its migration to a target executing environment where the interrupted process will resume its execution.In other words, process migration is "interrupt-then-code mobility".The author has provided a formal semantics for process migration as a form of interrupt mechanism where the interrupt routine, i.e., Q in P Q, performs code mobility (cf.[Ek16, §5.5]).Then, if the code to be moved contains a channel-passing operation, the effect of channel-passing will likely be observable in the target process instead of the source.Tang and Woodcock [Tang04b] provide semantics for code mobility in UTP-CSP.We note here that modelling process migration requires modelling unstructured programming primitives such as jumps.The author and Woodcock have used the concept of continuation to represent jumps in UTP, [Ek16b], extending prior work from Hoare and He [HoaHe98,Ch. 6].Thus, a theory that aims to account for both channel mobility and process migration will be somewhat complex, as it should account for continuations, time, un-timed message-passing and channel-passing features.Refinement.Let S and D denote any static and dynamic processes, respectively.Let snap denote the number of snapshots of a process.Then, snap(S ) = 1 and snap(D) ≥ 2. Let D = S 1 car .unknS 2 .If we view unkn to be a symbolic value, viz., a channel itself, then, the interface of D is computable at compile time, i.e., ID = IS 1 ∪ {car } ∪ IS 2 ∪ {unkn}. 5As a consequence, we can reason about the traces and refusals of D as in static CSP; hence, the refinement calculus ([Ros10], cf.Appendix D) remains unchanged.However, unkn is actually a variable, and mappings unkn → new are important for refinement.
Let D = S 1 car .unknS 2 .We want to establish the conditions for refinement between D and D .For ease, we will write A <> B to mean that sets A and B are disjoint, i.e., none is the subset or equal of the other: In order to formally achieve the mapping unkn → kn mentioned above, we remark that if D is sent a channel kn, then D will receive kn.Then, we need only to place D and D in an environment, say ε, that has kn in its interface.Then, D D ⇔ ∀ ε : D ε D ε.It remains for us now to formalise the conditions expressed above in terms of traces and refusals.We leave this for future work.

Related work
The concept of a DAT (Dynamic Alphabetised Trace) captures changes of interface, and similar dynamic traces have been used in [HoaOh08].However, we have seen that without the concept of capability, DATs are insufficient for characterising channel mobility.Hence, mobile processes must have a static capability and a dynamic interface.The notion of capability is original to this work.Its introduction to the works cited below is necessary for their validity and would pose no difficulty.
No model in the literature is a direct extension of CSP as in this work.Vajar et al. [Vaj09] propose an extension of CSP||B with channel mobility.[Vaj09] explores a limited form of mobility where channels are passed from B machines to CSP controllers only.There is no concept of capability, and the interface of processes is not discussed.As a consequence, no healthiness condition is defined over traces of mobile processes.
Hoare and O'Hearn [HoaOh08], and Roscoe [Ros10a,Ros10b,Ros10] both propose preliminary models for mobility in CSP.Hoare and O'Hearn [HoaOh08] investigate an analogy between separation logic and channel mobility from which they extend CSP.[HoaOh08] contains a different traces model than the DATs used here.Indeed, instead of pairs (interface, event), each interface and event occurrence is recorded separately.Then, in a trace, odd elements are all interface values whilst even elements are events.There is no concept of capability, and their investigation is limited to traces only, whilst our work covers also failures and divergences.In [HoaOh08], a channel can transmit a copy of itself, which to us is very counter-intuitive.
In [Ros10a,Ros10b], Roscoe proposes different possible models for mobile CSP, all based on CSP operational semantics.Unlike [Vaj09] and [HoaOh08] whose approach may be qualified as 'dynamic traces', [Ros10a,Ros10b] attempt to model Pi-calculus [Mil99] fresh names mechanism in CSP.This results in many models with complex semantics.The models are also limited to traces semantics, although directions to extend that work to failures are given.In [Ros10], Roscoe introduces a closed-world semantics for mobile CSP, but the concept of closed-world is not well-defined therein.Indeed, if P Q is closed-world [Ros10] means that P and Q alone can exchange channels, then P and Q individually must be open-world.However, in [Ros10], Roscoe proposes closed-world as the basis for defining open-world semantics.
Bialkiewicz and Peschanski [BialPes09b] provide a CSP-like traces model for Pi-calculus [Mil99].The resulting traces model, which we call localised traces, takes into account both fresh names-constructed differently from [Ros10b]-and branching information.The localised traces model is significantly more complex than traditional CSP traces and, since it is targeted to represent Pi-calculus processes, it is not evident how to relate it to CSP itself.
Welch and Barnes [WelBa08] propose a CSP semantics for the programming language occam-pi, however, their result is not abstract enough.We discuss how to model occam-pi channel mobility mechanism in greater detail in [Ek16, §3.2.2].Hereafter is a summary of our modelling approach.Occam-pi is a process-oriented programming language that supports channel mobility, amongst other features.A channel is represented as a pair of channel ends, and all the channels that can be used in the communication between two processes are grouped together as a bundle.A bundle has two ends called client and server respectively.Both bundles and channels are defined/implemented as mobile data types.In [WelBa08], bundles and mobile channels are modelled as indexed CSP processes, respectively, Bdle(bId , nbFlds) and ChFld (bId , chId ), where bId uniquely identifies a CSP bundle process, nbFlds its number of channel-field (component) processes; chId uniquely identifies a channel-field process within a bundle.Essentially, Bdle(bId , nbFlds) = 1≤chId≤nbFlds ChFld (bId , chId ).ChFld is a process that communicates through three channels: rd for input, wr for output, and ack for acknowledgement.An occam-pi program, Oπ, is modelled as the parallel composition of two processes: the application (system) process, AS , and the mobile channel kernel, MCK , i.e., Oπ = AS MCK .AS is the actual application, and MCK is a server of channels.AS processes can communicate through static channels as typical CSP processes do; or else they can communicate through bundles provided by MCK .An AS process may request MCK to create a new bundle, then will receive bId in return.Channel mobility is then achieved by communicating bundle indexes from one AS process to another.
In [WelBa08], since channels are modelled as processes, one may rightly expect to see (bundle and channelfield) processes move-this is not the case.The model closely follows the implementation architecture, hence it is not abstract enough.Let AS = P Q.Since in [WelBa08] the interfaces of processes do not and cannot change-given that indexes are passed around and not channels themselves-we are bound to conclude that the passing of bId say from P to Q is like a guard on the use of ChFld channels, as Q would need to have ChFld channels in its interface already, by definition-occam-pi programs are static CSP processes, in [WelBa08].We can simplify the model from [WelBa08] if we remark that ChFld channels only are indexed, i.e., by force of the indexing mechanism, ChFld channels become triples (bId , chId , chan), where chan ∈ {rd , wr , ack }.An indexed channel is simply a channel.(Since CSP channels are unique by their name, providing uniqueness by indexing is superfluous.)We also amalgamate all three rd , wr , ack channels into a single mobile (CSP) channel, say mch.We are thus left with Bdle = ChFld , with interface {mch}.Then, we eliminate the process Bdle by reducing it to its interface, given that it served only to provide channels to AS .Similarly, we eliminate MCK by reducing it to its interface, which is the set of all possible mobile channels.Given that any AS process could access MCK process, we add MCK 's interface to the definition of all AS processesthis corresponds to the capability of AS , not its interface.We are thus left with a single process, AS (viz., Oπ = AS ), whose capability is defined by the interface of MCK ; the interface of AS is determined by a set of static channels and the interface of Bdle processes (viz., the set of indexed channels-varies with the index acquired/released by the AS process), which defines mobile channels.From this, we easily achieve channel mobility by modelling every index passing operations say move!bid by a channel passing operation move!!mch, where pairs (bid , mch) are unique.
In the context of dataflow models, Grosu et al. [GroSto99,Sto99] provide an extension of FOCUS with channel mobility, called mobile FOCUS.This is the first attempt known to the author for giving denotational semantics to mobility.The semantics of a FOCUS component are given by its messages history, extracted from its communications history.In mobile FOCUS, channels are moved as messages between components (or processes, in CSP terms), whose semantics are defined by timed histories.Time is central in characterising mobility as it is used to restrict the valid channels at a given observation time.Furthermore, [GroSto99] considers that time is essential for characterising channel mobility, that is, channel mobility could not have been characterised without time.However, the results presented in this paper contradict the later conclusion.In effect, channel mobility implies a time division between the time before and the time after the movement.That division is implemented in the difference between the interface before and the interface after (the movement), so that it is not necessary to represent time explicitly in their model.
Stølen [Sto99] considers the environment of a FOCUS component as any other component, thus channels are hidden from the global interface, as in static hiding.However, [Sto99] distinguishes for each component its internal interface from its external interface, and then imposes that each component should have a disjoint internal interface.Whilst the external interface can grow, the internal interface remains static.Hence, the separation between internal and external interface only serves to prevent name collision, such that an internal name may not appear in the trace.
Recently, Woodcock et al. [Wood15] present a version of mobile CSP based on the Reactive Designs formulation of UTP-CSP [CavWoo06].In contrast, this paper contains a Reactive Processes formulation of UTP-CSP.[Wood15] provides interesting examples for the application of mobility in general, and mobile CSP in particular.Renaming and hiding notably are not discussed in [Wood15].It would be interesting to study how channel mobility affects the link [CavWoo06, §6.2, Thrm.2, p.38] between Reactive Processes and Reactive Designs.
In the literature of Pi-calculus, no work provides semantics for the renaming operator.
In order to model secrecy, Giunti et al. [Giu12] define a hiding/secrecy operator for Pi-calculus, resulting in a new theory called Secret Pi-calculus.In [Giu12], the main effect of the secrecy operator is to prevent the extrusion or output of (channel) names declared secret.The secrecy operator, therefore, must not be confused with CSP hiding.
In [Sang96], Sangiorgi et al. investigate the possible relationship between CCS and Pi-calculus.They distinguish internal from external mobility, leading them to define a specific characterisation of internal mobility for Pi-calculus, called πI (see also [Borea98]).Internal mobility applies to Pi-calculus with a leftmost restriction operator (viz.νx (P Q) or (νxP νyQ), where P and Q are Pi-calculus processes)-only restricted names, x , y can be moved.Their treatment of external mobility yields more complex formulations than πI .In external mobility, non-restricted names can also be moved.The main-perhaps the onlydifference between internal and external mobility is that the latter allows the possibility for a process to acquire a name that it already owned.Hence, our work models internal mobility.Furthermore, we consider internal mobility to be the only valid definition of channel mobility.It is nonetheless possible to remove the restriction on acquired names in our semantics simply by removing the corresponding condition, ch ∈ mChans, from the semantics of channel passing input prefix (cf.Def.3.2.5).

Conclusion
We have presented an extension of static CSP with channel mobility, based on UTP semantics framework.The resulting theory, called mobile CSP, allows passing channels as messages between processes as in Pi-calculus.Mobile processes are charaterised as having a static capability (viz., introduced to model the knowledge, by a process, of the existence of channels) and a dynamic interface.New operations have been defined for channel passing, namely channel passing input and output prefixes.A process cannot receive a channel that it already owns, otherwise channel mobility would be vacuous; and it cannot send a channel it does not own already.Channels are characterised as concrete entities.Of particular importance is the fact that a channel name does not entirely characterise a channel, but its presence in the interface does.
We have shown that mobility must be defined from the perspective of a process, for which the world is always open, as modelled by the capability set.This perspective being the right choice is confirmed when dealing with renaming and hiding.We thus avoided a number of difficulties encountered in [GroSto99] and [Ros10b].Overall, this work has resolved a number of issues related to representation and manipulation of (channel) names in calculi of mobility, notably issues of closed-and open-world, of internal and external interface, issues that may greatly cloud understanding and reasoning.
Two operators of interest to the author are dynamic renaming, which would allow a process to rename acquired names at runtime, and dynamic hiding, which would allow a process to hide acquired names at runtime.The author expects to present these operators in the near future.The mechanisation of mobile CSP is an interesting future work that would confirm the preservation of the laws of operators and further allow analysing/proving properties about mobile systems in a theorem prover.
Whilst Pi-calculus remains the main reference for formal semantics of channel mobility, we think that mobile CSP provides a more solid semantic basis.We expect future applications of mobile CSP to prove this claim to be valid.For example, a result available in the CSP world but not in Pi-calculus is the definition of transformations from DN healthy processes into SN processes.The latter result will soon be published.
A formal comparison with Pi-calculus is still missing, although attempts have been made to bridge the gap between (static) CSP and CCS.Assuming the existence of a link between CSP and CCS, it is possible to link mobile CSP and Pi-calculus if, following the link between mobile CSP and CSP, a formal link could be built between Pi-calculus and CCS.The definition of that link is currently undergoing and results should be published soon.

Fig. 1 .
Fig. 1.Channel Mobility with 3 processes.(left) Before the migration of ch 1 .(right) After the migration of ch 1 In words, the laws about [| x := e |] csp can be derived from those of [| x := e |] rel .There is thus no need to prove the laws of [| x := e |] rel for [| x := e |] csp .This is the essence of additive definitions [Abr84].

Fig. 2 .
Fig. 2. A mobile telecommunications network Clearly, when the initial interfaces of D and D are disjoint (IS 1 <> IS 1 ), refinement cannot be established between them.Also, if ID ⊆ ID up to a given snapshot and later ID ⊇ ID , refinement cannot be established.Let D.ch denote channel ch ∈ ID.Let IS 1 ⊆ IS 1 and let IS 2 \{S 2 .unkn}⊆ IS 2 \{S 2 .unkn}.Then, were it not for channel passing input, D and D would be in a refinement relation.If D.unkn = D .unkn, then IS 2 ∪ {D.unkn} = IS 2 ∪ {D .unkn}and there can be no refinement between D and D .However, if D.unkn = D .unkn= kn, then ID = IS 1 ∪ {car } ∪ IS 2 ∪ {kn} ⊇ ID = IS 1 ∪ {car } ∪ IS 2 ∪ {kn}.Thus, the refinement calculus remains unchanged.

Dynamic alphabetised traces. Let
dtr denote the trace associated with acquired mobile channels, i.e., those in mChans.The value of mChans at a given time defines which events may be recorded at that time; at different times, mChans may have different values: dtr must reflect such changes.We thus introduce the notion of dynamic alphabetised trace.