Beruflich Dokumente
Kultur Dokumente
62
Figure 7-1: Architectural view of an SOL system
The system view depicts the refinement of the system into blocks. In Figure 7-1,
these blocks are named 811 and 812.
The block view depicts the refinement of the system blocks into processes. In
Figure 7-1, these processes are named Pr1 and Pr2.
The process view depicts the finite state machines that perform the functionality of
the particular FE.
Finally, the procedure view depicts the finite state machines that are used by the
processes.
Communication
In SOL, there is no global data. This approach requires that information between
processes, or between processes and environment, must be sent with signals and
optional signal parameters. Signals are sent synchronously; the sending process
continues executing without waiting for an acknowledgement from the receiving
process.
Behaviour
The dynamic behaviour in an SOL system is described in the processes. The
block hierarchy is only a static description of the system structure. Processes in
SOL can be created at system start, or created and terminated at runtime. More
than one instance of a process can exist.
Abstract Data Types
The abstract data types concept in SOL is very well suited to a specification
language. An abstract data type is a data type with no specified data structure.
Instead, it specifies a set of equations that the operations must fulfil.
The software tool that is used for SOL specifications at KPN Research is the SOL
Definition Tool (SOT) version 3.0. SOT not only provides a graphical design editor
and analyser, but also a tool that can be used for simulation of the design. The
simulator provides output as information flow diagrams, that are suited for
elaboration of the developed SOL system.
For exclusive use within KPN and TUE
R&D-SV-96-771 Chapter 7 Applicability Handover Generic Model
7.1.2 The MSC language
ITU has standardised a formal language that defines Message Sequence Charts
(MSCs). As defined in the recommendation [Z.120], the MSC language offers a
powerful complement to SOL in describing the dynamic behaviour of an SOL
system. Its graphical representation is well suited for presenting a complex
dynamic behaviour in a clear and unambiguous way.
An MSC describes one or more traces from one node to another node of an
abstract communication tree generated from an SOL specification. Basically, the
information interchange is carried out by sending messages from one instance to
another. In an SOL specification, those messages would coincide with the signals
that are sent from one process and consumed in another process. The instances
would correspond to any part of the specification (an SOL system, a block, or a
process).
In this study, the MSC language has been used to present a graphical output of
the execution of the simulations of handover processes. These simulations are
necessary, in order to verify the Handover Generic Model. To do so, these MSCs
have been compared with the information flows, as described in chapter six. Some
MSC charts that resulted from the simulations can be found in Appendix B.
7.2 Verification Handover Generic Model
The Model has been verified by formulating SOL specifications of a minimum
number of processes with which all identified aspects of the handover process can
be simulated. The formulated specifications make use of the handover information
flows, described in chapter six. In order to be able to verify all handover aspects,
supported by the Model, the choice has been made to specify the handover
functionality of one UMTS environment. The public (metropolitan) high traffic
environment has been selected according to its importance (Le., high number of
users). This section describes how the UMTS system has been specified and
which aspects of the UMTS system have been omitted.
7.2. 1 Formulated SDL specifications
The system of the formulated SOL specifications has been divided into blocks
according to the Functional Groups (FGs) encountered in this UMTS environment
(as described in chapter three).
Each FG has been divided into processes according to the Functional Entities
(FEs) encountered in the Handover Functional Model. The precise allocation of
each FE onto the FGs, with respect to this UMTS environment, has been
described in chapter five.
The signals used in the communication between the processes, the FEs, are the
Information Flows (IFs) of the handover application protocol. These IFs have been
described in chapter six.
The behaviour of the FEs has been formulated in such a way that each FE, if
necessary, can be re-used in other FGs.
The SOL specifications that have been formulated in order to verify the Model can
be found in Appendix A.1-3. Some MSC charts that resulted from the simulations
can be found in Appendix B.
For exclusive use within KPN and TUE
63
Development of a generic model for handover in UMTS R&D-SV-96-771
7.2.2 Restrictions of the SDL specifications
The main objective of the formulated SOL specifications and the simulations is the
verification of the defined Handover Generic Model. This is done by means of the
elaboration of an example of a UMTS environment, the public (metropolitan) high
traffic environment. In order to reduce the complexity of the SOL specifications,
some aspects of the UMTS environment have been omitted:
Switching and data processing functionality is omitted
The functionality of the FEs (switchill9 of bearers, and the storing, gathering, and
combining of user and control data) has not been specified. This has not been
studied in this report. Only the IFs that start the execution of these functionalities
and the IFs that result from that, are specified. The result of this is a high level
description of the handover functionality.
One handover process at a time
The formulated SOL specifications of the UMTS system are not able to perform
multiple handover processes simultaneously. The handling of multiple handovers
has been no subject of study.
No intra BTS handovers
These handovers depend on the radio interface the UMTS network has been
equipped with. The handling of these handovers is supposed to be performed at
the lower three layers of the OSI protocol stack. This entails the invisibility of these
handovers at the handover application layer. Hence, the intra BTS handovers
have not been specified.
No inter LE and inter environment handovers
These handover cases have not been specified. These cases require functionality
(Le. transfer of control point) that introduces a lot of complexity.
No interconnection between network elements.
The study, described in this report, has made use of a tree topology without
interconnections between network elements (FGs). The interconnections of FGs
and the network topology introduce complement lower layer protocols between
FGs(Le., rerouting procedures, chapter three). These messages have no impact
on the handover application layer. Hence, only the tree topology without
interconnections has been studied.
Network errors are omitted
Each functionality performs correctly, and does not introduce errors nor negative
results. Among other things, this entails that each request for handover (issued by
the Handover Initiation (HI) entity), always results in the performance of the
requested handover process. In reality, the HI entity creates a list of possible
handover processes with respect to one user. The HI entity will request the
Handover Decision (HD) entity to perform a handover process that is on top of this
list; having the best characteristics. The HD entity will calculate whether the
performance of this process is possible or not. If, Le. the requested handover
process requires too much bandwidth, the HD entity will respond with a negative
result. In that case, the HI entity will continue with the request of the second
handover process on its list. These requests and rejections continue until the
handover has been performed, or the situation has been changed.
64 For exclusive use within KPN and TUE
R&D-SV-96-771 Chapter 7 Applicability Handover Generic Model
7.3 Coverage Handover Generic Model
The coverage of the Model has been studied by describing the assumptions that
have been taken into consideration with respect to the handover aspects.
Furthermore, the coverage has been studied by the identification of options of the
handover aspects that have not been studied.
With respect to the handover aspects, the following assumptions have been
made:
The radio interfaces have no impact on the application layer
As described in chapter three, only the lower layers of the radio interfaces are
used.
The impact of the UMTS environments and reference configurations is
limited to the allocation of the FEs.
The UMTS environments and reference configurations define the way the
handover functionality has been allocated to the FGs of the UMTS network
(chapter three). Hence, the have no impact on the handover functionality.
All handovers within the security control domain
From a security point of view, two more handover cases can be distinguished:
handovers inside one security control domain, and handovers between security
domains. The handover related security functions have been no subject of study,
and therefore each handover is supposed to be within a particular security control
domain.
Taking these assumptions into consideration, the Handover Generic Model covers
all identified handover aspects, identified in chapter three. However, the different
options of an handover aspect that can be used in a particular handover scenario
are not all covered by the Model. Two options have not been taken into
consideration:
Firstly, the handover initiation part of the handover decision phase is assumed to
be unique for each handover scenario. This 'unique' part is called a backward
handover. Another way to perform this part of the handover process is a forward
handover. These two types, concerning the control of the handover process, have
been clarified in chapter three (section 3.7). A forward handover can be performed
in two cases. The first case is when the Handover Initiation (HI) entity has been
allocated in the MT and the handover has been Mobile Initiated (MI), or has been
requested by the network or the user (SHRN or SHRU). The other case in which a
forward handover can be performed is when the HI entity has been allocated in
both the MT and the network, aAd the handover has been Mobile Originated (MO).
These options do not require any new Information Flows between entities.
Therefore, these handover types, concerning the control of the handover process
can easily be added to the Handover Generic Model.
Secondly, the execution of the hard handover type is assumed to be possible in
two ways: seamless and non- seamless. With respect to this handover type, it
has been assumed that there is sufficient time for the establishment of the new
path. This is the make-before-break (non-) seamless hard handover type. Another
type that might be necessary is called a break-before-make (non-) seamless hard
handover. These two types, concerning the transport aspects of the handover
process have been clarified in chapter three. In the case there is not sufficient time
for the establishment of the new path, the needed handover type is different. In
this situation it is possible that the radio link between the MT and the old BTS is
For exclusive use within KPN and TUE
65
Development of a generic model for handover in UMTS R&D-SV-96-771
released before the establishment of the fixed network connection between the
new BTS and the network switching point. A hard handover in this situation is
referred to as a break-before-make (non-) seamless hard handover.
7.4 Conclusions
This chapter explored the applicability of the developed Handover Generic Model.
The Model has been verified by formulating SOL specifications of the handover
application protocol, valid in an example environment. The selected example
environment is the public (metropolitan) high traffic environment, according to its
importance (Le., high number of users).
The restrictions that have been made in order to reduce the complexity of the SOL
specifications have been described and justified.
The coverage of the Model with respect to all handover scenarios has been
studied, by describing the assumptions that have been taken into consideration.
Furthermore, the coverage has been studied by the identification of options of the
handover aspects that have not been studied.
66 For exclusive use within KPN and TUE
8
CONCLUSIONS AND RECOMMENDATIONS
This report describes the definition of a Generic Model for the handover functionality in
UMTS that is suitable for all handover scenarios. In this chapter, conclusions are
drawn whether the goal of the project is met (section 8.1). In section 8.2 some
recommendations and issues for further study regarding the Handover Generic Model
are presented.
8.1 Conclusions
An important functionality, concerning UMTS, is the handover functionality. To
efficiently implement this complex functionality, a model is needed that can handle
all possible handover scenarios. The development of such a generic model was
the goal that had to be achieved for this project.
The analysis of the common features of the handover process in UMTS pointed
out that this process depends on several aspects. These aspects are the
handover initiation points, handover initiation procedures, bearer types, the UMTS
reference configurations and environments, the handover cases, the handover
types, and, finally, the radio interfaces that the network has been equipped with.
It is concluded that each handover aspect is relevant during only one particular
part of the handover process. Each handover aspect identifies possible options in
the performance of the particular part of the handover process. Because of this,
each handover scenario can be described by a combination of options regarding
these handover aspects.
The aspects and their options have been used to describe the allocation of
Functional Entities onto Functional Groups of an example UMTS environment. It is
concluded that the precise description of the possible signalling associations
between the Functional Entities, and hence between the Functional Groups is
valid for each handover scenario.
These signalling relations between the Functional Groups have been
characterised by describing the Information Flows. The Information Flows describe
the needed interaction between Functional Entities as to support their joint
operation. It is concluded that the developed top-level structure of the handover
Information Flows is suitable for all handover scenarios.
The developed Handover Generic Model structures the options accompanying
each handover aspect, and consequently models all possible handover scenarios.
It is concluded that the Model reduces 660 different handover scenarios to 27
modules with which all these scenarios can be performed.
The coverage of the Model has been studied, by formulating SDL specifications of
the Functional Groups of the example environment. These SDL specifications are
used to simulate all identified handovers. It is concluded that the Model can handle
all 660 possible handover scenarios.
For exclusive use within KPN and rUE
67
Development of a generic model for handover in UMTS R&D-SV-96-771
8.2 Recommendations and future work
Regarding the restrictions of the SOL specifications
Three handover cases can occur that have not been specified: intra BTS
handover, inter LE handover, and inter environment handover. In a real UMTS
these handover cases can occur. Therefore, they have to be specified. In the
case of intra BTS handover, this involves the analysis of the radio interfaces. In
the case of inter LElinter environment handover, this involves the analysis of
the transfer of control point functionality.
The network topology of the specified UMTS environment is a tree topology
without interconnections between Functional Groups. In future UMTS other
topologies and possible interconnected Functional Groups might be needed.
Regarding the assumptions with respect to the handover aspects
It has been assumed that the radio interfaces do not impact the application
layer. With respect to the second generation radio interfaces, this is merely one
of the migration options. Another option is that the complete protocol stacks of
these radio interfaces are re-used. In that case the Radio Access System must
perform the interworking between the UMTS protocol stack and the stack of the
radio interfaces.
All handover scenarios studied in this report are handovers within one security
domain. In a real UMTS, handovers can occur between security domains. This
requires handover security entities, that have not been studied in this report.
Regarding the coverage of the Handover Generic Model
The Handover Generic Model only supports backward handover. Another way
to perform the initiation of a handover is called forward handover. These
handovers might be required, e.g. if a radio interface is used that does not
support a backward control of the handover process.
With respect to the handover types it has been assumed that there is sufficient
time for the establishment of the new path. Situations can occur that
connections are lost abruptly. In these situations, a handover type is needed
with which the call can be recovered. This hard handover type is called a break-
before-make handover.
68 For exclusive use within KPN and rUE
[Black95]
[Bro93]
[MONET 65]
[MONET 70]
[MONET 7"1]
[MONET 73]
[MONET 80]
[MONET 99]
[MONET 100]
[MONET 107]
[MPLA 7]
REFERENCES
Black, U.
ATM FOUNDATION FOR BROADBAND NETWORKS. 1
st
ed.
New Jersey: Prentice Hall, 1995.
van den Broek, W; Motagna, M.
IMPLEMENTATION ASPECTS OF THE UMTS NETWORK
Contribution to RACE mobile Telecommunication Workshop
France, Metz, 16-18 June 1993
CEC Deliverable R2066IVTT/GA4/DS/P/065/a2
EVALUATION OF SUPPORTING PROTOCOL STACKS
RACE MONET, members of GA4, 1994
CEC Deliverable R2066/BT/PM2IDS/P/070/b2
UMTS SYSTEM STRUCTURE DOCUMENT
RACE MONET, members of PM2, 1994
CEC Deliverable R2066/CSELT/MF2IDS/P/071/b2
BSS ARCHITECTURE AND INTERCONNECTION SCHEMES
RACE MONET, members of MF2, 1994
CEC Deliverable R2066/SEUGA3/DS/P/073/b1
UMTS FUNCTIONAL AND NETWORK ARCHITECTURE
RACE MONET, members of GA3, 1994
CEC Deliverable R2066/CSELT/MF2IDS/P/080/a1
DEFINITION OF HANDOVER PROTOCOLS
RACE MONET, members of MF2,1994
CEC Deliverable R2066/PTT NUMF/DS/P/099/b1
BASELINE DOCUMENT ON LOGICAL AND FUNCTIONAL MODELS
RACE MONET, members of M1, M2, M3, and MF4, 1995
CEC Deliverable R2066/RMRlUNA2IDS/PI100/b1
INTEROPERABILITY AND INTEGRATION OF UMTS IN B-ISDN
BACKBONE
RACE MONET, members of UNA2, 1995
CEC Deliverable R2066/RMRlUNA2IDS/P/1071b1
RECOMMENDATIONS OF UMTS INTEGRATION SCENARIOS IN THE
B-ISDN BACKBONE
RACE MONET, members of UNA2, 1995
CEC Deliverable MPLAlCSELTISIG2/007
UMTS TRANSPORT AND CONTROL FUNCTION ALLOCATION IN A
B-ISDN ENVIRONMENT
RACE CODIT, MONET, MBS, AND ATDMA, 1995
For exclusive use within KPN and TUE
69
Development of a generic model for handover in UMTS R&D-SV-96-771
[0.1202]
[0.1204]
[0.1205]
[0.1214]
[0.1215]
[RAINBOW 1]
[RAINBOW 4]
[SOT 3.0]
[Stallings95]
[Z.100]
[Z.120]
70
ITU-T Recommendation 0.1202
INTELLIGENT NETWORK SERVICE PLANE ARCHITECTURE
Geneva: ITU-T, 1992
ITU-T Recommendation 0.1204
INTELLIGENT NETWORK DISTRIBUTED FUNCTIONAL PLANE
ARCHITECTURE
Geneva: ITU-T, 1992
ITU-T Recommendation 0.1205
INTELLIGENT NETWORK PHYSICAL PLANE ARCHITECTURE
Geneva: ITU-T, 1992
ITU-T Recommendation 0.1214
DISTRIBUTED FUNCTIONAL PLANE FOR INTELLIGENT NETWORK
cs-1
Geneva: ITU-T, 1992
ITU-T Recommendation 0.1215
PHYSICAL PLANE FOR INTELLIGENT NETWORK cs-1
Geneva: ITU-T, 1992
CEC Deliverable AC015/BELUCIT/DS/P/001Ib1
RAINBOW DEMONSTRATOR ARCHITECTURE AND SERVICES
ACTS RAINBOW, CIT, 1995
CEC Deliverable AC015/BELURMC2IDS/R/004/b1
IDENTIFIED RAS ARCHITECTURES FOR THE TARGET
ENVIRONMENTS
ACTS RAINBOW, RMC2, 1996
SOT 3.0
GEITING STARTED
Malmo, Telelogic, 1995
Stallings, W.
ISDN AND BROADBAND ISDN. 3
rd
ed.
New Jersey: Prentice Hall, 1995.
ITU-T Recommendation Z.1 00
SPECIFICATION AND DESCRIPTION LANGUAGE SOL
Geneva: ITU-T, 1994
ITU-T Recommendation Z.120
MESSAGESEOUENCECHART(MSC)
Geneva: ITU-T, 1992
For exclusive use within KPN and TUE
Appendix A: FORMULATED SOL SPECIFICATIONS
The feasibility of the Handover Generic Model has been studied by formulating SOL
specifications of the Functional Groups of the example environment. These
specifications have been placed in this appendix. The meaning of the used SOL
symbols can be found in [Z. 100J and will not be explained here.
SOL Overview
The structure of the developed SDL specifications of the public (metropolitan) high
traffic environment of UMTS is depicted in the following overview (see Figure A-1).
RAS
Figure A-1: Overview SOL specifications
The Figure illustrates that the UMTS users (USERS block) are connected to the B-
ISDN Core Network (B-ISDN block) via the Radio Access System (RAS block).
The USERS block consists of one user, and therefore one Mobile Terminal (MT).
The RAS block consists of four BTS sub-blocks and two CSS-Ievel sub-blocks.
The CSS-Ievel sub-block is divided into a MSCP(Access) part and a CSS part.
The B-ISDN block consists of one LE-Ievel that is divided into a MSCP(Core) part
and a LE part.
This structure is according to the UMTS Reference configurations, as discussed in
chapter 3 of this report (Figure 3.4 and Figure 3.5). The sub-blocks and their parts
For exclusive use within KPN and TUE
A-1
Development of a generic model for handover in UMTS R&D-SV-96-771
can be seen as Functional Groups. The Functional Entities can be allocated onto
these Functional Groups, as discussed in chapter 5 of this report. Therefore the
Functional Groups are interpreted as processes (not shown in the Figure).
The SDL specifications of the UMTS system are shown according to the hierarchy
discussed in chapter 7 (system, block, process, and procedure view).
System view
o
System UMTS Public_Metropolitan_High3ralfic(4)
,-----
~
(CMC)
El B ~
I ~ L____.J
(HOC) (HUPj
~
(MEF) [RBC I
ENV_BTS1 ENV_BTS2 ENV_BTS3 ENV_BTS4
El E9 ~
(TCCj ( T C C ~ ((8TS_aim_data (RTS_sim_data (BTS_sim-<tala (BTS_aim_data
[IBTS_MTI] MT BTS1 [IMUTSI) [IBISON_AASI] CSS1 BISON[IAAS_SlSoNI)
ICSS_MT)
MT_CSS1 [IMT_CSSI]
IBTS_MTl
MT_BTS2 [IMUTSI)
USERS
RAS
BISON
IBTS_MT) MT_BTS3 [IMT_91SI]
ICSS_MTl MT_CSS2 [IMUSSI]
IBTS_MTl MLBTS4 [IMUTSI) (BISON_RASl] CSS2.BISON [IAAS_SlSoNI]
t
[IBISoN_MT)]
MT.BISON
[IMT_BISoNI]
/
ENV_MT ENV.CSS1 ENV.CSS2
[IMT_om_datal] [ICSS_om_datal] [Ccss_sim_datal]
Figure A-2: System view UMTS Public (Metropolitan) High Traffic Environment
A-2 For exclusive use within KPN and TUE
R&D-SV-96-771
o
System UMTS
,----"'"
,
L J
Appendix A Formulated SDL specifications
SignaLdefinitions(4)
,integer),
ADD CONNresp conf,
CAND_LIST_REPORT(lnteger,lnteger),
CONNECTreq_ind(lnteger,CharString),
CONNECTresp_conf,
DROP_CONNre<Und(lnteger,lnteger),
DROP_CONNresp_conf,
HO_COMPLETEreqjnd,
HO_COMPLETEresp_conf,
HO_CONTROLrelL1nd(lnteger,lnteger,CharString,HO_Types_Type),
HO_CONTROLresp_conf,
HO_CRITERIArelLind,
HO_CRITERIAresp_conf,
HO_INITIATlON_INDreq_ind,
HO_INITIATION_INDresp_conf(lnteger),
HO_INIT_REQrelLind(lnteger,lnteger,HO_Types_Type,HO_lnitiation_Points_Type)
HO_INIT_REQresp_conf,
ho_type(HO_Types_Type),
inLconfiguration(HO_lnitiation_Points_Type),
ini_configuration_slave(CharString,CharString),
L1NK_QOAL_REPORTQnteger,HO_initiation_f:'rocs_Type),
MEF_uRdate(HO Initiatron_Points_Type,lnteger,HO_lmtiation_Procs_Type),
RELEASE_Bl'lIDGErelLind(lnteger,lnteger),
RELEASE_BRIDGEresp_conf,
RELEASErelLind(lnteger,CharString),
RELEASEresp_conf,
RESOURCE_INFOreq_ind,
RESOURCE_INFOresp_conf(lnteger),
SERVICE_DATAreq_ind,
SERVICE_DATAresp_conf,
SET_BRIDGErelLind(lnteger,lnteger),
SET_BRIDGEresp cont,
SHRN_HO(lntegerJnteger,HO_lnitiation_POints_Type),
SHRNreq_ind(lnteger,lnteger,HO_lnitiation_Points_Type),
SHRNresp_conf,
SHRU_HO(HO_lnilialion_Points_Type,lnteger,lnteger),
SHRUreq_ind(lnteger,lnteger),
SHRUresp conf,
SWITCH_CONNreq_ind(lnteger,lnteger),
SWITCH_CONNresp_conf,
TCCN_update(lnteger),
TCCU_update(lnteger,lnteger,HO_lnitiation_Points_Type),
USER_DATAreq_ind,
USER_DATAresp_conf;
Figure A-3: UMTS Signal definitions
For exclusive use within KPN and TUE
A-3
Development of a generic model for handover in UMTS
o
R&D-SV-96-771
System UMTS
I
L J
. aeclarallons-, I'
newtype HO_Types_Type ..
literals soft,seam,nonseam;
endnewtype;
newtvpe HO_lnitiation_Points_Type
literals mt,bts,bothmt,bothbts;
endnewtype;
newtvpe HO_lnitiation_Procs3ype
literals mi,ni,mo,no,ma,shru,shrn;
endnewtype;
SignaUists_1 (4)
A-4
"::;ystem UM l::i ::ilgnaUlsts "'
SIGNALLIST BTS MT =
ini_configuration-"Slave,HO_COMPLETEreq_ind,HO_COMPLETEresp_conf,
HO_INITIATION_INDreq_ind,HO_INITIATION_INDresp_conf,
CONNECTreq_ind,RELEASEreqjnd,SHRUresp_conf,USER_DATAreq_ind;
SIGNALLIST MT BTS =
LINK_OUAL_REPORT,CONNECTresp_conf,HO_COMPLETEreq_ind,HO_COMPLETEresp_conf,
HO_INITIATION_INDreq_ind,HO_INITIATION_INDresp_conf,ini_configuration_slave,
CAND_L1ST_REPORT,RELEASEresp_conf,SHRUre<1-ind,USER_DATAresp_conf;
SIGNALLIST MT_CSS =
ADD_CONNresp_conf,DROP_CONNresl'_conf,SET_BRI DGEresp_conf,SWITCH_CONNresp_conf,
RELEASE_BRI DGEresp_conf,HO_INIT_REOreq_ind,SHRNresp_conf;
SIGNALLIST CSS_MT =
ADD_CONNre<1-ind,DROP_CONNreq_ind,SET
RELEASE_BRI DGEreq_ind,HO_INIT_REOresp_conf,SHRNreq_ind;
SIGNALLIST RAS BISDN=
HO_CONTROLrecl-/nd,CONNECTresp_conf,RELEASEresp_conf;
SIGNALLIST BISDN_RAS=
HO_CONTROLresp_conf,CONNECTreq_ind,RELEASEreq_ind;
SIGNALLIST MT BISDN=
ADD_CONNresp_conf,DROP_CONNresp_conf,SET_BRIDGEresp_conf,SWITCH_CONNresp_conf,
RELEASE_BRIDGEresp_conf;
SIGNALLIST BISDN_MT=
ADD_CONNreq_ind,DROP_CONNreq_ind,SET_BRIDGEreq_ind,SWITCH_CONNreq_ind,
RELEASE_BRIDGEre<1-ind;
SIGNALLIST MT_sim_data=
ini_configuration,MEF_update,SHRU_HO,TCCU_update,ho_type;
SIGNALL1ST BTS sim data=
MEF_update,inLconfiguration,ho_type;
SIGNALLIST CSS_sim_data=
SHRN_HO,TCCN_update;
, l:!locK HA::i ::ilgnailists -,
SIGNALLIST BTS_CSSI=
HO_INIT_REOre<1-ind,SHRNresp_conf,CONNECTresp_conl,RELEASEresp_conf;
SIGNALLIST CSSI_BTS=
HO_INIT_REOresp_conf,SHRNre<1-ind,CONNECTreq_ind,RELEASEreq_ind;
Figure A-4: Signal-lists UMTS system and RAS block
For exclusive use within KPN and TUE
R&D-SV-96-771
o
System UMTS
,-----.
, ~
L J
Appendix A Formulated SOL specifications
SignaUists_2(4)
tllOCK I ype \j::i::ilevel ::ilgnalllsls "' rJ
SIGNALLIST MSCP_CSS =
SET_BRIDGEreqjnd.SWITCH_CONNreQ_ind.RELEASE_BRIDGEreq_ind.ADD_CONNreQ_ind.
DROP_CONNreQ_ind.CONNECTrecLind.RELEASErecLind;
SIGNALLIST CSS_MSCP =
SET_BRIDGEresp_conf.SWITCH_CONNresp conf.RELEASE_BRIDGEresp_conf.
ADD_CONNresp_conf.DROP_CONNresp_conT,CONNECTresp_conf.RELEASEresp_conf;
SIGNALLIST MSCP BTS =
HO_INIT_REQresp'::::conf.SHRNreq..Jnd;
SIGNALLIST BTS_MSCP =
HO_INIT_REQrecLind,SHRNresp_conf;
SIGNALLIST BTS_CSS =
CONNECTresp_conf,RELEASEresp_conf;
SIGNALLIST CSS_BTS =
CONNECTreq..Jnd,RELEASErelLind;
SIGNALLIST Access_Core =
HO_CONTROLreq..Jnd;
SIGNALLIST Core_Access =
HO_CONTROLresp_conf;
SIGNALLIST CSS LE =
CONNECTresp_conf.RELEASEresp_conf;
SIGNALLIST LE_CSS =
CONNECTreQ_ind.RELEASErelLind;
tllOCK I ype Ll:level ::ilgnaUlsts "' I:l
SIGNALLIST LE_MSCP =
ADD_CONNresp_conf,DROP_CONNresp_conf,SET_BRIDGEresp_conf,SWITCH_CONNresp_conf.
RELEASE_BRIDGEresp_conf,CONNECTresp_conf,RELEASEresp_conf;
SIGNALLIST MSCP LE =
ADD_CONNreQ_ind-;DROP_CONNreQ_ind.SET_BRIDGEreQ_ind.SWITCH_CONNrelLind.
RELEASE_BRIDGEreQ_ind.CONNECTrelLind,RELEASErelLind;
Figure A-5: Signal-lists block types CSS level and LE level
For exclusive use within KPN and TUE
A-5
Development of a generic model for handover in UMTS
Block view
Users
Block USERS 1(1)
.-----
~
I ~
L____.J
[IBTS_Mn] BTS1 [IMUTSl]
BTS
[(CSS_MTl]
CSS1 [(MUSSl]
CSS
MT1:MT [IBTS_MTl] BTS2
(MT_BTSl]
BTS
((MT_Sim_dat8)]
SIM
[(BTS_MTl] BTS3
(MT_BTSl]
BTS
SIM
[lcSS_Mn] CSS2
IMT_CSSl]
CSS
[IBTS_MTl] BTS4
(MT_BTSl]
BISOfIBTS
1t(BISDN_MTI]
BISON
LIMT_BISDNlJ
Figure A-6: Block view UMTS users
R&D-SV-96-771
MT_CSS1
MLBTS2
MT_BTS3
MT_CSS2
MLBISON
A-6 For exclusive use within KPN and TUE
R&D-SV-96-771 Appendix A Formulated SOL specifications
Block Type
BT51 8T52 8T$3 BTS4 SIM BTSl BTS2 BTS3 BTS4
BTS4
BISON
CSS2
eSS1
BISDN
CSS2
eSS1
BTS1
BTS4
eSS1
8T52
8TS1
CS$2
8T53
BTS2
SIM
BTS'
BTS2
BTS3
BrS4
BTS3
Bkx:k Type
MT[USER_DAT__"')
HUPU_E
S'
SER DA"
"P__)
1[........ _...)
'(1)
[SHRU_HO] USER_ HRU
SHAU_BTS2 [SHRU___
.----""'"
[USER_DAT.wq..Jnd] [us R_OJ
r_
-) I "I
HUPU_BT
[""".
...)
SHAU_BTS' [ __
BTSl
1. ____.1
[USER_DAT__"')
HUPU_BT [us R_OJ
r_
-)
[""". -"'1
SHAU_BTS3(_.-
[ISTS_"") [USER_DAT__"')
HUPU_BT [us R.D
r_
-)
[SHRUo _...)
SHAU_BTS4 [ ___
+aTsi
(9TS_"")
( BTS
(SEA_; BTSI BTS2
BTS3
BT)
((9TS "")
HUPUmt:HUPU
J
SHRUmt:SHRU
HI_o HU HU HI_o HU HI_o
f---i
(IBiS.",,)
(USER_DAT___) .1HUPU_HI
HI_HC <lH'-
[USE DATMlq.Jr.cl} '_HUPU [ CRlTERI
p__) HC_H
SHRU_HI
]
... ]
_ HUPU_i HUPU_o
HC_o HCj
SHRU_o "'
HO)N1TlATIC;)/'()NOresP_conI
ini_conligumlOO_slave
SHRU_i
8T54_0
54 BTS_i
-",
1
... ]
-.
.......conligullllion_sIIMt
_....
--. - 8T53_0
-",.,
S3 BTS_i Hlmt:HI
_....
. -. 8T52_0
-", ..
TS2 BTS_i
-"'I
_slave _WIll.
n_
-",.] 8T51_0
_..,. p_conf.
[tfOJNlT_REOnosp_conI] [HO INlT RfOreq ind]
TS' BTS_i Si'Rlreq...Jnd HI CSS, SHRNIasI> eonl
00"-
CSSl -
!"-l
HI_CSS2
[HO .lNlT_REQreq_ind]
ho_"'"
SHAN.esJU:onl
SIM USERj CSS2
n,_u,on
MEF_i TCCU_i
[UN<_OUAL_REPORT]
MEF_Hl
1TCCU_HI [CANO_lIST_REPOAT]
_0'
(ME'__)
USER MEF
MEFmtMEF CCUmtTCCU
USER_TCCU
(m:u__)
1M USER_i
USER_i
Sl
UNlCQUN.._REPORT
MEF_BTSl
BTSCo TCCU_aTS1
lIN1UlUAlYlEPORT
ME' BTS2
aTSCo
TS2 BTS2_0
BTS2_0
TCCU_BTS2
S3
LlNUJUAl..
MEF BTS3
Br53_0 TCCU BT53
UNICQUAl._RfPORT
MEF BrS4
BTS3_0
54
BTS4
TCCU_BrS4
BT54_o
CSS1 [CONNEcTfeQjnd, ] ICONNECTrMP coni,]
teSsi
(I'"_CSSI) (less_Mn)
RELEASE.-q ind RBC_BTS coni
BTS1
(CONNECTfeCI..,lncI. ] [CONto.ECTresp..eool. ]
+siM
(I'"_CSSI) (Iess_..,.,)
ABC BTS2
AELEASE.esp_conI
BTS2
BiSiiN
[1"'_....--,) RBCmt:RBC
tX.>NtECTresp_Conl, ]
RBC_BTS3
RElEASEresp_oonl
f---i
[I'"-"'SONI) (18""_"",)
BTS3
[CONNECTreq_ind,} [CONNECTresp_conl, ]
AELEASEreq.ind RBC_BTS4 RELEASEresp coni
[SET BRIDGEreq ind, ]
BrS4
SWItCH jnd, [SET BRlDGEresp oonl, ]
RELEASE BRlOG recUrld SWITCH..CONNreSl_Conl.
HOC SBC_CSS1 SBC HOC eSS1
RELEASE 8RIOG resp oonl
eSS1 HOC_i HOC_o
]
]
SWITCH CON _conl,
SBC"',SBC
HOC_SBC_CSS2 SBC_HOC_CSS2
CSS2 HOC_i HOC_o
[SET [SET BAlOGE'"P_
wnl
. I
BISON_SBC SBC_BISON
ISDN HOCJ HOC_o
[ADD OON__", l
!ADDOON___.]
DROP CClNthsp conl
HOC_CMC CSSl
OROP_CONNreot.-iIid
CMC_HOC_CSSl
eSS1 HOC_i HOC_o
CMCmtCMC
[ADD CClNPftsp_conl,]
HOC_CMC_CSS2 CMC_HOC_CSS2
DRoP_CONNresp_conl
eSS2 HOC_i HOC_o
[ADDOON_ ...l
1.-.00 CONNresp_conl, ]
BISON_CMC
DROP_CONthq_ind
CMC_BISON
DROP_CONNrctsp_conI
ISDN HOC_i HOC_o
BT
B
BT
S
BT
B
BT
BT
[I"LOTSI)
[I"LOTSI)
[1"'_BiSl)
[""_BiSl)
Figure A-7: Block type Mobile Terminal (MT)
For exclusive use within KPN and TUE
A-7
Development of a generic model for handover in UMTS R&D-SV-96-771
RAS
Block RAS
ICSSlev3
[ICSS_MTl)
1(1)
.------.
(CSS_"_"'lJ
I "I L ____.J
MTCSS1
'l;NVCSSl
MTBTSI
[IBTSJJll) [IMUTSl)
1
IM' ,II BTSI CSSI
[IMUSS']
[IBTS_""'_""")
BTSI :BTS [ICSSUITS'] - [IBT'-CS"']
SIM
1 SIM CSS
MTBTS2 BTS2_CSSI SSievell :CSSlevei
[IBTS_Mll)
[IMUTS')
[ICSSljlTSl] [IBTS_CSS'] [IBOSON_AAS') CSSILE [IAAS_BOSON')
2 M' BTS I LE
(IBTS--,,",_""")
IBTS2:BTS
I 2 SIM
c
MTBT
5;
[IMTjlTS,)
IM' ,II BTS3 CSS2
[(BTS_Sim_da..)] BTS3:BTS [ICSSljlTSl] (IBTS_CSSO)
[IBOSON_RAS') CSS2LE [IRAS_B"""')
3 SIM CSS LC
BTS4_CSS2
[IBTS_Mll) (IMTjlTS,) [IBT'-C.",]
SSleveI2:CSSlevet
M
I
BTS_I
IBTS4:BTS
MT
[(BTS_Sim_dalll))
(MT_eSS) SIM
ENVCSS2
MTCSS2
[ICSS_MTl)
ICSS_..._....,)
CSS,-BISDN
Figure A-8: Block view Radio Access System (RAS)
Block Types
HI_ol------------------iI MT
1(1)
.:.US:::E:;;R;;;_::::M.:.E;..F ---i SIM
HUPU_o 1-------------------lI MT
MEFj
[UNK_OU '-REPORT)
M F_HI
LH
MT_HI
MT HU
Hlbts:HI
MT
HUPU_HI
HUPU_'
MT
CAND_UST_FlEPORT
TCCU_HI
TCCU_i
Block Type BTS
f----u.
MT L .J
[IBTS_MTJ]
[IMUTSI]
CSS
[IBTS_CSSII]
SIM [ICSSO_BTSI]
[IBTS_.m_"'lal]
CSS !f------..."...,.,=--------lI css
[SHRU.",,__]
MT
rCONNEcrresp_conf,]
lRELEASEreSJl_coof
CSSIE----- MT
]
"- oF [CONNECTf*I,...lnd,]
[
CONNECTfell,.ind, - FlELEASEteqjnd
Figure A-9: block type Base Transceiver Station (BTS)
A-8 For exclusive use within KPN and TUE
R&D-SV-96-771 Appendix A Formulated SDL specifications
MT SIM
[ICSSCSTSI]
[ICSOl_BTSI]
:<RAS_BISDN)]
[Icss_"n]
Block Type CSSlevei
1(1)
.----- ENV_CSS
I
IAccess I
L ____ .J
ICSS_Mn] [(CSS_lim_deta>]
BTS_
+sTsj
[IBTS_CSOlI]
[IBTS_CSSlI]
MT_MSCP
[IBISON_RASI)
[IMT_C55I) [IMT_CSSI]
----l
[I"SCP_BTSI] BTSu_MSCP [IBTS_"SCPI)
MT SI
[(Core_AcceSS)] MSCP_LE [ (AcceSS3Me>]
BTS BTS_u MSC
[<"SCP_BTSI) [IBTS_"5CP))
MSCP:Acce.,
BTSI_MSCP
BTSJ BTS_I
css
(CSS_MSCP>]
MSCP_CSS
,\1"5OP_CSSI)
[ICSS_BTSI)
BTSu_CSS
[IBTS_CSSI) [ILUSSI) CSS_LE [ICSUEI) I,,,,r
BTS BTS_u L
[ICSS_BTSI) [IBTS_CSSI)
CSS:CSS
BTSLCSS
BTS I BTS_I
Figure A-10: Block type Cell Site Switch (CSS) level
LE
LE
MSCP MSCP MSCP MSCP
Block Type CSS
SBC_HOC HOC_SBC
1(1)
r----
CMC_HOC HOC_CMC
I
[SET BRIOGE.... _,
[5ET_BRIDGE,""-"", J
SWITCH SWITCH CONN Ind,
BTS_
L____.J
RELEASt_BRIDG resp_con [AOD ] [ADD CONNresp_conf, ]
DROP_CONNI'8Q..I DROP_CONNresp_conl
---.;
[IBT5_CSSI]
BTS_I
(HOC i HOC
---.;
[<BTS_CSSI]
[HKO HOC]
CMCCS5:CMC
MSCF SBCcss:SBC
---.; [<"SCP_CSSI]
LE
---.;
[ILE_CSSI]
[ CONNECTrell.,.ind] [ CONNECTNlsp_conl]
[CONNECTf8CL;
RELEASEreq....ind BC_BTS_u RELEASErasp_ClOnI
RELEASEreq,Jnd OC_BC
u BTS_u HOC_i
BCcss:BC
c{CONNEcTresp: cont]
Be_HO RELEASErasp_Com
(CONNECTreq.)nd] [ CONNECTrup_COflI,
HOC_o
RELEASENCI-Ind BC_BTS_I RELEASErasp_oonf
[CONNECTfeq.,.ind] C [CONNEcTresp_conl]
I BTS_I AELEASEAMLind 8 _LE RELEASEresp_coof
LE
MSCP
MSCP
LE
Figure A-11: Block type CSS
For exclusive use within KPN and TUE
A-9
Development of a generic model for handover in UMTS R&D-SV-96-771
MSCP MSCP SIM
Block Type Access 1(1)
.-----
I "\
L____.J
HD_BTS_ HD_BTS_u HO_LE LE_HD
["..CP_IllSI) [lBTS_MSCPl]
HO_CONTROLAls,uxln'l
STS)
HO_INIT_lIE SILO 1
USER_TCCN
+---'
[lMSCP_ers)]
CSS
+---'
[IMOCP_CSSI) [(CSS_MSCPl]
MSCP
+---'
[(ACUn_Corel]
["''''''__MI)
MT
+----'
[(CS'_Mn) [I",_CSSI)
SIM
--i
[lcss_sm_datal]
(AESOURCE_INFOr9Q...ind]
(TCCN_UpdaIlI)
rSHRN_HO]USER SHRN'/
USER
j HO SHRN HO/ 5_1 BTS_u
LE_o LE_
SIM HD TCCN
1 rSHRNIMp__ HO SHAN
SHRN_i
HD;
TCCN_o
TCCN_HD -I TCCNcas:TCCN
SHAN_o
TCCN_1
HO INIT_REO'"P_eonf]
HD_o
MT
SHRN'vcUI'l\:l HD_MT
MT_o
[RESOUACE..lNFOntIlp_con'l
MT
-(SHRNFOl) OOnl -
HI HD MT_i
HOcss:HO
[He INIT_ReOr*l_II'ld.]
SHANreIlp_conl
HI BTS1_HD HD HUPN
BTS_U HI_HD
HUPN_o
HD;
HI 8T52 HO HI_HD
HUPN_HD I HUPNcss:HUP
8T5_1 HUPN_i HD_o
HOC 0 HOC i
(SERVICE_DATA'''$UlOll1]
HD_:1
lHOC HD
[1"tCU:ONTAOlt.CL [l-iCU X)NTAOLrtISp_conl]
[SET BRIDGErltl4Uonl.
swrfCi"l CONNnt colli.
nV_1 [ADO CONNte$p coni, ]
SBe_HOC nv_ DAOP_CONNreBP_conI HOC_CMC
CSS CMCj
[SET BRIDGErIlq_Ind. ]
SBC_i
SWlfCl-l CONN incl., CMC_HOC
HOC_Sec
CSS SBC_o
CMC_o
MT_o
[CONNECTTeILmd]
HOC_BC
HOCcss:HOC
RELEASEreq_;nd
CSS BC_o
Be_HOC
[
CONNECT
retP_<;llI1I]
RElEASErtISp_OOI'"
CSS BC_1
MT HOC
MT_i
oW. J .
_oW
CSS
CSS
MT
MT
Figure A-12: Block type Mobile Service Control Point (MSCP)(Access)
B-ISDN
A-10
Block BISON
EJ
1(1)
.----....
I
L ____ J
[(BISDN_MTll
MT_MSCP
[(MT_BISDN
MT
[(BISDN_RAS.1l MSCP2_MSCP l(RAS_BISDNl
CSS2
LElevel1 :LElevel
[(BISDN_RAS)] MSCP1_MSCP l<RAS_BISDNl
CSS1
Figure A-13: Block view B-ISDN
For exclusive use within KPN and TUE
R&D-SV-96-771 Appendix A Formulated SOL specifications
Block Types
Block Type L8evel 1(1)
... ---...
I
EJD
L ____.J
MT
[(MT_BISONl]
[(RAS_BISON)]
t----i
[(RAS_BISONl]
[IBlSON_MTl]
MT_MSCP
[IMT_BISON)]
MT MT
[ICore_AccesS)]
MSCP2 MSCP [IAccess_co'el
MSCP:Core
CSS2 CSS2
[(Core_AccesS)]
MSCP1_MSCP [(Access_Co,e)
CSS1 CSS1
LE
[(LE_MSCP)]
MSCP_LE
[IMSCP_lE)]
[llE_CSSI] CSS2_LE [ICSUEI]
MSCP
CSS2 CSS2
[llE_CSS)]
CSS1_LE [(CSUEI] LE1:LE
CSS1 CSS1
[IBISDN_MTl]
[(BISON_RAS)]
[IBISON_RAS)]
Figure A-14: Block type Local Exchange (LE) level
MSCP MSCP MSCP MSCP
CSS2
CSS1
Block Type LE [SET BRIDGE,
]
CONNECTresp_conf] 1(1)
SWITCH CONNr. RElEASEresp_conf
,..----
RELEASE_BAlOG re5P_conf
I ut L ____.J
CSS1
+---l
[llUSSl] HOC_SBC SBC_HOC HOC_BC BC_HOC
[(CSUEl]
CSS2
+---l
[llE_CSSl]
MSCF
[ICSUEI]
+---l
[(lU'SCPl]
eWITCH CONN"'Lind, ] [CONNECTrect.,.ind
SET BRIDGEr ind, RELEASErecvnd
[<MSCP_lEI)
(CONNECTrect.,.ind]
HOC_i
coni]
RELEASEreq..Jnd
ElEASEresp3xrl
Be_CSS1
/HOC i HOC:), CSS1
BCle:BC
(CONNECTresp_conf]
SBCle:SBC
RELEASEr8lL,nd
RELEASEresp_conf
BC_CSS2
CSS2
"
/
[AOD CONNreq,jnd. ]
HOC_CMC
DROP_CONNr8Cl.ind
SCP
{;OC-' "-
[ADD CONNresp conf, ]
CMCle:CMC
ORO'P_CONNr.sP_oonf
CMC_HOC
HOC_D
SCP
"
/
M
M
Figure A-15: Block type LE
For exclusive use within KPN and TUE
A-11
Development of a generic model for handover in UMTS R&D-SV-96-771
CSS1 CSS2 CSS1 CSS2
CSSCHOC
[HO_CONTROl ..]
LE 1----------------lI SBC_i
1(1)
'I:- -:- MT
HOCIe:HOC
LE
Block Type Core
CSS1 L -'
[IC""'__"I]
[1-.._ca'I]
CSS2
[IC""'__"I]
[I-"_C""'I]
MT
[IBls",,-",n]
[IMUISDNI]
[IMSCP_LEI)
SWITCH 1
iJE-------------1MT
HOC_BC
[
cONNECTreqjnd,]
RElEASEreqjnd
BC_HOC
[
CONNEcrre'P_oonI,]
RElEASEasp_coof
LE LE
Figure A-16: Block type MSCP(Core)
Process View
Process Type BC
.-----
I
L ____ .J
BTS_u
[CONNECTreq.".ind'l
RElEASEreqjnd
[CONNECTresp_COnf]
RElEASEresp_cont
BTS_I
[CONNECTr9Q.,.ind]
RELEASEreq..,.ind
[CONNECTresp_COnf]
RElEASEresp_conf
CSSl
[CONNECTresp_cont]
RELEASEresp_cont
[CONNECTreQ..,.ind]
RELEASEreQ....lnd
CSS2
COnf]
RElEASEresp_Conf
CONNECTr8Q....ind]
RELEASEreq...ind
HOC_
[CONNEcTreQ....ind.]
RELEASEreq...Jnd
HOC_o
[CONNECTresp_conf]
RELEASEresp_conf
LE
[CONNECTre<t,.ind]
RElEASEr9lL'nd
[CONNECTresp_COnf.]
AElEASEresp_conf
1(2)
Figure A-17: Bearer Control (BC) process
A-12 For exclusive use within KPN and TUE
R&D-SV-96-771
Process Type Be
.----""'"
I '" L .J
Appendix A Formulated SDL specifications
2(2)
Figure A-18: BC process (continuation)
Process Type CMC
r - - - ~
I ~
L J
1(1)
NrecUnd(new,old)
Figure A-19: Combining and Multicasting Control (CMC) process
For exclusive use within KPN and TUE
A-13
Development of a generic model for handover in UMTS R&D-SV-96-771
HLo
Process Type He
,-----.
I
L .J
Figure A-20: Handover Control (He) process
1(1)
Process Type HD
.-----
I '"
SHRN_i
L ____.J
[SHRNteqjnd]
HOC_o
[HO_CoNTRoLre<Und]
HI_HD
[HO_INIT_AEQreSP_cOflf]
[HO INIT_REQreqjnd]
SHRNresp_conf
LE_o
[ HO_CONTROLtecLind]
BTS_u
[HO lN1T_REQresp_conf.]
SHRNreqjnd
BTSJ
[HO
LE_i
SHRNreQ...md
[Ho_CONTROLresp_conf]
TCCN_o
[AESOURCE_INF01"eQj nd]
TCCN_i
[RESOURCE_INFOresP_cont)
HUPN_o
[SERVICE_DATAr&q_ind)
HUPN_i
[SERVICE_DATAresp_conl]
SHRN_o
[SHRNresp_COnf]
MT_o
[HO INIT_REOresp_conf]
SHANreqjnd
HOC_i
[HO_CONTROLresp_con,]
MT_i
[HO tNIT_REOreQjnd'l
SHRNresp_conl
1(2)
A-14
Figure A-21: Handover Decision (HD) process
For exclusive use within KPN and TUE
R&D-SV-96-771
Process Type HD
i - - - ~
L .J
Appendix A Formulated SOL specifications
2(2)
OrO<l-ind(new,old,TypeOIHO,hoip)
Figure A-22: HD process (continuation)
For exclusive use within KPN and TUE
A-15
Development of a generic model for handover in UMTS
Process Type HI
r----
SHRU
I "I
-
MEF_i
Hisiave
[UNtCOUAl_REPOR
HUPU_i
[USER_DATAresp_conf]
HUPU_o
[USER_DATAreq..Jnd]
SHRU_o
(sHRuresp_coot)
_0
[HO_CRITERIAreq..Jnd]
R&D-SV-96-771
1(3)
_REPORT(8TSnew,BTSoId)
[
ini configuration,]
___HO,
ho_type
[CAND_lIST_REPORT]
[
HO_CAITERIAnHlP_conf] HC_i
inCconfiguration_slave
A-16
[HO INIT_REQf8lLind]
[HO ]
ess SHRNresp_cool
'OI_configuration_slave
[HO
SHRNr6ClJnd
[HO .]
eSS1 [HQ INrT_REOreq_ind] HQ- cOnI.
SHRNresp_conl
_
inU:onfiguration_slaV'e
[HO IN1T_REoresp_oont.]
SHRNreq..-ind
eSS2 [HO INIT_REareqjnd]
[HO ]
SHRNresp_conf
HO::::tNIT1ATlON]NDresp_conf.
inLconfiguration_slave
[HO INIT_REQreSP_cool]
SHRNreqjnd
HI_o
[HO_COMPLETE,e<tJnd' ] [HO_COMPL _ind, ]
HO_COMPL 3001,
HO INITIAl ect..ind.
H9:::'INIT1ATION::::INDresp_eonf, HO::::lNtTlAT _ reIP_oonf,
in13onfiguration_slave ini_configuration_slave
HO_COMPLETEl$Q..ind,
HO_INITIATION_INDre5P30nt,
u
Figure A-23: Handover Initiation (HI) process
For exclusive use within KPN and TUE
R&D-SV-96-771
Process Type HI
r---"""
I Uj
L .J
mo,no,mi,ni
Appendix A Formulated SOL specifications
2(3)
_REPOAT(BTSold,iniproc)
Figure A-24: HI process (continuation)
For exclusive use within KPN and rUE
A-17
Development of a generic model for handover in UMTS
Process Type HI
.-----
I "I
L .J
,-------
J a . ~ n r r - - - - -
L
Figure A-25: HI process (continuation)
-,NOrund
R&D-SV-96-771
3(3)
A-18 For exclusive use within KPN and TUE
R&D-SV-96-771 Appendix A Formulated SOL specifications
1(1)
aSoflHO
aSeamHardHO
a
HD_'
[HO_CONTROl""Lind]
HD_o
[HO_CONTROL""P_Conf)
BC_o
[SWITCH Ind. I
SeT BRiDGErs Ind,
RELEASE_BRIShEreqjnd
SBC j
[SWITCH CONNresp_conf. ]
SeT BRIDGEres conI.
CMC_i
eoo CONNresp coni, ]
DRO"P_CONNresp_conf
MC_o
[ADO CONNreq indo ]
ORO'P_CONNreqjnd
MT_i
[ADO CONN,.sp conf. ]
DRO"J) CONNresp conf.
SET EmIDGEresp-conI,
SWITCH CONNJe- conI,
RELEASE_BR,OOrtiSP30nf
MT_
[ADD ]
DROP CONNreqJnd.
SWITCH CONNreq indo
SET BRIDGEre ind,
RElOASE_BRIO'hE""L"d
Process Type HOC
L .J
SS,_ [HO_CONTAOlresp_conf]
SS2_ [HO_CONTROlr.sp_conf]
CSS, . [HO_CONTROl",,,.Jnd]
CSS2 i [HO_CONTROL'....Jnd]
C_o [CONNECTreq,.ind,]
RELEASEreCLmd
BCJ rCONNECTresp_conf,]
lRELEASEresp_conf
Figure A-26: HandOver Control (HOC) process
Process Type HUPN
r---"'"
I
L J
1(1)
HD i
- [SERVICE_DATAre<und]
HD_
[SERVICE_DATAresp_conf]
Figure A-27: Handover User Profile - Network (HUPN) process
For exclusive use within KPN and TUE
A-19
Development of a generic model for handover in UMTS R&D-SV-96-771
Process Type HUPU 1(1)
.----""'
. ~
L ____J
HI_o
[ USER_DATAresp_cont]
HU
[USER_DATAreQ...ind]
[ USER_DATAresp_conf]
[ USER_DATAresp_cont]
[ USER_DATAresp_cont]
[USER_DATAresp_cont]
[USER_DATAreqjnd]
Figure A-28: Handover User Profile - User (HUPU) process
1(1)
REPORT(BTSoId.inllroc)
Process Type MEF
.-----
I ~
L____ .J
USER
-
[MEF_UPdate]
HI_o
[LINK_QUAL_REPORT]
BTSI
[ LINK_QUAL_REPORT]
nO,mo,mi,ni
bts
BTS2
[L1NK_OUAL_REPORT]
BTS3_
[L1NK_QUAL_REPORT]
BTS4
-
[L1NK_QUAL_REPORT]
Figure A-29: MEasurement Function (MEF) process
A-20 For exclusive use within KPN and TUE
R&D-SV-96-771
Process Type ABC
MT
I
[CONNECTresp_conf]
RELEASEresp_conf
CSS
[CONNECT,,,,,,,,,,,]
RElEASEreqjnd
[CONNECTresp conf.]
RELEASEre5P_Conf
BTS
[CONNECTresp conf]
RElEASEresp3:onf
RELEASEreQ...ind
BTS
(CONNECTre8P_c:on,]
RELEASEresp)::onf
RELEASErecUnd
BTS
RELEASEreBP_conf
[CONNECr,eq",.ind]
RELEASEreq,jnd
BT
[CONNECTresp_conf]
RElEASEresp_conf
[CONNECTr9Q..,.ind]
RELEASEreq....1nd
Appendix A Formulated SOL specifications
1(1 )
new Integer.
ind(04d,tg)
_conf
Figure A-30: Radio Bearer Control (RBC) process
HOCj
Process Type SSC
.----....
.
L .J
[
SET_BRIDGEreQ.jnd, ]
SWITCH CONNre ind,
AIDGEffi'l-ind(new,old)
1(1)
Figure A-31: Switching and Bridging Control (SBC) process
For exclusive use within KPN and TUE
A-21
Development of a generic model for handover in UMTS R&D-SV-96-771
Process Type SHRN
I
L J
1(1)
Figure A-32: Special Handover Request - Network (SHRN) process
1(1)
bts
oip,NewBaseStationIO,OldBaseSlationID)
Process Type SHRU
1----"'"
I L .J
HU
BTS
[ SHRUrecLind]
[SHAuresp_cont]
BTS
[
[sHRuresp_COnf)
BTS
[SHAureq_ind)
[SHRuresp_conf]
BTS
[SHRUflJrLind]
[SHRuresP_COnf]
Figure A-33: Special Handover Request - User (SHRU) process
A-22 For exclusive use within KPN and TUE
R&D-SV-96-771 Appendix A Formulated SOL specifications
Process Type TCCN
,----"'"
I
L .J
USER_
__-I [TCCN_uPdate]
HD_i
__-I [RESOURCE_INForeq_ind]
1(1)
Figure A-34: Target Cells and Connections - Network (TCCN) process
Process Type TCCU
HI_o L .J
_REPORT)
lTCCu_uPdate)
-[CAND_LlST_REPORT]
BTS -tCAND_L1ST_REPORT)
BTS fcAND_L1ST_REPORT]
BTS -tCAND"""' ...T"_=...........
bts
1(1}
Figure A-35: Target Cells and Connections - User (TCCU) process
For exclusive use within KPN and rUE
A-23
Development of a generic model for handover in UMTS
Procedure View
HDprocess
Procedure HOcalculation
I. .J
1. _
1C'a1Cu18fKmS -
I
I
---------------------
1.
3,4
ind(new,oId,lg,TypeOfHO)
TAre'l..ind
R&D-SV-96-771
1(1)
HI process
Figure A-36: Procedure HO calculation
Procedure Hisiave
r----
I 1. .1
1(1)
A-24
Figure A-37: Procedure Hlslave
For exclusive use within KPN and TUE
R&D-SV-96-771
Procedure HI_HandoverDecision
L .J
Appendix A Formulated SOL specifications
1(1)
mt,bothml
3,4
QreILind(BTSnew.BTSold,TypeOfHO,hoip)
Figure A-38: Procedure HLHandoverDecision
HOC process
Procedure NonSeamHardHO
liN/OUT new
J
Figure A-39: Procedure NonSeamHardHO
For exclusive use within KPN and TUE
1(1)
A-25
Development of a generic model for handover in UMTS R&D-SV-96-771
Procedure SeamHardHO
"'I"A'!l---- ....
liN/OUT new
1(1)
Figure A-40: Procedure SeamHardHO
Procedure SoftHO
liN/OUT new
J
req_ind(new,old)
1(1)
A-26
Figure A-41: Procedure SoftHO
For exclusive use within KPN and TUE
Appendix B : MESSAGE SEQUENCE CHARTS
As examples of the message flows between entities, needed during particular
handover scenarios, three Message Sequence Charts (MSCs) are shown. These
MSCs are constructed using the simulator tool of SDT.
Ii
I
"
-
I
- -
Q
t
i
W Ii
i
E,
!
.-
r
!
" "
E
d ..
f
r
Ii
i'
l
f
0;:;'" 0;:;'" 0;:;'" 0;:;'"
f t .::.. .::.. .::.. .::..
-...
:::..
.:::..
g
':-'
g
2
E
!
.. E,
R
g
'5
I
"
.- 2
E (l,
T
d
p
5
I
"
.-
i
2
"
I
- -
t::..
In
i !
."..
"
Ii
- -
z
if
0 5
j
/
"
"
E,
i,
!'
2' !,
z 0
2'
"
z
u
.,...
j
!
f "
.::..
i
d
1:'
-, .
0
2 "
IT
T :L'
Figure B-1: The HI in both MTand network, SHRN, inter BTS, soft handover scenario
For exclusive use within KPN and TUE
B-1
OJ
,
I\)
I
c::
ca
OJ
;1
ltl
s
s:
,"'"'I
(J)
15
,c:
s
(j)
..,
OJ
,Cri
::J
0
::J
."
I
C1l
0 ltl
..,
0)
(l)
:3
><
iD
0
2
C1l
is
;;;:.
(l) ::J
c::
g.
l/)
Ci5 (l)
..,
C1l
-
@
::r
::J
:;.
0)
'"
5
"'tJ
<=
0)
::J
Q..
'""i
c:
rn
MSC process TeCUml process HUPUmt process SHRUm! process HDcss process HUPNcss process TCCNcss process HOCcS$ process BCess process RBCbts process RBCmt process SBCcss process seemt process RBCbls
.----j,
erw 0 r HI"" TCCUmt HUPUmf I SHRUml HDcssl HUPNcssl TCCNcssl I HOCcssl BCcssl 1 ABCbts2 ABCmtl SBCcssl SBCmtl RBCbls1
I
enerated by lni_conflguration
Simulat", [MT
[2.1.MT
TCCU_update
C NO_LIST_REPO [2.1]
USER_OATAre tnd
U EA_DATAresp_c
[MT. 2. 1] SHRU_HO
SHRUreq".Jnd
[2.1]
[nonsellm
ho_type
[2. nonS8ll1m, MTl
_INIT_REQreq) d
SERVICE_DATA q..tnd
SER CE_OATAresp_c
RESOURCEJN r9CI-ind
[2 ]
TCCN_update
RESOU CE_INFOtesp_c
"'[ 2]
[2.1 'CSS', nonseem] HO_CONTROLr fUnd
[2,'CSSJ
CONNECTreq...!
[2. 'BT$' CONNECTre<U
[2. 'MT'
OONNECTreq.J
poNNECTresp_c
ONNECTre.,u
ONNECTresp_c rtf
[2.1 SWITCH_CONN CLind
SWI H_CONNresp_c
[2.1 SWITCH_CONN qjnd
SWI H_CONNresp_c f
[1,'CSS') AELEASEreqjn
I
1,,'8TS- RELEASEreq_1
1
'
M
T'J
ELEASEreq..-ind
LEASEresp_conf
RELEASEr9SP_c
RELEASEresp_c
HO p>NTROLresp_c III
HO_IN _REQresp_conf
RUresp_con1
C)
(l)
<::
(l)
0-
"b
:3
(l)
::J
-
o
.....
0)
<0
(l)
::J
(l)
..,
O
:3
o
Q..
(l)
-
0'
..,
::r
0)
::3
Q..
o
<::
(l)
..,
:;.
c:
s:
Cri
::D
l20
o
,
CIJ
<
I
CO
0>
,
.....
.....
....
___--' L- ._._J I. .__ L__.__ _ ____ I I
process HDcss ptOO8fIS HUPNcu ptoCelI6 TCCNc;es process HOCIe
TCCNcss1 I i HOCIe
:D
Ro
Cl
I
en
<
I
co
0)
I
-...I
-...I
......
s:
(l)
CIl
CIl
\l)
<Q
(l)
C/)
(l)
.Q
c::
(l)
::J
o
(l)
()
:::r
\l)
...
(;j
:J>
"C
"C
CD
:::I
a.
><
lD
process8CC8S prooe.RBCbtI
iElEASEresp.
[2.'''')
___.L-----I__J
RdLEASEre"UlllO'
pIOCeS$ sec.. plOCfISS SBCmI
SBCmI
IDGENsp_oonf
RElEASE_ RIDGEre"uxmI
proens BC<:ss process RBCbIs prooea, RBCmt
I ABCbb3 I I RBCn1
"""",SClo
---.c;;
RELEASEreq..,.
[2. 'LECSS'J 1RELEASEreq...Jr
rLEASeretlp_
(3.2) ITCH_CONNreq 100
[3, 2] AELEASE....BR Ereq...Jnd
(3.2) LEASE...BRIOGE lnd
[HE)
[ 3)
[Wl"
HO.t::ONTR0L.Iesp3
RfsouIK:E_INfOr..
SEAVlCE_OATAIeq_lnc:I
SER\fcE_DATAresp_c
.2, 'lE', seam) rHO_CONTROlrt.Jnd
HO_INILREOre9p_COl'lI
PIOCeSSHCb!s
HOJCRITEAlAresp_
uNKtauAL..AEPORT12, !'RII)
TCCUrnl proce. HUPUml proous MEFbls PfOC"lI MEFmt
TCCUmI I i MEFblS2 I i MEFml
HC_CRITERtAMJnd
(3)
Il3, 2. seam, 8T1
(MT.2. maJ MEF_updIIIe
utEfLDATAresp_
MSC
,-----
iSImUlallonlJ
[.TS)
.2.
"11
0
...
OJ
I
;i
C!)
s
OJ
:::::.:
C!)
(j)'
s
CD
...
Jf)
C/)
C!)
III
:3
CD
C/)
C/)
:::J
&
(
...
C!)
:::J
III
5'
I
OJ
I
W