GSM System - Handover∗

Crist´ v˜ o Oliveira o a 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 AGILE’s workplan. It attempts to model the specification 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 computing, namely distributed and mobile components.

1

Introduction

In 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 the“Mobile 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 MS’s. One BTS covers 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 BTS’s. The BTS takes care of the actual radio communication. The BSC tells the BTS’s 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 Fundac˜ o para a Ciˆ ncia e Tecnologia M.C.E.S through the PhD Scholarship SFRH/BD/6241/2001 of Crist´ v˜ o a e o a 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

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 CommUnity 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. This procedure 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, InterBSC 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 command message 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 command message 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 disconnects the 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 handover preparation. 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 MS’s 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

On a realistic system the communication between BSCs is trough the network (MSC).2 we describe the whole architecture and how the computations proceed together to execute the handover procedure.Figure 1: Handover procedure messages from a MS and sends them to the network. This one includes all the existent steps of a complete handover procedure although it involves only one MSC.“sendHReq” in the BSC component. To simulate the initiation of the handover process we use an action . after the MS sent the burst message to it. 3 . The execution of the previous action is controlled by another component that implements the initiation of the handover “BeginHandover”.1 Handover Case-Study in Mobile CommUnity 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. the MS is communicating with the network (MSC) through a BTS and a BSC.1. The use of this component externalizes the decision making for the initiation of the handover from the current computational concern. randomly the BSC decides to initiate an handover procedure and send a request message to the other BSC. The locations don’t play an important role in this approach. The BTSs are connectors and they have an associated location in the second and third approaches. 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. The used example is very simple. The locations are “be in touch” with the locations of the BSCs respectively. This solution has the computation of the communication and of the handover procedure inside of the components. To simplify the component types we don’t use location variables. but they may not “be in touch” with the location of the MS. but to simplify we synchronize directly the actions of the BSCs. and it receives messages from the network to a MS registered in a local BSC. We decided to only implement the “Inter-BSC” handover type. 4 4. There are three types of handover.

block. true -> skip 4 . The BeginHandover implements the way of the initiation of the handover process. command). /* Mobile Station */ design ms in inMsg1.1. outMsg2 : MSG prv sc : bool. The first represents a MS. newMS. initHand. inMsg2 : MSG out outMsg1. communication : bool do transferIn : ˜block -> skip [] transferOut : ˜block -> skip [] sendHReq : true. BeginHandover and MSC. BSC. is prepared with input and output channels. outMsg : MSG prv state : enum(idle. req. command.4. They are the MS. The BTS entities are represented by the simple connections and synchronizations between the MS and the BSCs. 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.1 Component Types For the implementation of the first approach we use four types of components. 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. The BSC guarantees the passage of the communication for the MSC and is responsible for initiating the handover procedure. 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 MSC is very simple and only simulates the communication with the MS. state : enum(idle.

To guarantee the communication between the MS and only one BSC at a time. In the new BSC the action unblocks the communication because the private channel “communication” becomes true again. More later the handover procedure will be again initiated by the new BSC that will becomes the old one. The architecture of the system describes the component types. 5 . In this way the MS can communicate with both BSCs in different moments because it uses one input channel for each BSC. The steps 10 and 15 are actions to initiate the handover process. 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. The action “sendHReq” blocks the communication immediately (block := true). 18-21 and 23 are actions for the communication. the connections and the synchronizations between the instances. The steps 7-9. after the first handover process. This may happen because the communication continues with the new BSC and the complete message is related to the old BSC. there is a private channel (communication : bool) in the BSCs used in the guards of the actions used for the communication. In Figure 2 we show the implemented architecture in the CommUnity Workbench [5]. The MS receives the messages with the input channel connected with the output channel of the BSC. Meanwhile after the activation of the handover procedure the old BSC advices the MS that an handover began (Steps 11 and 16). Finally. The contact is made with the execution of the action “hBurst” synchronized with the same action of the BSC. The MS communicates with one BSC because it have its actions synchronized with the actions of the BSC. The MS communicates with two BSCs and each BSC communicates with the MSC. Finally the MS still executes the action “hComplete” synchronized with the old BSC to end the handover procedure. Then the MS sends a burst message to the new BSC (Steps 12 and 17). In Figure 3 we show an example of the execution of the system in the CommUnity Workbench. We guarantee that the system is initialized with only one of these private channels to true. the instances. The locations were omitted because they don’t play a relevant role. 14. We are talking about the actions of sending and receiving messages. inMsg2 : MSG out outMsg1.1. 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)./* Mobile Service Switching Center */ design msc in inMsg1. the communication starts again before the completion of the process. In the example. In detail the process of the communication is very simple and takes place like the following. they are not explicit on the configuration. When the communication is blocked the old BSC advices the MS that the handover procedure began. Then the MS is ready to contact the new BSC. the steps 13 and 22 are the last actions of the handover process (Handover Complete). 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.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. An handover procedure begins with a request from the old BSC to the new BSC. The execution of the action “hcommand” of the MS synchronized with the same action of the BSC makes the advice. outMsg2 : MSG do send1 : outMsg1 := random(MSG) [] receive1 : skip [] send2 : outMsg2 := random(MSG) [] receive2 : skip 4. This channel is also used in the guard of the action that is responsible to initiate the handover process in the current BSC that is considered the old BSC for the remaining of the explanation.

inMsg ims.sendHReq 6 .sendHReq .receiveHReq ibsc[1].hBurst1 .inMsg ibsc[2].cwp" } configuration ims : ms ibsc : array (2.ibsc[1]. bsc) ibh : array (2.hComplete ims.outMsg1 .receive2 ims.transferIn ims.cwp" } design bsc { source-code: "bsc.Figure 2: Configuration as depicted in the CommUnity Workbench Description of the architecture Architecture GSM_System_1 { components design ms { source-code: "ms.hCommand1 .receiveHReq .cwp" } design beginHandover { source-code: "beginHandover.transferIn ibsc[2].hBurst ims.ibsc[2].ibsc[2].hCommand ims.hComplete1 .transferOut ims.hComplete ibsc[1].transferOut ibsc[2].ibsc[1].hComplete2 ibsc[2].hBurst ibsc[2].outMsg ims.inMsg1 .hCommand2 ims.ibsc[1].receive1 .ibsc[1].hBurst2 ims.hCommand ibsc[2].send2 ims.ibsc[1].outMsg2 ims.outMsg ibsc[2].ibsc[1].cwp"} design msc { source-code: "msc.send1 .ibsc[1]. beginHandover) imsc : msc attachments { ims.inMsg2 ims.

imsc.inMsg .imsc.inMsg1 ibsc[1].receive1 ibsc[2].transferin .transferIn .outMsg2 ibsc[2].Figure 3: An example of the execution of the system ibsc[1].imsc.ibh[2].outMsg .ibh[1].imsc.transferOut .send2 ibsc[2].imsc.inMsg .transferOut .receive2 } } 7 .imsc.sendHReq ibsc[2].imsc.sendHReq .imsc.outMsg .send1 ibsc[1].outMsg1 ibsc[1].begin .begin ibsc[1].inMsg2 ibsc[2].

communication. 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. newId : int prv id@lbsc : int do transferIn@lbsc : communication & ˜block -> skip [] transferOut@lbsc : communication & ˜block -> skip [] handoverReq@lbsc : communication & (newId /= id) -> skip 8 . and has a separation of concerns like all the component entities. outMsg : MSG. 4. the handover process is initiated. 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 [] receive2@lms : ˜sc -> sc := true [] prv move@lms : lms := random(Loc) /* The MS moves around */ /* Base Station Controller */ design BSC outloc lbsc in inMsg. supports the communication between the MS and the BSC. Then the MS sends the measurements to the BSC through the current BTS that is supporting the communication. The locations of the BSCs are “in touch” with the locations of the BTSs. Each BTS is represented by two connector types. but the location of the MS may not be “in touch” with both BTSs.1 Component Types Like the first approach we have the same component types but the “beginHandover” component. When the MS is “in touch” with both BTSs and only when this happens it receives measurements of nearness from the BTSs.the BTSs.2. sending them to the MS at the end. inMsg2 : MSG out outMsg1@lms. The MS moves around and controls its movement itself. Same components of the first approach with location variables: /* Mobile Station */ design MS outloc lms in inMsg1. The “MS measure” component receives 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. The first connector type is binary. The MS is physically connected with the two BSC using two connector entities . Each known entity has a second layer represented with new components to implement the measurements. The difference resides in the new components of the second layer to implement the measurements. In the implementation we have two physical binary connector types to represent a BTS.4. The BSC verifies if its BTS is the nearest and if it is not. The second connector type is unary and calculates the measurements. block : bool.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.

ready2@lm : bool.2. simulates a BTS and is applied two times between the MS component and the two BSC components. The fourth externalizes the handover process between the two BSCs.2 Connector types We use four types of connectors. ready@lm : bool do sendbsc1@lm : ready1 & ready2 -> ready1 := false || ready2 := false || counter1 := 0 || counter2 := 0 [] sendbsc2@lm : ready1 & ready2 -> ready1 := false || ready2 := false || counter1 := 0 || counter2 := 0 [] receive_d1@lm : dist1dist2. The first. 1.m2 := dist2 || ready2 := true || counter2 := counter2 + 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.m1 < dist1dist2.m1 := dist1 || ready1 := true || counter1 := counter1 + 1 [] receive_d2@lm : dist1dist2. dist2 : int out dist1dist2@lm : record(m1 : int. counter1@lm. but it implements the calculation of the measurements and sends them to the MS. The third connector also represents a BTS. counter2@lm : int. already mentioned. m2 : int) prv ready1@lm. 2) 4. The second implements the second layer of the previous connector to transfer the measurements from the MS Measure component to the BSC Measure component. 9 . m2 : int) out newId@lbsc : int do receive_dist1dist2@lbsc : communication -> newId := if (dist1dist2./* Mobile Service Switching Center */ design MSC outloc lmsc in inMsg : MSG out outMsg@lmsc : MSG do send1@lmsc : outMsg := random(MSG) [] receive1@lmsc : skip [] send2@lmsc : outMsg := random(MSG) [] receive2@lmsc : skip New components to implement the second layer: /* Measure Mobile Station */ design ms_measure inloc lm in dist1. It implements the communication between the MS and the respective BSC.m2.

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. 10 . When the MS Measure is “in touch” with the two unary BTSMeasure connectors it receives measurements from both and sends them to the current BSC Measure through the current BTSMeasure connector. In Figure 4 we show the implemented architecture in the CommUnity Workbench for this approach. that’s not the current one. The BSC Measure receives the measurements and verifies if the nearest BTS belongs to it.2. In the same time when the MS leaves the zone “be in touch” with the two BTSs. communicationBSC1@lmsc. 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. it cannot communicate with the old BTS/BSC anymore. The current BSC blocks the communication before the process begins. While the MS isn’t “in touch” with the other BTS. lbts) /* Handover Protocol */ design handover outloc lmsc out hand@lmsc./* Communication between nodes of the architecture */ design BTS outloc lbts in inMsg. 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.3 Configuration The MS moves around and the MS Measure component constantly receives measurements from the BTSMeasure connectors that are “in touch”. This control is guaranteed by the guards of the involved actions. 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. The remaining of the handover procedure is similar of the first approach. the handover process cannot be never initiated. 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.

l1. c := l2.j . Only two neighboring locations are “in touch” and “reachable”.y. c : int. and its implementation can be similar to: function DIST(l1 : loc.l2.i .l . y) = true components design MS {source-code: "MS.j) <=1 | (x. j : int) bt(x. The function DIST(l1. l2) returns the distance between the locations l1 and l2. y) = ((x. l := l2.i) >= -1) & ((x.cwp"} design MS_Measure {source-code: "MS_Measure.Figure 4: The second approach in the CommUnity Workbench To show as an example of locations we use a bidimensional space.cwp"} design BSC {source-code: "BSC.i .y.j .c. return l.l.j) >= -1) reach(x. } Description of the architecture: Architecture GSM_System_2 { location loc = record(i : int. if l < 0 then l := -1*l if c < 0 then c := -1*c if l < c return c.i) <=1 | (x. l2 : loc) : int { l.cwp"} connectors connector BTSMeasurements { 11 .c .y.y.cwp"} design BSC_Measure {source-code: "BSC_Measure.cwp"} design MSC {source-code: "MSC.

m2 : int) do send_ds : skip design bscrole in dists : record(m1 : int.send_d .bscr.transferMeasure .cwp" } roles design msrole inloc l in dist : int do receive_d : skip configuration btsg : BTSMeasure msr : msrole attachments { btsg.glue design BTSMeasure { source-code: "BTSMeasure.msr.receive_ds } } connector BTSConnector { glue design BTS { source-code: "BTS.dists . outMsg : MSG do transferIn : skip [] transferOut : skip 12 .l btsg.msr.dists . m2 : int) do receive_ds : skip configuration btsg : BTS_Measure msr : msrole bscr : bscrole attachments { btsg.lms .msr.msr.transferMeasure .cwp" } roles design msrole in inMsg : MSG out outMsg : MSG do send : skip [] receive : skip design bscrole in inMsg.dists btsg.send_ds btsg.msr.dists btsg.dist btsg.receive_d } } connector BTSMeasureConnector { glue design BTS_Measure { source-code: "BTS_Measure.dist .bscr.cwp" } roles design msrole out dists : record(m1 : int.

msc.outMsg btsg.hand .bschr[1]. BTSConnector) cmeas : array(2.lms .handReqBSC1 .communicationBSC1 . BTSMeasureConnector) hand : handover attachments { ms.communication hand.transferIn btsg.configuration btsg : BTS msr : msrole bscr : bscrole attachments { btsg.handoverReq } } configuration ms : MS ms_meas : MS_Measure bsc : array(2.cwp" } roles design bschrole in communication.lm bsc[1]. BTSMeasurements) comm : array(2.inMsg btsg. BSC) bsc_meas : array(2.inMsg .transferOut bscr. block : bool do handoverReq : skip configuration hand : handover bschr : array (2.outMsg msr.msc. BSC_Measure) msc : MSC mbts : array(2.outMsg .block hand.transferIn } } connector handover { glue design handover { source-code: "handover.transferOut btsg.inMsg msr.receive msr.bschr[2].bschr[2]. bschrole) attachments { hand.bschr[1].transferOut btsg.outMsg 13 .bschr[2].block hand.communicationBSC2 .outMsg bscr.outMsg btsg.inMsg btsg.communication hand.send bscr.inMsg bscr.bschr[1].inMSg bsc[1].handReqBSC2 .ms_meas.handoverReq hand.transferIn - msr.hand .

transferOut msc.bsc_meas[1].send2 msc.inMsg bsc[2].msr to ms { inMsg to inMsg2 14 .msc.transferIn bsc[1].lbsc .newId .send1 .communication .msr to ms { inMsg to inMsg1 outMsg to outMsg1 send to send1 receive to receive1 } refinement comm[1].msr to ms_meas { dists to dist1dist2 send_ds to sendBSC1 } refinement cmeas[1].receive1 bsc[1].lbsc bsc[2].transferIn bsc[2].bscr to bsc_meas[1] { dists to dist1dist2 receive_ds to receive_dist1dist2 } refinement mbts[2].bsc_meas[2].communication .communication bsc[2].inMSg msc.bsc[1].msr to ms_meas { l to lms dist to dist2 receive_d to receive_d2 } refinement comm[2].lbsc bsc[1].newId .outMsg bsc[2].lbsc .outMsg msc.receive2 bsc[2].bsc_meas[2].communication bsc[1].bsc_meas[1].bsc_meas[2].newId bsc[2].bscr to bsc[1] { outMsg to outMsg inMsg to inMsg transferIn to transferIn transferOut to transferOut } refinement cmeas[1].bsc_meas[1].msc.transferOut .newId } refinement mbts[1].msr to ms_meas { l to lms dist to dist1 receive_d to receive_d1 } refinement comm[1].

The Figure 5 shows the architecture in the CommUnity Workbench to simulate the third approach. We use runtime reconfiguration to implement the handover procedure.bschr[2] to bsc[2] { communication to communication block to block handoverReq to handoverReq } } 4. one output channel and two actions to communicate instead of two input channels. The implementation of the third approach is initially based on the second approach.1 Component Types There are few differences between these Component types and the component types used in the last approach.Execute one computation step on the runtime configuration. The MS only uses one input channel. • 2.bscr to bsc_meas[2] { dists to dist1dist2 receive_ds to receive_dist1dist2 } refinement hand.bschr[1] to bsc[1] { communication to communication block to block handoverReq to handoverReq } refinement hand. So we must implement them again. The handover connector disappeared and was substituted by the reconfiguration algorithm.Go to step 1.msr to ms_meas { dists to dist1dist2 send_ds to sendBSC2 } refinement cmeas[2]. two output channels and four actions. • 3.Execute the script called “main”.bscr to bsc[2] { outMsg to outMsg inMsg to inMsg transferIn to transferIn transferOut to transferOut } refinement cmeas[2].outMsg send receive to outMsg2 to send2 to receive2 } refinement comm[2].3 Reconfiguration at runtime For the implementation of the reconfiguration we use the syntax explained in [4].3. The coordination between computation and reconfiguration is achieved by a reconfiguration interpreter that constantly executes the following loop: • 1. 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 measurements transfer. because it is only synchronized with one connector 15 . 4.

newId@lbsc : int out block : bool prv id@lbsc : int. counter1@lm. dist2 : int out dist1dist2@lm : record(m1 : 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. counter2@lm : int. outMsg : MESSAGE. ready@lm : bool do sendbsc1@lm : ready1 & ready2 -> ready1 := false || ready2 := false || counter1 := 0 || counter2 := 0 [] sendbsc2@lm : ready1 & ready2 -> ready1 := false || ready2 := false || counter1 := 0 || counter2 := 0 [] receive_d1@lm : dist1dist2. Same components of the second approach with some differences: /* Mobile Station design MS outloc lms in inMsg1 out outMsg1@lms prv sc@lms do send1@lms : sc [] receive1@lms : [] prv move@lms : */ : MSG : MSG : bool -> outMsg1 := new(MSG) || sc := false ˜sc -> sc := true lms := random(Loc) /* The MS moves around */ /* Base Station Controller */ design BSC outloc lbsc in inMsg.m1 := dist1 || ready1 := true || counter1 := counter1 + 1 [] receive_d2@lm : dist1dist2.m2 := dist2 || ready2 := true || counter2 := counter2 + 1 [] clean@lm : ((counter1 >= 2) & (counter2 = 0)) | ((counter1 = 0) & (counter2 >= 2)) -> counter1 := 0 || counter2 := 0 || ready1 := false || ready2 := false 16 . ready2@lm : bool. communication : bool.BTS at a time for communicate. In this approach the BSC blocks the communication when it sends the request to the other BSC. It only has one action to send the measurements for the same reason. In the second approach the communication is blocked by the handover connector. m2 : int) prv ready1@lm. The BSC is very similar to the last approach.

1. The idle BSC will refine one of the role and the idle BSC Measure will refine the other role. do receive_dist1dist2@lbsc : communication -> newId := if (dist1dist2.3.communication . We loose the handover connector type. The first is the same connector type “BTSconnector” used in the last approach. But now we only apply one in the system. This connector has an invariant in its glue to impose the value false to the output channel communication. 2) /* Mobile Service Switching Center */ design MSC outloc lmsc in inMsg : MSG out outMsg@lmsc : MSG do send1@lmsc : outMsg := random(MSG) [] receive1@lmsc : skip [] send2@lmsc : outMsg := random(MSG) [] receive2@lmsc : skip 4. \textbf{\\New connector:} /* An unary connector to invalidate the communication */ connector endCommunication { glue design glueEnd out communication : bool inv communication = false roles design roleEnd in communication : bool configuration gend : glueEnd rend1. The output channel is connected with the input channels communication of the roles. The fourth connector type appear to invalidate the communication in the BSC that is not used by the MS.communication gend.m1 < dist1dist2.2 Connector types In this approach we use four connector types. The third is the same connector type “BTSMeasurements” we used to calculate the measurements and send them to the MS. m2 : int) out newId@lbsc : int.rend2.m2. rend2 : roleEnd attachments { gend./* Measure Base Station Controller */ design BSC_Measure inloc lbsc in communication : bool.communication .rend1. The second is the same connector type “BTSConnectorMeasurements” used in the last approach too.communication 17 . dist1dist2 : record (m1 : int. because the handover process takes place at runtime reconfiguration. In the reconfiguration the idle BSC must be detected to complete the handover process.

cwp"} design MSC {source-code: "MSC. the new BTS measurements connector and the new “EndCommunication” connector.cwc" } configuration ms : MS ms_meas : MS_Measure bsc : array(2. y) = ((x.i) <=1 | (x.cwp"} connectors connector BTSConnector { source-code: "BTSConnector. BSC) bsc_meas: array(2.cwc" } connector BTSMeasurements { source-code: "BTSMeasurements.j) >= -1) ((x.3.outMsg bsc[1].cwc" } connector endCommunication { source-code: "endCommunication. If the communication is blocked then the handover is executed.3 Configuration Description of the architecture The architecture of the third approach extends the last architecture with reconfiguration.ms_meas.y.i .cwp"} design BSC {source-code: "BSC.j .transferIn bsc[1].y.inMSg msc.j .lm bsc[1].receive1 18 .j) <=1 | (x. The reconfiguration removes the BTS connector.cwc" } connector BTSMeasureConnector { source-code: "BTSMeasureConnector.i . Architecture GSM_System_3 { location loc = record(i : int.y. j : int) bt(x.cwp"} design BSC_Measure {source-code: "BSC_Measure. BTSMeasurements) endcomm : endCommunication attachments { ms. y) = true components design MS {source-code: "MS.cwp"} design MS_Measure {source-code: "MS_Measure.inMsg bsc[1]. the BTS measurements connector and the “EndCommunication” connector and adds the new BTS connector.outMsg msc.lms .send1 msc.y.transferOut msc. The script “main” verifies the state of the BSC component that holds the communication. BSC_Measure) msc : MSC comm : BTSConnector cmeas : BTSMeasureConnector mbts : array(2.i) >= -1) reach(x.} } 4.

bsc_meas[1].bsc_meas[1].bscr to bsc[1] { outMsg to outMsg inMsg to inMsg communication to communication transferIn to transferIn transferOut to transferOut } refinement cmeas.lbsc .bsc_meas[2].msr to ms_meas { dists to dist1dist2 send_ds to sendBSC1 } refinement cmeas.transferOut msc.bsc_meas[2].send2 msc.communication bsc[2].newId } refinement mbts[1].inMSg msc.communication .bscr to bsc_meas[1] { dists to dist1dist2 receive_ds to receive_dist1dist2 } refinement endcomm.communication .msr to ms { inMsg to inMsg1 outMsg to outMsg1 send to send1 receive to receive1 } refinement comm.newId bsc[2].newId .receive2 bsc[2].bsc_meas[1].bsc_meas[2].lbsc .lm bsc[1].bsc[1].lm bsc[2].newId .rend2 to bsc_measure[2] { communication to communication 19 .msr to ms_meas { l to lms dist to dist2 receive_d to receive_d2 } refinement comm.msr to ms_meas { l to lms dist to dist1 receive_d to receive_d1 } refinement mbts[2].transferIn bsc[2].outMsg bsc[2].rend1 to bsc[2] { communication to communication } refinement endcomm.inMsg bsc[2].communication bsc[1].outMsg msc.

ecomm apply endCommunication { refinement rend1 to bscms. bsc)}) bscend := head(match{bsc : BSC. ms : MS. bsc) with bsc.bsc { outMsg to outMsg inMsg to inMsg communication to communication transferIn to transferIn transferOut to transferOut } } apply BTSMeasureConnector { refinement msr to bscmsmeas. ms : MS. ms : MS_Measure. ecomm : endCommunication) l : list (record (bsc : BSC.bts remove bscend.bsc { communication to communication } } apply BTSConnector { refinement msr to bscms. bts : BTSConnector | bts(ms. bsc_m : BSC_Measure.ms { dists to dist1dist2 send_ds to sendBSC1 20 . bts : BTSConnector)) l := match{ms : MS. bts : BTSConnector) bscmsmeas : record (bsc : BSC_Measure.} reconfiguration script main prv bscms : record (bsc : BSC.ms { inMsg to inMsg1 outMsg to outMsg1 send to send1 receive to receive1 } refinement bscr to bscend. bsc_m : BSC_Measure. ecomm : EndCommunication | ecomm(bsc.block = true} if (l /= nil) then bscms := head (l) bscmsmeas := head(match{ms : MS_Measure. bsc : BSC_Measure.bsc { communication to communication } refinement rend2 to bscmsmeas.bts remove bscmsmeas. bsc_m)}) remove bscms. bts : BTSMeasureConnector) bscend : record (bsc : BSC. bsc : BSC. bts : BTSMeasureConnector | bts(ms.

} refinement bscr to bscend. and in this way to add to the Mobile CommUnity syntax for reconfiguration. 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. For the third approach we still needed to enrich the textual specification with syntax to represent the reconfiguration in runtime and we based on the reconfiguration language presented in ESEC’01 paper [4]. All the architectures presented in the three approaches are specified with the textual language of description of architectures. and to try to surpass the barriers when using one alone languages. 21 . The second is a reconfiguration language used in the development of the third approach. Finally the third approach completes the second adding reconfiguration in runtime for reconfigure the system during handover. 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. The first language is Mobile CommUnity. However for the second and third approaches this language is enriched with syntax for representation and treatment of the locations introduced in Mobile CommUnity. Each approach completes the previous trying to eliminate the disadvantages obtained in the development of the previous one. 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. We developed the case-study using three approaches that are not independent. Briefly the first approach implements the system using pure CommUnity. The Handover is always executed among two neighboring cells that belong to two assumed BTS.bsc_m { dists to dist1dist2 receive_ds to receive_dist1dist2 } } end if end script } Figure 5: Reconfiguration Architecture 5 Conclusion In this case-study we presented the Handover protocol of a GSM system.

One of the relationships is the “be in touch” relation that is used to implement the detection of the possibility of a handover. In the real system the process handover is implemented in the architecture and each component has an important role in the process. We obtained a simplification of the steps of the original protocol. The two unary connectors BTS sends the measurements to the MS or not if they are “in touch” or not respectively. that system stays equal in the three approaches. We need to define a distributed Configurator. this approach doesn’t implement the location notion and the handover begin is not based on the environment. 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. So the evolution of the first approach for the second is mainly centered in the insertion of location variables in the existent components. two BTSs. BTSs. The frag- 22 . The other is an unary connector to calculate the measurements and to send them for the MS. The reconfiguration allows the use of only one binary connector BTS between the MS and the current BSC. In the case-study we developed a mini-system with a MS. Based on the locations. creating a connector in the second approach and using reconfiguration in the third. Finally the handover process is externalized for a connector. BSCs and MSCs. it is random. In end summary let compare this case-study with the real system to obtain conclusions between the reached and pretended results. The relationship “be in touch” is used in an implicit way. This component has a pair of channels and of actions for communication for each BTS of the system. For the calculation of the measurements it became indispensable to also represent BTS like located connectors. 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. One of them is a binary connector to do the communication and measure transfers between the MS and the BSC. and the components are simplified in what it respects to the actions / channels for the implementation of the handover process. because many of the interactions among the components stopped being necessary and the process had been more centralized (Connector / Reconfigurator). When doing the analysis he detects if it is necessary a handover. with the knowledge that should exist in each point of the network.In the first approach the handover process is well defined. In the first approach we implemented a random beginning of handover and we concentrated more in the protocol itself. 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. The way as the handover is begun stays equal of the second approach but the connector handover is substituted by the reconfiguration. the calculation of measurements and the respective sending for the BSC like the real GSM system become possible. The locations are introduced to use the existent relationships in Mobile CommUnity over locations. In the real GSM system the architecture is divided in nodes of the net. we began on the second approach and we developed the third approach. and a MSC. In spite of the handover process to be the closest of the reality among the three approaches. The links used between the MS and BSCs were substituted by two connectors each. as like as the second approach. The locations are implemented in Mobile CommUnity by location variables in the components. For future work it remains to develop an ADT with functions about locations to be used by the reconfigurator. The mini system is static and the MS component is very complex. The detection of the need of a handover is an important point in the architecture of the system GSM. two BSCs. To solve the great disadvantage of the static system and the impossibility of using the same MSs when we add more BTSs. and it is a good introduction for the assumed mini system. We introduced dynamic reconfiguration to control the handover procedure. This architecture is well described in the first approach. 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. In the following approaches we tried to externalize the process from the components. 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. The communication between the MS and the BSCs is implemented by connections of channels and synchronizations of actions. The reconfigurator has a global knowledge of the whole system and it analyzes the state of the components. they are MSs. 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. and when a handover is detected this connector is removed and substituted by a new one between the MS and the other BSC.

Conf. www. training@apis.Lopes and J. pages 41-50. ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE 10). In Proc.Lopes. no. to know how a component can move from “l1” to “l2”.se [3] A. page 713.apis. ACM Press. 6 Acknowledgments I thank the supervision of my supervisor Michel Wermelinger. I thank my cousin Filipe Goncalves who taught me a lot about ¸ GSM Systems and the handover process. To study which possibilities a local reconfigurator agent has to know the locations for besides yours. of the 24th Intl.Fiadeiro. APIS Training & Seminars. 23 . References [1] Fredrik Orava and Joachim Parrow. Department of Computer Systems. The principal goal must be the development of a coordination based software architecture with runtime reconfiguration available. 2001 [5] M.se. o e Without them this work would have been more difficult. 100. applied with the Mobile CommUnity approach. His opinions and suggestions were very important for the development of this paper. J. for mobile / distributed systems. APIS Technical Training AB 1998.Wermelinger. 8th European Software Engineering. An Algebraic Verification of a Mobile Network. Sweden. on Software Engineering.mentary knowledge of the space should be well studied. North-Holland 1990 [2] GSM System Overview. pages 21-32. In Proc. Wermelinger and C. The CommUnity Workbench. 2002 [4] M.L. and Verification X. Architecural Primitives for Distribution and Mobility. pages 275-291. All these subjects should be answered to develop a distributed reconfiguration because a centralized Configurator with global knowledge and omniscient of the whole architecture is impracticable for nets of great dimension. I thank Ant´ nia Lopes and Jos´ Fiadeiro for their support and feedback in the case-study. to know which components exist in several places. Conference/9th Symposium on the Foundations of Software Engineering. 2002.L. A. rev. A Graph Based Architectural (Re)configuration Language. ACM Press. The distribution of the knowledge should be well meditated. ACM Press. Oliveira. In Protocol Specification. Uppsala University.Fiadeiro and M. Testing. In Proc. Wermelinger.

relative path\design.)+ ] [ out ((Name)* : Type.)+ ] [ prv ((Name)* : Type.7 7.1 Specification of Architectures in Mobile CommUnity Current Specification architecture Name { [ components ComponentDecl* ] [ connectors ConnectorDecl* ] [ configuration [ InstancesComp* ] [ InstancesCon* ] [ AttachmentsDecl ] [ RefinementsDecl* ] ] } Architecture ::= /* Components */ /* Connectors */ ConnectorDecl ::= connector Name { source-code: “..cwt” } | connector Name { glue ComponentDecl roles ComponentDecl* [ configuration [ InstancesComp* ] /* Components */ [ AttachmentsDecl ] ] } ComponentDecl ::= design Name { source-code:“.relative path\connector.. Name [ at (Number. Name ) ) InstancesList : ( Name | array ( Number..)+ ] [ do Name : [Expression ->] Name := Expression (|| Name := Expression)* | skip ([] Name : [Expression ->] Name := Expression (|| Name := Expression)* | skip )* ] InstancesComp ::= InstancesCon ::= InstancesList ::= InstancesList : ( Name | array ( Number. Number) ] )* AttachmentsDecl ::= attachments { 24 . Name ) ) Name [ at (Number.cwp” } | design Name [ in ((Name)* : Type.. Number) ] (.

Action .NameComp..Var | NameComp.NameComp. y) = Function(x.” end script ] } loc = Type bt(x.(NameComp) to (NameComp) { (Var to Var )* (prv Var to Expression )* (Action to Action)* } NameComp ::= Var ::= Action ::= Expression ::= Name ::= Number ::= Type ::= Name | Name[X] Name Name “Involves values and the operations of the data types used by CommUnity” < LET T ER > (< LET T ER > | < DIGIT > |“ )∗ (< DIGIT >)+ “Data types used by CommUnity” 7.Action)*} )* } RefinementsDecl ::= refinement Name..Reconfiguration Language..Action (.{NameComp.Var .. y) Architecture ::= /* Components */ /* Connectors */ /* Scripts */ LocationDecl ::= 25 .2 Specification with Future Extensions of the Specification architecture Name { [ location LocationDecl ] [ components ComponentDecl* ] [ connectors ConnectorDecl* ] [ configuration [ InstancesComp* ] [ InitDecl ] [ InstancesCon* ] [ AttachmentsDecl ] ( RefinementsDecl | RepetitiveRefinement )* ] [ reconfiguration [ ScriptDecl* ] script main “. NameComp.

Name [ at (Number..relative path\design. Name ) ) Name [ at (Number... Number) ] )* with NameComp. Number) ] (.Var := Expression ( || NameComp. y) = Function(x..)+ ] [ out ((Name)* : Type.Reconfiguration Language.relative path\connector.Var := Expression )* InstancesComp ::= InstancesCon ::= InstancesList ::= InitDecl ::= AttachmentsDecl ::= attachments { 26 .” end script InstancesList : ( Name | array ( Number.)+ ] [ prv ((Name)* : Type. y) Function(x...cwp” } | design Name [ in ((Name)* : Type..cwt” } | connector Name { glue ComponentDecl roles ComponentDecl* [ configuration [ InstancesComp* ] /* Components */ [ AttachmentsDecl ] ] } ConnectorDecl ::= ComponentDecl ::= design Name { source-code:“.reach(x. y) ::= “Boolean expression which Involves values and the operations of the data types used by CommUnity over the variables x and y” connector Name { source-code: “..cws” } | script Name “.relative path\script. Name ) ) InstancesList : ( Name | array ( Number..)+ ] [ do Name : [Expression ->] Name := Expression (|| Name := Expression)* | skip ([] Name : [Expression ->] Name := Expression (|| Name := Expression)* | skip )* ] ScriptDecl ::= script Name { source-code:“..

Action)*} RefinementsDecl ::= refinement Name.(NameComp) to (NameComp) { (RefVarDecl)* (RefPrvVarDecl)* (RefActionDecl)* ( for i = Number to Number loop RefVarDecl | RefPrvVarDecl | RefActionDecl end loop )* } RefVarDecl ::= RefPrvVarDecl ::= RefActionDecl ::= Var ::= Action ::= NameComp ::= Expression ::= Name ::= Number ::= Type ::= Var to Var prv Var to Expression Action to Action NameComp NameComp Name | Name[i] “Involves values and the operations of the data types used by CommUnity” < LET T ER > (< LET T ER > | < DIGIT > |“ )∗ (< DIGIT >)+ “Data types used by CommUnity” 27 . NameComp.Action .Var AttachActionDecl ::= NameComp.(AttachVarDecl)* (AttachActionDecl)* ( for i = Number to Number loop AttachVarDecl | AttachActionDecl end loop )* } AttachVarDecl ::= NameComp.Var .NameComp.Action (.{NameComp.

Sign up to vote on this title
UsefulNot useful