handover4

8/7/2019 handover4

1/27

GSM System - Handover

Cristovao Oliveira

Computer Science Department

Faculty of Science and Technology

New University of Lisbon

Quinta da Torre, 2829-516 Caparica

November 11, 2003

Abstract

This is a first outline of the case study Handover according to AGILEs workplan. It attempts to model the speci-

fication of the core of the handover protocol for the GSM system for mobile systems in Mobile CommUnity. Mobile

CommUnity, described in [3] is an extension of CommUnity in order to support location-dependent patterns of comput-

ing, namely distributed and mobile components.

1 IntroductionIn a mobile communication network some nodes change locations, and are therefore connected to different other

nodes at different points at time. We show how some important aspects of such a network can be implemented using

Mobile CommUnity. As an example of a mobile network we consider the PLMN - Public Land Mobile Network and

concentrate our case-study on the handover procedure which controls the dynamic topology of the network. The PLMN

implements GSM network that is a living and evolving wireless communications standard.

The case-study covers some basic nodes of the GSM network. Some nodes are left out to simplify the case-study.

The first basic node is the Mobile Station (MS), made up of the SIM and theMobile Equipmen. The SIM, Subscriber

Identity Modul, is a separate physical entity that contains all information regarding the subscription. The SIM is an

IC-card or a Smart Card. The Mobile Equipment is the actual piece of hardware enabling radio communication

with the system. All calls for the SIM are routed to that Mobile Equipment. Another important basic node of the

system is the Base Station System composed by some Base Transceiver Stations (BTS) and a Base Station Controller

(BSC). The BTS is the radio equipment, the main task of which is communication on radio with the MSs. One BTScovers a cell with transmitted radio waves. The BTS contains all the radio equipment necessary to stay in touch with the

MS. The BSC controls and supervises the underlying BTSs. The BTS takes care of the actual radio communication.

The BSC tells the BTSs what to do, when to transmit, what power to use, etc.

Finally the last basic node is the Switching System. The principal entity of the Switching System is the Mobile

Services Switching Centre (MSC) and we only represent it in our system to avoid some details that are not important

for our case-study. This entity sets up, supervises and releases calls. It can connect calls within the GSM/DCS network,

This research was supported by Fundacao para a Ciencia e Tecnologia M.C.E.S through the PhD Scholarship SFRH/BD/6241/2001 of Cristovao

Oliveira and through project POSI/32717/00 (FAST-Formal Approaches to Software Architecture), and by the European Commission through project

AGILE (Architectures for Mobility), ref. IST-2001-32747 Global Computing Initiative.

1

8/7/2019 handover4

2/27

or between a mobile subscriber and a subscriber in the PSTN (Public Switched Telephone Network) or in some other

network. A MSC controls some BSCs and each BSC is responsible for some BTSs.In Section 2 we introduce the reader to the context of the handover procedure, then, in Section 3, we explain the

assumptions in our implementation of the case-study. In Section 4 we present the handover case-study in Mobile Com-

mUnity divided through three different approaches. In the first approach, explained in Section 4.1, we have implemented

the handover process inside the components without care about locations. For the second approach, in Section 4.2, we

use locations and the relation in touch. And finally, the third approach is implemented in Section 4.3, using runtime

reconfiguration.

2 The Handover Procedure

The handover procedure is used when there is a need for a cell change during a call, i.e, the MS is busy. As described in

[1], the purpose of the handover procedure is to move data and control channels from the BSC currently communicating

with the MS to another BSC in another cell. The network controls the handover and decides when it is needed. Thisprocedure is needed to ensure the continuous operation of a data channel allocated to a MS during a call moving across

a cell boundary; without such a handover the communication in the data channels could be terminated because of the

limited range of the BTS. The MS will assist in the handover decision making by providing measurements about the

radio environment that it experiences.

Three types of handover can be distinguished depending on the network structure [2]: Intra-BSC Handover, Inter-

BSC Handover, and Inter-MSC Handover. We focus our case-study in the Inter-BSC Handover. The procedure is

described in Figure 1. The network (MSC - Mobile Service Switching Center) receives a handover request from the

old BSC (step 1.a) and forwards it to the new BSC (step 1.a). The new BSC initiates the handover by transmitting a

handover commandmessage to the MS via the old BSC (step 2) and before it advices the new BTS that it will receives a

new MS (step 1.b). The handover commandmessage contains parameters enabling the MS to locate the radio channels

of the new BSC. When transmitting this message the old BSC suspends transmission of all messages except for the

Radio Resource Management sub-layer messages. Upon receipt of a handover command message the MS disconnectsthe old radio channels and initiates the establishment of lower layer connections in the new radio channels. In order to

establish these connections the MS sends handover bursts messages to the new BSC (step 3). The purpose of the burst

messages is to synchronize the MS with the new BSC. When the lower layer connections are successfully established,

the MS sends a handover complete message for the network via the new BSC (step 4). When the handover complete

message has been received the network resumes normal operations and releases the old radio channels in the old BSC

(step 5).

3 Assumptions on the Implementation of the Case-Study

When the MS is considered busy, (during a call or call set-up), the decision about which cell is the best for the

dedicated connection is done by the BSS (BTS - Base Transceiver Station + BSC - Base Station Controller). The

procedure for the system to figure out which cell is the most suitable, and evaluate the measurements, is called handoverpreparation. We have implemented like the real system the BSC to be responsible for the evaluation of the measurements

reports. To be able to make the right handover decision, the BSC needs measurements about the connection to the

serving cell (BTS) as well as to the possible handover candidates, (i.e. the neighboring cells).

For the three approaches described next we assume a small system with only one MS, two BTSs, two BSCs and

one MSC. Each BSC controls a BTS. The MS never sets up calls, is always communicating with a BSC through the

associated BTS. In the first approach the decision for initiating the handover process is made in a random way. For

simulating the receipt of measurements with information about MSs location. For the second and the third approach

we implement the sending and receipt of the measurements between the MS and the BSC, and the mobility of the MS.

The MCSs were not essential but we implemented them for better insertion of the case-study in the real system. In the

communication process it receives messages from the MS, and generates new messages. In a real system it receives

2

8/7/2019 handover4

3/27

Figure 1: Handover procedure

messages from a MS and sends them to the network, and it receives messages from the network to a MS registered in

a local BSC. The BTSs are connectors and they have an associated location in the second and third approaches. The

locations are be in touch with the locations of the BSCs respectively, but they may not be in touch with the locationof the MS.

There are three types of handover. We decided to only implement the Inter-BSC handover type. This one includes

all the existent steps of a complete handover procedure although it involves only one MSC.

4 Handover Case-Study in Mobile CommUnity

4.1 Hard-wired computations without locations

The first approach has the handover procedure inside of the nodes of the architecture and each node has an active role

in the process. In Section 4.1.2 we describe the whole architecture and how the computations proceed together to execute

the handover procedure. The locations dont play an important role in this approach. To simplify the component types

we dont use location variables. This solution has the computation of the communication and of the handover procedureinside of the components. The communication is blocked in the beginning of the process by the old BSC and the new

BSC continues with the communication at the end of the process, after the MS sent the burst message to it. The used

example is very simple, the MS is communicating with the network (MSC) through a BTS and a BSC, randomly the

BSC decides to initiate an handover procedure and send a request message to the other BSC. On a realistic system the

communication between BSCs is trough the network (MSC), but to simplify we synchronize directly the actions of the

BSCs.

To simulate the initiation of the handover process we use an action - sendHReq in the BSC component. The

execution of the previous action is controlled by another component that implements the initiation of the handover -

BeginHandover. The use of this component externalizes the decision making for the initiation of the handover from

the current computational concern.

3

8/7/2019 handover4

4/27

4.1.1 Component Types

For the implementation of the first approach we use four types of components. They are the MS, BSC, BeginHandover

and MSC. The first represents a MS, is prepared with input and output channels, and actions for the communication

with a BSC. For the handover procedure this component is equipped with actions, that will be synchronized with others

actions of the BSCs. The BSC guarantees the passage of the communication for the MSC and is responsible for initiating

the handover procedure. The BeginHandover implements the way of the initiation of the handover process. The MSC

is very simple and only simulates the communication with the MS. The BTS entities are represented by the simple

connections and synchronizations between the MS and the BSCs.

/* Mobile Station */

design ms

in inMsg1, inMsg2 : MSG

out outMsg1, outMsg2 : MSG

prv sc : bool;state : enum(idle, command, burst)

do send1 : sc -> outMsg1 := random(MSG) || sc := false

[] receive1 : sc -> sc := true

[] send2 : sc -> outMsg2 := random(MSG) || sc := false

[] receive2 : sc -> sc := true

[] hCommand1 : state=idle -> state := command

[] hCommand2 : state=idle -> state := command

[] hBurst1 : state=command -> state := burst

[] hBurst2 : state=command -> state := burst

[] hComplete1 : state=burst -> state := idle

[] hComplete2 : state=burst -> state := idle

/* Base Station Controller */

design bsc

in inMsg, outMsg : MSG

prv state : enum(idle, req, command);

block, initHand, newMS, communication : bool

do transferIn : block -> skip

[] transferOut : block -> skip

[] sendHReq : true, state=idle & communication ->

block := true || state := req || initHand := true

[] receiveHReq : state=idle & communication ->

block := true || state := req || newMS := true

[] hCommand : state=req & initHand -> state := command

[] hBurst : state=req & newMS ->block := false || state := idle ||

newMS := false || communication := true

[] hComplete : state=command & initHand ->

block := false || state := idle ||

initHand := false || communication := false

/* The handover initiation */

design beginHandover

do begin : false, true -> skip

4

8/7/2019 handover4

5/27

/* Mobile Service Switching Center */

design mscin inMsg1, inMsg2 : MSG

out outMsg1, outMsg2 : MSG

do send1 : outMsg1 := random(MSG)

[] receive1 : skip

[] send2 : outMsg2 := random(MSG)

[] receive2 : skip

4.1.2 Configuration

We use connections of channels and synchronization of actions between the nodes of the architecture to implement

the communication process and the handover process. The MS communicates with two BSCs and each BSC commu-

nicates with the MSC. The architecture of the system describes the component types, the instances, the connections

and the synchronizations between the instances. In Figure 2 we show the implemented architecture in the CommUnity

Workbench [5].

In this first approach the control of the locking of the communication for handover process and the control of the

process itself belong to the components of the architecture (Communication and hard-wired handover), they are not

explicit on the configuration.

The locations were omitted because they dont play a relevant role. In detail the process of the communication

is very simple and takes place like the following. The MS communicates with one BSC because it have its actions

synchronized with the actions of the BSC. We are talking about the actions of sending and receiving messages. The MS

receives the messages with the input channel connected with the output channel of the BSC. In this way the MS can

communicate with both BSCs in different moments because it uses one input channel for each BSC. To guarantee the

communication between the MS and only one BSC at a time, there is a private channel ( communication : bool) in the

BSCs used in the guards of the actions used for the communication. We guarantee that the system is initialized with

only one of these private channels to true. This channel is also used in the guard of the action that is responsible toinitiate the handover process in the current BSC that is considered the old BSC for the remaining of the explanation.

The handover process initiates when it executes the action sendHReq synchronized with the action receiveHReq of

the other BSC that is considered the new BSC. The action sendHReq blocks the communication immediately ( block

:= true). When the communication is blocked the old BSC advices the MS that the handover procedure began. The

execution of the action hcommand of the MS synchronized with the same action of the BSC makes the advice. Then

the MS is ready to contact the new BSC. The contact is made with the execution of the action hBurst synchronized

with the same action of the BSC. In the new BSC the action unblocks the communication because the private channel

communication becomes true again. Finally the MS still executes the action hComplete synchronized with the old

BSC to end the handover procedure. At the end of the process the state of the system remains the same like before, but

with a change of roles between the BSCs. More later the handover procedure will be again initiated by the new BSC

that will becomes the old one.

In Figure 3 we show an example of the execution of the system in the CommUnity Workbench. The steps 7-9,

14, 18-21 and 23 are actions for the communication. The steps 10 and 15 are actions to initiate the handover process.

An handover procedure begins with a request from the old BSC to the new BSC. Meanwhile after the activation of

the handover procedure the old BSC advices the MS that an handover began (Steps 11 and 16). Then the MS sends

a burst message to the new BSC (Steps 12 and 17). Finally, the steps 13 and 22 are the last actions of the handover

process (Handover Complete). In the example, after the first handover process, the communication starts again before

the completion of the process. This may happen because the communication continues with the new BSC and the

complete message is related to the old BSC.

5

8/7/2019 handover4

6/27

Figure 2: Configuration as depicted in the CommUnity Workbench

Description of the architecture

Architecture GSM_System_1 {

components

design ms { source-code: "ms.cwp" }

design bsc { source-code: "bsc.cwp" }

design beginHandover { source-code: "beginHandover.cwp"}

design msc { source-code: "msc.cwp" }

configuration

ims : ms

ibsc : array (2, bsc)

ibh : array (2, beginHandover)

imsc : msc

attachments {

ims.inMsg1 - ibsc[1].outMsg

ims.outMsg1 - ibsc[1].inMsg

ims.send1 - ibsc[1].transferOut

ims.receive1 - ibsc[1].transferIn

ims.hCommand1 - ibsc[1].hCommand

ims.hBurst1 - ibsc[1].hBurst

ims.hComplete1 - ibsc[1].hComplete

ims.inMsg2 - ibsc[2].outMsg

ims.outMsg2 - ibsc[2].inMsg

ims.send2 - ibsc[2].transferOut

ims.receive2 - ibsc[2].transferIn

ims.hCommand2 - ibsc[2].hCommand

ims.hBurst2 - ibsc[2].hBurst

ims.hComplete2 - ibsc[2].hComplete

ibsc[1].sendHReq - ibsc[2].receiveHReq

ibsc[1].receiveHReq - ibsc[2].sendHReq

6

8/7/2019 handover4

7/27

Figure 3: An example of the execution of the system

ibsc[1].sendHReq - ibh[1].begin

ibsc[2].sendHReq - ibh[2].begin

ibsc[1].inMsg - imsc.inMsg1

ibsc[1].outMsg - imsc.outMsg1

ibsc[1].transferin - imsc.send1

ibsc[1].transferOut - imsc.receive1

ibsc[2].inMsg - imsc.inMsg2

ibsc[2].outMsg - imsc.outMsg2ibsc[2].transferIn - imsc.send2

ibsc[2].transferOut - imsc.receive2

}

}

7

8/7/2019 handover4

8/27

4.2 Relations bt/Reach

In this approach the locations have a very important role and they are used for the initiation of the handover process

that is not random anymore. The MS moves around and controls its movement itself. The MS is physically connected

with the two BSC using two connector entities - the BTSs. The locations of the BSCs are in touch with the locations

of the BTSs, but the location of the MS may not be in touch with both BTSs. Each known entity has a second

layer represented with new components to implement the measurements. When the MS is in touch with both BTSs

and only when this happens it receives measurements of nearness from the BTSs. Each BTS is represented by two

connector types. The first connector type is binary, supports the communication between the MS and the BSC, and has

a separation of concerns like all the component entities. In the implementation we have two physical binary connector

types to represent a BTS. The separation of concerns in each component or connector is based on the computational

behavior like the first approach and the implementation of the measurements treatment in a second layer. The second

connector type is unary and calculates the measurements, sending them to the MS at the end. Then the MS sends the

measurements to the BSC through the current BTS that is supporting the communication. The BSC verifies if its BTS

is the nearest and if it is not, the handover process is initiated.


Like the first approach we have the same component types but the beginHandover component. The difference

resides in the new components of the second layer to implement the measurements. The MS measure component re-

ceives the measurements from the unary BTS Measure connectors and sends them to the BSC Measure component

through the current binary BTSMeasure connector that supports the current measurements transfer.

Same components of the first approach with location variables:


design MS

outloc lmsin inMsg1, inMsg2 : MSG

out outMsg1@lms, outMsg2@lms : MSG

prv sc@lms : bool

do send1@lms : sc -> outMsg1 := new(MSG) || sc := false

[] receive1@lms : sc -> sc := true

[] send2@lms : sc -> outMsg2 := new(MSG) || sc := false


[] prv move@lms : lms := random(Loc) /* The MS moves around */


design BSC

outloc lbscin inMsg, outMsg : MSG;

communication, block : bool;

newId : int

prv id@lbsc : int

do transferIn@lbsc : communication & block -> skip

[] transferOut@lbsc : communication & block -> skip

[] handoverReq@lbsc :

communication & (newId /= id) -> skip

8

8/7/2019 handover4

9/27


design MSCoutloc lmsc

in inMsg : MSG

out outMsg@lmsc : MSG

do send1@lmsc : outMsg := random(MSG)

[] receive1@lmsc : skip

[] send2@lmsc : outMsg := random(MSG)


New components to implement the second layer:

/* Measure Mobile Station */

design ms_measureinloc lm

in dist1, dist2 : int

out dist1dist2@lm : record(m1 : int; m2 : int)

prv ready1@lm, ready2@lm : bool;

counter1@lm, counter2@lm : int;

ready@lm : bool

do sendbsc1@lm : ready1 & ready2 -> ready1 := false ||

ready2 := false || counter1 := 0 || counter2 := 0

[] sendbsc2@lm : ready1 & ready2 -> ready1 := false ||


[] receive_d1@lm : dist1dist2.m1 := dist1 ||

ready1 := true || counter1 := counter1 + 1



[] clean@lm : ((counter1 >= 2) & (counter2 = 0)) |

((counter1 = 0) & (counter2 >= 2)) ->

counter1 := 0 || counter2 := 0 || ready1 := false || ready2 := false

/* Measure Base Station Controller */

design BSC_Measure

inloc lbsc

in communication : bool;

dist1dist2 : record (m1 : int; m2 : int)

out newId@lbsc : int

do receive_dist1dist2@lbsc : communication ->newId := if (dist1dist2.m1 < dist1dist2.m2, 1, 2)

4.2.2 Connector types

We use four types of connectors. The first, already mentioned, simulates a BTS and is applied two times between

the MS component and the two BSC components. It implements the communication between the MS and the respec-

tive BSC. The second implements the second layer of the previous connector to transfer the measurements from the

MS Measure component to the BSC Measure component. The third connector also represents a BTS, but it implements

the calculation of the measurements and sends them to the MS. The fourth externalizes the handover process between

the two BSCs.

9

8/7/2019 handover4

10/27

/* Communication between nodes of the architecture */

design BTSoutloc lbts

in inMsg, outMsg : MSG

do transferIn@lbts : skip

[] transferOut@lbts : skip

/* Measurements tranfer between nodes of the architecture */

design BTS_Measure

inloc lbts

in dists : record (m1 : int; m2 : int)

do transferMeasure@lbts : skip

/* Measurements treatment */

design BTSMeasure

inloc lms

outloc lbts

out dist@lbts : int

do send_d@lbts : dist := DIST(lms, lbts)

/* Handover Protocol */

design handover

outloc lmsc

out hand@lmsc, communicationBSC1@lmsc, communicationBSC2@lmsc : bool

do handoverReqBSC1@lmsc : hand & communicationBSC1 -> hand := true

[] handoverReqBSC2@lmsc : hand & communicationBSC2 -> hand := true

[] handoverCommand@lmsc : hand -> hand := false ||communicationBSC2 := communicationBSC1 ||

communicationBSC1 := communicationBSC2

4.2.3 Configuration

The MS moves around and the MS Measure component constantly receives measurements from the BTSMeasure

connectors that are in touch. When the MS Measure is in touch with the two unary BTSMeasure connectors it re-

ceives measurements from both and sends them to the current BSC Measure through the current BTSMeasure connector.

The BSC Measure receives the measurements and verifies if the nearest BTS belongs to it. In this moment if the nearest

BTS is not the same the handover process can be initiated because the MS is in touch with both BTS connectors. The

remaining of the handover procedure is similar of the first approach. The current BSC blocks the communication before

the process begins. At the end of the process the communication is unblocked by the new BSC and the actions to hold

the communication belong to the new BSC for now. This control is guaranteed by the guards of the involved actions.

In the same time when the MS leaves the zone be in touch with the two BTSs, it cannot communicate with the old

BTS/BSC anymore. While the MS isnt in touch with the other BTS, thats not the current one, the handover process

cannot be never initiated.

In Figure 4 we show the implemented architecture in the CommUnity Workbench for this approach.

10

8/7/2019 handover4

11/27

Figure 4: The second approach in the CommUnity Workbench

To show as an example of locations we use a bidimensional space. Only two neighboring locations are in touch

and reachable. The function DIST(l1, l2) returns the distance between the locations l1 and l2, and its implementation

can be similar to:

function DIST(l1 : loc, l2 : loc) : int {

l, c : int;

l := l2.l - l1.l;

c := l2.c - l2.c;if l < 0 then l := -1*l

if c < 0 then c := -1*c

if l < c return c;

return l;

}

Description of the architecture:


location

loc = record(i : int; j : int)

bt(x, y) = ((x.i - y.i) = -1)& ((x.j - y.j) = -1)

reach(x, y) = true

components

design MS {source-code: "MS.cwp"}

design MS_Measure {source-code: "MS_Measure.cwp"}

design BSC {source-code: "BSC.cwp"}

design BSC_Measure {source-code: "BSC_Measure.cwp"}

design MSC {source-code: "MSC.cwp"}

connectors

connector BTSMeasurements {

11

8/7/2019 handover4

12/27

8/7/2019 handover4

13/27

configuration

btsg : BTSmsr : msrole

bscr : bscrole

attachments {

btsg.outMsg - msr.inMsg

btsg.inMsg - msr.outMsg

btsg.transferIn - msr.receive

btsg.transferOut - msr.send

btsg.outMsg - bscr.outMsg

btsg.inMsg - bscr.inMsg

btsg.transferOut - bscr.transferOut

btsg.transferIn - bscr.transferIn

}

}

connector handover {

glue design handover { source-code: "handover.cwp" }

roles

design bschrole

in communication, block : bool

do handoverReq : skip

configuration

hand : handover

bschr : array (2, bschrole)

attachments {

hand.hand - bschr[1].blockhand.communicationBSC1 - bschr[1].communication

hand.handReqBSC1 - bschr[1].handoverReq

hand.hand - bschr[2].block

hand.communicationBSC2 - bschr[2].communication

hand.handReqBSC2 - bschr[2].handoverReq

}

}

configuration

ms : MS

ms_meas : MS_Measure

bsc : array(2, BSC)

bsc_meas : array(2, BSC_Measure)

msc : MSC

mbts : array(2, BTSMeasurements)

comm : array(2, BTSConnector)

cmeas : array(2, BTSMeasureConnector)

hand : handover

attachments {

ms.lms - ms_meas.lm

bsc[1].inMsg - msc.inMSg

bsc[1].outMsg - msc.outMsg

13

8/7/2019 handover4

14/27

bsc[1].transferIn - msc.send1

bsc[1].transferOut - msc.receive1

bsc[1].lbsc - bsc_meas[1].lbsc

bsc[1].communication - bsc_meas[1].communication

bsc[1].newId - bsc_meas[1].newId





bsc[2].lbsc - bsc_meas[2].lbsc



}

refinement mbts[1].msr to ms_meas {

l to lms

dist to dist1

receive_d to receive_d1

}

refinement comm[1].msr to ms {

inMsg to inMsg1

outMsg to outMsg1

send to send1

receive to receive1

}refinement comm[1].bscr to bsc[1] {

outMsg to outMsg

inMsg to inMsg

transferIn to transferIn

transferOut to transferOut

}

refinement cmeas[1].msr to ms_meas {

dists to dist1dist2

send_ds to sendBSC1

}

refinement cmeas[1].bscr to bsc_meas[1] {

dists to dist1dist2

receive_ds to receive_dist1dist2

}


l to lms

dist to dist2


}

refinement comm[2].msr to ms {

inMsg to inMsg2

14

8/7/2019 handover4

15/27

outMsg to outMsg2

send to send2receive to receive2

}

refinement comm[2].bscr to bsc[2] {

outMsg to outMsg

inMsg to inMsg



}

refinement cmeas[2].msr to ms_meas {

dists to dist1dist2

send_ds to sendBSC2

}

refinement cmeas[2].bscr to bsc_meas[2] {

dists to dist1dist2


}

refinement hand.bschr[1] to bsc[1] {

communication to communication

block to block

handoverReq to handoverReq

}

refinement hand.bschr[2] to bsc[2] {


block to block

handoverReq to handoverReq}

}

4.3 Reconfiguration at runtime

For the implementation of the reconfiguration we use the syntax explained in [4]. The implementation of the third

approach is initially based on the second approach. The most relevant difference is the existence of only one BTS

connector used between the MS and the current BSC for communication and one BTS Measure connector for mea-

surements transfer. We use runtime reconfiguration to implement the handover procedure. The handover connector

disappeared and was substituted by the reconfiguration algorithm. The Figure 5 shows the architecture in the CommU-

nity Workbench to simulate the third approach.

The coordination between computation and reconfiguration is achieved by a reconfiguration interpreter that con-

stantly executes the following loop:

1- Execute one computation step on the runtime configuration.

2- Execute the script called main.

3- Go to step 1.


There are few differences between these Component types and the component types used in the last approach. So we

must implement them again. The MS only uses one input channel, one output channel and two actions to communicate

instead of two input channels, two output channels and four actions, because it is only synchronized with one connector

15

8/7/2019 handover4

16/27

BTS at a time for communicate. It only has one action to send the measurements for the same reason. The BSC is very

similar to the last approach. In the second approach the communication is blocked by the handover connector. In thisapproach the BSC blocks the communication when it sends the request to the other BSC.

Same components of the second approach with some differences:


design MS

outloc lms

in inMsg1 : MSG

out outMsg1@lms : MSG

prv sc@lms : bool

do send1@lms : sc -> outMsg1 := new(MSG) || sc := false


[] prv move@lms : lms := random(Loc) /* The MS moves around */


design BSC

outloc lbsc

in inMsg, outMsg : MESSAGE;

communication : bool;

newId@lbsc : int

out block : bool

prv id@lbsc : int;

do transferIn@lbsc : communication & block -> skip

[] transferOut@lbsc : communication & block -> skip

[] handoverReq@lbsc :communication & (newId /= id) -> block := true

[] handoverComplete@lbsc : communication & block -> block := false

/* Measure Mobile Station */

design MS_measure

inloc lm

in dist1, dist2 : int

out dist1dist2@lm : record(m1 : int; m2 : int)

prv ready1@lm, ready2@lm : bool;

counter1@lm, counter2@lm : int;

ready@lm : bool

do sendbsc1@lm : ready1 & ready2 -> ready1 := false ||


[] sendbsc2@lm : ready1 & ready2 -> ready1 := false ||






[] clean@lm : ((counter1 >= 2) & (counter2 = 0)) |

((counter1 = 0) & (counter2 >= 2)) ->

counter1 := 0 || counter2 := 0 || ready1 := false || ready2 := false

16

8/7/2019 handover4

17/27

/* Measure Base Station Controller */

design BSC_Measureinloc lbsc

in communication : bool;

dist1dist2 : r ecord ( m1 : i nt; m 2 : int)

out newId@lbsc : int;

do receive_dist1dist2@lbsc : communication ->

newId := if (dist1dist2.m1 < dist1dist2.m2, 1, 2)


design MSC

outloc lmsc

in inMsg : MSG

out outMsg@lmsc : MSG

do send1@lmsc : outMsg := random(MSG)


[] send2@lmsc : outMsg := random(MSG)


4.3.2 Connector types

In this approach we use four connector types. The first is the same connector type BTSconnector used in the last

approach. But now we only apply one in the system. The second is the same connector type BTSConnectorMeasure-

ments used in the last approach too. The third is the same connector type BTSMeasurements we used to calculate

the measurements and send them to the MS. We loose the handover connector type, because the handover process takes

place at runtime reconfiguration.

In the reconfiguration the idle BSC must be detected to complete the handover process. The fourth connector typeappear to invalidate the communication in the BSC that is not used by the MS. This connector has an invariant in its

glue to impose the value false to the output channel communication. The output channel is connected with the input

channels communication of the roles. The idle BSC will refine one of the role and the idle BSC Measure will refine the

other role.

\textbf{\\New connector:}

/* An unary connector to invalidate the communication */

connector endCommunication {

glue

design glueEnd

out communication : boolinv communication = false

roles

design roleEnd

in communication : bool

configuration

gend : glueEnd

rend1, rend2 : roleEnd

attachments {

gend.communication - rend1.communication

gend.communication - rend2.communication

17

8/7/2019 handover4

18/27

}

}

4.3.3 Configuration

Description of the architecture

The architecture of the third approach extends the last architecture with reconfiguration. The script main verifies the

state of the BSC component that holds the communication. If the communication is blocked then the handover is exe-

cuted. The reconfiguration removes the BTS connector, the BTS measurements connector and the EndCommunication

connector and adds the new BTS connector, the new BTS measurements connector and the new EndCommunication

connector.


location

loc = record(i : int; j : int)

bt(x, y) = ((x.j - y.j) = -1)

((x.i - y.i) = -1)

reach(x, y) = true

components

design MS {source-code: "MS.cwp"}

design MS_Measure {source-code: "MS_Measure.cwp"}

design BSC {source-code: "BSC.cwp"}

design BSC_Measure {source-code: "BSC_Measure.cwp"}

design MSC {source-code: "MSC.cwp"}connectors

connector BTSConnector { source-code: "BTSConnector.cwc" }

connector BTSMeasureConnector { source-code: "BTSMeasureConnector.cwc" }

connector BTSMeasurements { source-code: "BTSMeasurements.cwc" }

connector endCommunication { source-code: "endCommunication.cwc" }

configuration

ms : MS

ms_meas : MS_Measure

bsc : array(2, BSC)

bsc_meas: array(2, BSC_Measure)

msc : MSC

comm : BTSConnector

cmeas : BTSMeasureConnectormbts : array(2, BTSMeasurements)

endcomm : endCommunication

attachments {

ms.lms - ms_meas.lm





18

8/7/2019 handover4

19/27

bsc[1].lbsc - bsc_meas[1].lm

bsc[1].communication - bsc_meas[1].communicationbsc[1].newId - bsc_meas[1].newId





bsc[2].lbsc - bsc_meas[2].lm



}


l to lms

dist to dist1


}


l to lms

dist to dist2


}

refinement comm.msr to ms {

inMsg to inMsg1

outMsg to outMsg1

send to send1receive to receive1

}

refinement comm.bscr to bsc[1] {

outMsg to outMsg

inMsg to inMsg




}

refinement cmeas.msr to ms_meas {

dists to dist1dist2

send_ds to sendBSC1

}

refinement cmeas.bscr to bsc_meas[1] {

dists to dist1dist2


}

refinement endcomm.rend1 to bsc[2] {


}

refinement endcomm.rend2 to bsc_measure[2] {


19

8/7/2019 handover4

20/27

}

reconfigurationscript main

prv b scms : r ecord ( bsc : BSC; m s : MS; b ts : BTSConnector)

bscmsmeas : record (bsc : BSC_Measure;

ms : MS_Measure;

bts : BTSMeasureConnector)

bscend : record (bsc : BSC; bsc_m : BSC_Measure; ecomm : endCommunication)

l : list (record (bsc : BSC; ms : MS; bts : BTSConnector))

l := match{ms : MS; bsc : BSC; bts : BTSConnector |

bts(ms, bsc) with bsc.block = true}

if (l /= nil)

then

bscms := head (l)

bscmsmeas := head(match{ms : MS_Measure; bsc : BSC_Measure;

bts : BTSMeasureConnector | bts(ms, bsc)})

bscend := head(match{bsc : BSC; bsc_m : BSC_Measure; ecomm : EndCommunication |

ecomm(bsc, bsc_m)})

remove bscms.bts

remove bscmsmeas.bts

remove bscend.ecomm

apply endCommunication {

refinement rend1 to bscms.bsc {


}

refinement rend2 to bscmsmeas.bsc {communication to communication

}

}

apply BTSConnector {

refinement msr to bscms.ms {

inMsg to inMsg1

outMsg to outMsg1

send to send1

receive to receive1

}

refinement bscr to bscend.bsc {

outMsg to outMsg

inMsg to inMsg




}

}

apply BTSMeasureConnector {

refinement msr to bscmsmeas.ms {

dists to dist1dist2

send_ds to sendBSC1

20

8/7/2019 handover4

21/27

}

refinement bscr to bscend.bsc_m {dists to dist1dist2


}

}

end if

end script

}

Figure 5: Reconfiguration Architecture

5 Conclusion

In this case-study we presented the Handover protocol of a GSM system. The Handover is always executed among

two neighboring cells that belong to two assumed BTS. Our objective is to model the specification of the protocol using

three specification languages, in order to take advantage of the benefits of each one of them, and to try to surpass the

barriers when using one alone languages.

The first language is Mobile CommUnity. The second is a reconfiguration language used in the development of the

third approach, and in this way to add to the Mobile CommUnity syntax for reconfiguration. The last language is the

textual language of description of architectures described in the appendix 7 which was developed to be applied in the

CommUnity Workbench and it also has the new reconfiguration syntax with origin in the second language previously

referenced.We developed the case-study using three approaches that are not independent. Each approach completes the previ-

ous trying to eliminate the disadvantages obtained in the development of the previous one. Briefly the first approach

implements the system using pure CommUnity. The second approach is based on the first joining the notion of location

and detection of the established handover from the information obtained on the knowledge of the locations. Finally the

third approach completes the second adding reconfiguration in runtime for reconfigure the system during handover. All

the architectures presented in the three approaches are specified with the textual language of description of architectures.

However for the second and third approaches this language is enriched with syntax for representation and treatment of

the locations introduced in Mobile CommUnity. For the third approach we still needed to enrich the textual specifica-

tion with syntax to represent the reconfiguration in runtime and we based on the reconfiguration language presented in

ESEC01 paper [4].

21

8/7/2019 handover4

22/27

In the first approach the handover process is well defined, and it is a good introduction for the assumed mini system.

In spite of the handover process to be the closest of the reality among the three approaches, this approach doesntimplement the location notion and the handover begin is not based on the environment, it is random. The mini system is

static and the MS component is very complex. This component has a pair of channels and of actions for communication

for each BTS of the system. The communication between the MS and the BSCs is implemented by connections of

channels and synchronizations of actions. Finally the handover process is inside of the components that it is bad

to possible reconfigurations because it implicates alterations in all the components if we should have to change the

handover process.

The second approach is based on the first introducing locations and it assumes that the system was well explained

in the first approach to stand back of some superfluous details and concentrate itself in the new introduced points. The

locations are introduced to use the existent relationships in Mobile CommUnity over locations. One of the relationships

is the be in touch relation that is used to implement the detection of the possibility of a handover. The locations are

implemented in Mobile CommUnity by location variables in the components. So the evolution of the first approach for

the second is mainly centered in the insertion of location variables in the existent components. Based on the locations,

the calculation of measurements and the respective sending for the BSC like the real GSM system become possible.

For the calculation of the measurements it became indispensable to also represent BTS like located connectors. The

links used between the MS and BSCs were substituted by two connectors each. One of them is a binary connector to do

the communication and measure transfers between the MS and the BSC. The other is an unary connector to calculate

the measurements and to send them for the MS. The relationship be in touch is used in an implicit way, because the

sending of measures of the BTSs for the MS is only possible when the involved entities are in touch making possible

the execution of synchronized actions of sending / receipt. Unfortunately the system continues static being necessary a

connector for BTS always present and the MS component continues with the same complexity for the communication

and measurements treatment. Finally the handover process is externalized for a connector, and the components are

simplified in what it respects to the actions / channels for the implementation of the handover process.

To solve the great disadvantage of the static system and the impossibility of using the same MSs when we add more

BTSs, we began on the second approach and we developed the third approach. We introduced dynamic reconfiguration

to control the handover procedure. The reconfigurator has a global knowledge of the whole system and it analyzes thestate of the components. When doing the analysis he detects if it is necessary a handover. The way as the handover

is begun stays equal of the second approach but the connector handover is substituted by the reconfiguration. The

reconfiguration allows the use of only one binary connector BTS between the MS and the current BSC, and when a

handover is detected this connector is removed and substituted by a new one between the MS and the other BSC. The

two unary connectors BTS sends the measurements to the MS or not if they are in touch or not respectively, as like as

the second approach.

In end summary let compare this case-study with the real system to obtain conclusions between the reached and

pretended results. In the real GSM system the architecture is divided in nodes of the net, they are MSs, BTSs, BSCs

and MSCs. In the case-study we developed a mini-system with a MS, two BTSs, two BSCs, and a MSC; that system

stays equal in the three approaches. In the real system the process handover is implemented in the architecture and each

component has an important role in the process. This architecture is well described in the first approach. In the following

approaches we tried to externalize the process from the components, creating a connector in the second approach and

using reconfiguration in the third. We obtained a simplification of the steps of the original protocol, because many of

the interactions among the components stopped being necessary and the process had been more centralized (Connector

/ Reconfigurator). The detection of the need of a handover is an important point in the architecture of the system GSM,

but to facilitate the study and the implementation of our case-study we divided some important points for the approaches

and we only introduced the treatment of measures from the environment in the second approach. In the first approach we

implemented a random beginning of handover and we concentrated more in the protocol itself. For the same reason the

mobility of the MS and the distribution of the system were omitted in the first approach and they were only contemplated

in the remaining ones.

For future work it remains to develop an ADT with functions about locations to be used by the reconfigurator. We

need to define a distributed Configurator, with the knowledge that should exist in each point of the network. The frag-

22

8/7/2019 handover4

23/27

mentary knowledge of the space should be well studied. The distribution of the knowledge should be well meditated.

To study which possibilities a local reconfigurator agent has to know the locations for besides yours, to know whichcomponents exist in several places, to know how a component can move from l1 to l2. All these subjects should be

answered to develop a distributed reconfiguration because a centralized Configurator with global knowledge and omni-

scient of the whole architecture is impracticable for nets of great dimension. The principal goal must be the development

of a coordination based software architecture with runtime reconfiguration available, for mobile / distributed systems,

applied with the Mobile CommUnity approach.

6 Acknowledgments

I thank the supervision of my supervisor Michel Wermelinger. His opinions and suggestions were very important for

the development of this paper. I thank Antonia Lopes and Jose Fiadeiro for their support and feedback in the case-study.

Without them this work would have been more difficult. I thank my cousin Filipe Goncalves who taught me a lot about

GSM Systems and the handover process.

References

[1] Fredrik Orava and Joachim Parrow. An Algebraic Verification of a Mobile Network. Uppsala University, Depart-

ment of Computer Systems. In Protocol Specification, Testing, and Verification X, pages 275-291, North-Holland

1990

[2] GSM System Overview, rev. no. 100, APIS Technical Training AB 1998. APIS Training & Seminars, Sweden,

[email protected], www.apis.se

[3] A.Lopes, J.L.Fiadeiro and M.Wermelinger. Architecural Primitives for Distribution and Mobility, In Proc. ACM

SIGSOFT Symposium on the Foundations of Software Engineering (FSE 10), pages 41-50, ACM Press, 2002

[4] M. Wermelinger, A.Lopes and J.L.Fiadeiro. A Graph Based Architectural (Re)configuration Language, In Proc.

8th European Software Engineering, Conference/9th Symposium on the Foundations of Software Engineering,

pages 21-32, ACM Press, 2001

[5] M. Wermelinger and C. Oliveira. The CommUnity Workbench. In Proc. of the 24th Intl. Conf. on Software Engi-

neering, page 713. ACM Press, 2002.

23

8/7/2019 handover4

24/27

7 Specification of Architectures in Mobile CommUnity

7.1 Current Specification

Architecture ::= architecture Name {[ components ComponentDecl* ]

[ connectors ConnectorDecl* ]

[ configuration

[ InstancesComp* ] /* Components */

[ InstancesCon* ] /* Connectors */

[ AttachmentsDecl ]

[ RefinementsDecl* ]

]

}

ConnectorDecl ::= connector Name { source-code: ...relative path\connector.cwt }|connector Name {

glue ComponentDecl

roles ComponentDecl*

[ configuration


[ AttachmentsDecl ]

]

}

ComponentDecl ::= design Name{

source-code:...relative path\

design.cwp}|

design Name

[ in ((Name)* : Type;)+ ]

[ out ((Name)* : Type;)+ ]

[ prv ((Name)* : Type;)+ ]

[ do Name : [Expression ->]

Name := Expression (|| Name := Expression)*|skip

([] Name : [Expression ->]

Name := Expression (|| Name := Expression)*|

skip)*

]

InstancesComp ::= InstancesList: ( Name | array ( Number, Name ) )

InstancesCon ::= InstancesList: ( Name | array ( Number, Name ) )

InstancesList::= Name [ at (Number, Number) ] (, Name [ at (Number, Number) ] )*

AttachmentsDecl ::= attachments {

24

8/7/2019 handover4

25/27

NameComp.Var- NameComp.Var

|NameComp.Action - {NameComp.Action (, NameComp.Action)*} )*

}

RefinementsDecl ::= refinement Name.(NameComp) to (NameComp) {(Varto Var)*

(prv Varto Expression )*

(Action to Action)*

}

NameComp ::= Name | Name[X]

Var ::= Name

Action ::= Name

Expression ::= Involves values and the operations of the data types used by CommUnity

Name ::= < LET T E R > (< LET T E R > | < D IGI T > | )

Number ::= (< DI GI T >)+

Type ::= Data types used by CommUnity

7.2 Specification with Future Extensions of the Specification

Architecture ::= architecture Name {[ location LocationDecl ]

[ components ComponentDecl* ]

[ connectors ConnectorDecl* ]

[ configuration


[ InitDecl ]

[ InstancesCon* ] /* Connectors */

[ AttachmentsDecl ]

( RefinementsDecl

| RepetitiveRefinement)*]

[ reconfiguration

[ ScriptDecl* ] /* Scripts */

script main

...Reconfiguration Language...

end script

]

}

LocationDecl ::= loc = Type

bt(x, y) = Function(x, y)

25

8/7/2019 handover4

26/27

reach(x, y) = Function(x, y)

Function(x, y) ::= Boolean expression which Involves values and the operations

of the data types used by CommUnity over the variables x and y

ConnectorDecl ::= connector Name { source-code: ...relative path\connector.cwt }|connector Name {

glue ComponentDecl

roles ComponentDecl*

[ configuration


[ AttachmentsDecl ]

]

}

ComponentDecl ::= design Name { source-code:...relative path\design.cwp }|design Name

[ in ((Name)* : Type;)+ ]

[ out ((Name)* : Type;)+ ]

[ prv ((Name)* : Type;)+ ]

[ do Name : [Expression ->]

Name := Expression (|| Name := Expression)*|skip

([] Name : [Expression ->]Name := Expression (|| Name := Expression)*|skip

)*

]

ScriptDecl ::= script Name { source-code:...relative path\script.cws }|script Name

...Reconfiguration Language...

end script

InstancesComp ::= InstancesList: ( Name | array ( Number, Name ) )

InstancesCon ::= InstancesList: ( Name | array ( Number, Name ) )

InstancesList::= Name [ at (Number, Number) ] (, Name [ at (Number, Number) ] )*

InitDecl ::= with NameComp.Var := Expression

( || NameComp.Var:= Expression )*

AttachmentsDecl ::= attachments {

26

8/7/2019 handover4

27/27

(AttachVarDecl)*

(AttachActionDecl)*( for i = Numberto Number

loop

AttachVarDecl

|AttachActionDecl

end loop

)*

}

AttachVarDecl ::= NameComp.Var- NameComp.Var

AttachActionDecl ::= NameComp.Action - {NameComp.Action (, NameComp.Action)*}

RefinementsDecl ::= refinement Name.(NameComp) to (NameComp) {(RefVarDecl)*

(RefPrvVarDecl)*

(RefActionDecl)*

( for i = Numberto Number

loop

RefVarDecl

|RefPrvVarDecl

|RefActionDecl

end loop)*

}

RefVarDecl ::= Varto Var

RefPrvVarDecl ::= prv Varto Expression

RefActionDecl ::= Action to Action

Var ::= NameComp

Action ::= NameComp

NameComp ::= Name | Name[i]

Expression ::= Involves values and the operations of the data types used by CommUnity

Name ::= < LET T E R > (< LET T E R > | < DI GI T > | )

Number ::= (< DI GI T >)+

Type ::= Data types used by CommUnity

27

handover4

Documents