A Flexible Control Architecture for the UMTS Mobile Terminal
Transcript of A Flexible Control Architecture for the UMTS Mobile Terminal
A Flexible Control Architecturefor the UMTS Mobile Terminal
Michael Gerard Barry
A thesis submitted in fulfilment of the
requirements for the degree of
Master of Engineering.
UNIVERSITY of LIMERICK 1998
Declaration
Title: A Flexible Control Architecture for the UMTS Mobile Terminal.
Author: Michael Barry.
Award: Master of Engineering.
Supervisor: Dr. John Nelson.
I hereby declare that this thesis is entirely my own work, and does not contain material previously pub-
lished by any other author, except where due reference or acknowledgement has been made. Furthermore,
I declare that it has not previously been submitted for any other academic award.
Michael Gerard Barry
November 27 1998
Abstract
Control Architectures for an Advanced Mobile Terminal
Michael Gerard Barry
As mobile telecommunications systems evolve globally, to keep pace with rapid changes in technolog-ical and regulatory systems, the role of the Mobile Terminal (MT) in such systems is constantly changingto reflect the complexity and range of services offered. This thesis examines the role the MT has to play inthe control architecture of a mobile network.
Initially the role of the MT in second generation systems, such as the Global System for Mobile Com-munications (GSM) and the Digital Enhanced Cordless Telecommunications (DECT) system is considered.Second generation systems such as GSM and DECT are intended for deployment in a limited number ofusage environments and as such do not require flexible control architectures. As third generation mobilesystems evolve, they must be flexible and adaptive in order to provide support for terminal and user mobility;to be suitable for deployment in a range of differing environments; as well as catering for the requirementsof a number of differing air interface techniques and diverse services.
These requirements for a flexible system control architecture are reflected in the MT through the use ofIntelligent Network (IN) techniques, the support of advanced call and bearer protocols and functionality tocater for the freedom of allocation of functionality in the system. The use of radio independent functionsand protocols in the terminal allows a great deal of flexibility in the MT’s control architecture. The impactof Software Radio is also considered.
A flexible terminal architecture incorporating radio independent and dependent element has been de-veloped and a radio independent/radio dependent interface identified. Furthermore a control/transport splithas been applied and the resulting system partitioned into system control and transport control parts. Theeffect of these divisions is to produce an open flexible architecture, within which each terminal function andinterface can be clearly identified and manipulated.
A functional model suitable for a 3rd generation mobile terminal control architecture is developed usingSDL. As well as incorporating the functional requirements of the MT, the non functional requirementsof the MT are identified and SDL model is extended to cater for these also. The use of object orienteddesign methodologies and the SDL language means that the non functional requirements of the MT can beintegrated seamlessly into the MT architecture. This allows the same MT model to be retained during theanalysis, design and implementation stages.
Acknowledgements
Sincere thanks to my supervisor John Nelson for his help, support encouragement and patience over the
last few years.
Special thanks to Gary Fleming and Liam Gray, my co-conspirators in Rainbow in UL for advice,
discussion and cigarette breaks. Thanks also to the TRC lab in UL: Daire, Conor, Sean, Ivan, Mark, Edwin,
Setphen, Martin, Dave, Kevin and Tom.
I would also like to thank the participants in the ACTS Rainbow project, particularly the RAP1ers; Elio,
Enrico, Michele, Stefano, Lauret, Jean, Amre, Andre, Vincent, Nikos and the SNLers; Alex, Oliver and
Michael. Honourable mentions to Ermanno, Johan, Bernard, Saidi, Flavio, Patrick, Caren and Nadege
Special thanks to Daniel, Adrian, Donogh and Darren for beer and holidays.
Finally I would like to thank my family; my parents Ger and Anne and my sister and brothers Noelle,
Mark and Edward for their constant support
This thesis is dedicated to my parents Anne and Gerard.
Contents
1 Introduction 1
1.1 Summary of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Development of Mobile Systems 7
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 First generation systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 2nd generation systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 GSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 The GSM Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 The Future of GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 DECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 DECT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 DECT PP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.3 Medium Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.4 Future trends in DECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Third Generation mobile Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Requirements of third Generation Mobile Systems . . . . . . . . . . . . . . . . . 22
2.5.2 Universal Mobile Telecommunications System . . . . . . . . . . . . . . . . . . . 24
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 A Flexible Architecture for UMTS 27
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Network Transport Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 B-ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 B-ISDN and UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 UMTS requirements on B-ISDN signalling . . . . . . . . . . . . . . . . . . . . . 31
3.3 Advanced Service Provision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
i
ii CONTENTS
3.3.1 IN and UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2 IN Functional Model Enhancement for UMTS . . . . . . . . . . . . . . . . . . . 37
3.4 Support for multiple Air Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 Access Network Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.2 Core Network Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3 A unifying view and common interface . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.4 Generic UMTS Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Mobile Terminal Functions in UMTS 49
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 MT Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Control Plane Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.1 Mobility Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.2 Call Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.3 Handover Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.4 Bearer Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3.5 Transport Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 The UMTS Signalling Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.1 Requirements on Access Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.2 SNL Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.3 The SNL in the Mobile Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.5 Terminal Transport Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.1 Call Setup in the Transport Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.2 Call Setup in the Transport Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5.3 Handover in the Transport Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5 MT Functional Architecture 79
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Monet design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.1 Application of the Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3 Identifying a Radio Independent Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3.1 Defining Radio Independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3.2 Specifying a Radio Independent Interface . . . . . . . . . . . . . . . . . . . . . . 82
5.3.3 Constraints on a Radio Independent/Dependent Boundary . . . . . . . . . . . . . 82
CONTENTS iii
5.4 Control Transport Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.5 Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.5.1 Mobility control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.5.2 Call Control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.5.3 Handover control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5.4 Bearer control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5.5 Transport control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.6 Radio Independence of Terminal Functions . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.6.1 Data Storage in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6 MT Design Aspects 99
6.1 MT Design Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2 OMT as a design methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2.1 Adoption of the Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2.2 SDL Object Modelling Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3 Non Functional Requirements in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4 The FE Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4.1 Rationale for an FE Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4.2 Design Model including the FE Manager . . . . . . . . . . . . . . . . . . . . . . 111
6.4.3 SDL Realisation of the aggregated model . . . . . . . . . . . . . . . . . . . . . . 112
6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7 The MT in other architectures 117
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2 Representing the GSM MT in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2.1 GSM MT Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2.2 Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.3 Representing the DECT PP in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.3.1 DECT PP Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.3.2 Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.4 TINA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.4.1 TINA Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.4.2 Mobility Support in TINA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
iv CONTENTS
7.4.3 The TINA Mobile Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.5 TINA MT Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.6 Emerging Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.6.1 Software Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.6.2 A UMTS MT Software Radio Architecture . . . . . . . . . . . . . . . . . . . . . 137
7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
8 Conclusions 143
8.1 Overall Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.1.1 Flexibility in Mobile Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.1.2 Derivation of the MT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 144
8.1.3 Specification and Design of the MT Architecture . . . . . . . . . . . . . . . . . . 146
8.1.4 Application of the MT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.2.1 Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.2.2 TINA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.2.3 Use of Mobile Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.2.4 Software MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.2.5 Internet MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
References 151
A Intelligent Networks 159
B Specification and Design Language (SDL) 165
C SDL Description of the MT 167
D SDL Description of the MT Mobility Management Group 177
E SDL Description of the LMT FE Manager 249
F SDL Description of the MT SNL 305
G List of publications 329
List of Figures
2.1 GSM Network Architecture [MP92] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 GSM Protocol Architecture [MP92] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 GSM Mobile Station Configuration [MP92] . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 GSM MT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 DECT application areas [EBG96] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 DECT Common Interface Reference Model [ETS95a] . . . . . . . . . . . . . . . . . . . . 16
2.7 DECT Layered Architecture [ETS95a] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 DECT PP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Structure of a DECT Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10 Evolution of Mobile Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 B-ISDN Protocol Reference Model [IT91a] . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 UMTS as Access to B-ISDN [Del95d] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Integrated UMTS and BISDN with UMS [Del95d] . . . . . . . . . . . . . . . . . . . . . 33
3.4 Call Control Entities in a Fixed-Mobile call . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 UMTS Architecture, UMS in Core and Access [Del95d] . . . . . . . . . . . . . . . . . . 35
3.6 IN Functional Plane for UMTS [NA696] . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 UMTS Network Architecture [BCM+97] . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8 UMTS - Generic Radio Access Network view [ETS96] . . . . . . . . . . . . . . . . . . . 40
3.9 UMTS - CORE Network view [BCM+97] . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.10 Identifying a common access/core interface [BCM+97] . . . . . . . . . . . . . . . . . . . 43
3.11 Radio Independence in the GRAN [BCM+97] . . . . . . . . . . . . . . . . . . . . . . . . 44
3.12 Generic UMTS Architecture [BCDH96] . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.13 UMTS Network Architecture [Del96b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.14 Radio Independent/Radio Dependent Division in UMTS Access Network . . . . . . . . . 46
4.1 MT Control and Transport Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Control Plane groupings in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
v
vi LIST OF FIGURES
4.3 Information flow for Session Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 User Registration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Location Update Information Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Domain Update Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Call and Bearer Setup in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.8 Call, Connection and Bearer Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.9 Handover Initiation in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.10 Handover Execution in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.11 A modified IN DFP for UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.12 Radio Bearer, Radio Channel hierarchy in the MT . . . . . . . . . . . . . . . . . . . . . . 63
4.13 Setup of a DCCH using the RACH and AGCH . . . . . . . . . . . . . . . . . . . . . . . . 64
4.14 Setup of a radio traffic bearer in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.15 Bearer Setup during Call Setup in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.16 Managing the Transport Plane for Call Setup in the MT . . . . . . . . . . . . . . . . . . . 66
4.17 Call Control and Transport Control during handover . . . . . . . . . . . . . . . . . . . . . 67
4.18 Positioning of the SNL in the MT [ZBGN97] . . . . . . . . . . . . . . . . . . . . . . . . 70
4.19 MT Transport Layers [Del96d] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.20 Overview of the RAL [SFB+97] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.21 MT Control and Transport Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.22 Activation of the transport plane during call setup . . . . . . . . . . . . . . . . . . . . . . 75
4.23 Management of the Transport Plane during Hard handover . . . . . . . . . . . . . . . . . 76
5.1 Monet Design Methodology [Fle94] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2 MT Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3 Mobility control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.4 Associations between Mobility control FEs . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5 Call control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6 Associations between Call control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.7 Handover FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.8 Associations between Handover control FEs . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.9 Bearer control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.10 Associations between Bearer control FEs . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.11 FEs for Transport control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.12 Associations between Transport control FEs . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.13 Radio Independence/Dependence in the MT Architecture . . . . . . . . . . . . . . . . . . 93
5.14 Use of an MTDB in the MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
LIST OF FIGURES vii
5.15 Associations between Mobility Control Objects . . . . . . . . . . . . . . . . . . . . . . . 95
6.1 Object Model for Mobility Control FEs in the MT . . . . . . . . . . . . . . . . . . . . . . 101
6.2 State Machine for the LMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3 Part of the LMT SDL State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.4 SDL description of Mobility Control Objects . . . . . . . . . . . . . . . . . . . . . . . . 106
6.5 Extended LMT State Machine for TCAP interface . . . . . . . . . . . . . . . . . . . . . . 109
6.6 Placement of an FE in the system [BGPR98] . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.7 Inheritance Tree for Mobility Control FE Managers . . . . . . . . . . . . . . . . . . . . . 111
6.8 Object Model for FE State Machines and FE managers for Mobility Control . . . . . . . . 112
6.9 FE Object as an aggregate of FE State Machine and FE Manager Objects . . . . . . . . . . 113
6.10 SDL Block Level view of Mobility Control FEs . . . . . . . . . . . . . . . . . . . . . . . 114
6.11 FE State Machine and FE Manager as SDL processes . . . . . . . . . . . . . . . . . . . . 115
7.1 GSM MT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2 GSM MT Control Plane Groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3 GSM MT Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.4 Bearer Switching in the MT during GSM handover . . . . . . . . . . . . . . . . . . . . . 122
7.5 DECT PP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.6 DECT PP Control Plane Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.7 DECT PP Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.8 Setup of a DECT bearer by the RBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7.9 TINA Architecture [TIN96b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.10 Using UMTS as the underlying Network in TINA [TIN96a] . . . . . . . . . . . . . . . . 129
7.11 control Functions in the TINA MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.12 TINA MT Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.13 Software Radio Architecture [KBW97] . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.14 Software Radio Architecture in the UMTS MT [FDB98] . . . . . . . . . . . . . . . . . . 138
7.15 Radio Dependent part of the MT Software Radio Architecture . . . . . . . . . . . . . . . 140
A.1 IN Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.2 Distributed Functional Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.3 Physical Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
viii LIST OF FIGURES
List of Tables
2.1 Summary of DECT Standards and Data Profiles . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 DECT U-Plane DLC services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Major Identifiers used by Mobility control in the MT . . . . . . . . . . . . . . . . . . . . 52
5.1 Summary of FE characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
ix
Glossary
TD-CDMA Point of Presence
ABR Available Bit Rate
ACTS Advance Communications
Technologies and Services
ADC Analog Digital Converter
AGCH Access Grant Channel
AHN Access Handler Network
AHT Access Handler Terminal
AMPS Advance Mobile Phone
System
AN Authentication Network
ATDMA Advanced TDMA for
Multiple Access
ATM Asynchronous Transfer Mode
AU Authentication User
BCAF Bearer Control Agent Function
BCF Bearer Control Function
BCH Broadcast Control Channel
B-ISDN Broadband Integrated
Services Digital Network
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
CBR Constant Bit Rate
CC Call Control
CCAF Call Control Agent Function
CCF Call Control Function
CDMA Code Division for Multiple
Access
CEPT Conference Europeenne des
Postes et Telecommunications
CLMS Connectionless Messaging
System
CM Communication Management
CMC Combining and Multicasting
Control
CMF Combining and Multicast
Function
CODIT Code Division Testbed
COMS Connection Oriented
Messaging System
C-Plane Control Plane
CSS Cell Site Switch
CT1 Cordless Telephony system 1
CT2 Cordless Telephony system 2
D/A Digital/Analog
D-AMPS Digital AMPS
DARTS Design Real Time Systems
DCCH Dedicated Control Channel
DCS Digital Cellular System
DECT Digital Enhanced Cordless
Telecommunications
DI Domain Identifier
DLC Data Link Control
DPE Distributed processing
Environment
DSP Digital Signal Processor
EDGE Evolved Data for GSM
Evolution
EML-CP Element Management Layer
Connection Performer
ERMES European Radio Message
Exchange System
ETSI European Telecommunications
Institute
EXODUS Experiments on the
LIST OF TABLES xi
Deployment of UMTS
FACCH Fast Associated Control
Channel
FE Functional Entity
FM Functional Model
FP Fixed Part
FPLMTS Future Public Mobile
Telecommunications System
GPRS General Packet radio Services
GRAN Generic Radio Access Network
GSM Global System for Mobile
Communications
HC Handover Criteria
HD Handover Decision
HDN Handover Decision Network
HDU Handover Decision User
HLR Home Location register
HOC Handover Control
HOCA Handover Control Agent
HOI Handover Initiation
HSCSD High Speed Circuit Switched
Data
HUPU Handover User Profile User
IMT200 International Mobile
Telecommunications 2000
IMUI International Mobile User
Identifier
IN Intelligent Network
IP Internet Protocol
IPC Inter Process Communication
ISDN Integrated Services Digital
Network
ISO International Standards
Organisation
ITU International
Telecommunications Union
IWF Interworking Function
IWU Interworking Unit
kTN Kernel Transport Network
LAI Location Area Identifier
LAN Local Area Network
LAPD Link Access Protocol D
LAPDm LAPD Mobile
LC Link Control
LCE Link Control Entity
LE Local Exchange
LMT Location Management Terminal
LNC Layer Network Controller
LUH Location Update Handler
MAC Medium Access Control
MAL Mobility Adaptation Layer
MAL Mobility Adaptation Layer
MBCF Mobile Bearer Control Function
MCCF Mobile Call Control Function
MCF Mobile Control Function
MEF Measurement Environment
Function
MEFA MEF Active
MEFL MEF Location
MEFP MEF Passive
MM Mobility Management
Monet Mobile Networks
MSC Mobile Switching Centre
MSF Mobile Storage Function
MSF Mobile Storage Function
MT Mobile Termination
MT Mobile Terminal
MTDB MT Database
N-ISDN Narrowband ISDN
NMT Nordic Mobile Telephony
NNI Network Network Interface
OAM Operation Administration and
xii LIST OF TABLES
Maintenance
OMT Object Modelling Technique
OSI Open Systems Interconnection
PA Paging Area
PCH Paging Channel
PCN Personal Communications
Network
PHL Physical Layer
P-MR Private Mobile Radio
PE Paging Entity
PP Portable Part
PPP Point to Point Protocol
PRM Protocol Reference Model
PRMA Packet Reservation for Multiple
Access
PSTN Public Switched Telephone
Network
QoS Quality of Service
RACE Research for Advance
Communications in Europe
RACF Radio Associated Control
RACH Random Access Control
Channel
RAINBOW Radio Access Independent
Broadband Over Wireless
RAL Radio Adaptation Layer
RAL Radio Adaptation Layer
RAS Radio Access Subsystem
RBC Radio Bearer Control
RBCF Radio Bearer Control
Function
RC Resource Control
RFP Radio Fixed Part
RHN Registration Handler Network
RHT Registration Handler
Terminal
RLL Radio Lower Layer
RLL Radio Lower Layer
RR Radio Resource
RSVP Resource Reservation
RTD Real Time Data
SAAL Signalling AAL
SACCH Slow Associated Control
Channel
SAL Service Adaptation Layer
SAL Service Adaptation Layer
SAP Service Access Point
SaR Segmentation and Reassembly
SARF Segmentation and
Reassembly Function
SBC Switching and Bridging Control
SBE Signalling Bearer Entity
SCF Service Control Function
SCH Synchronisation Channel
SDCCH Stand-alone Dedicated Control
Channel
SDF Service Data Function
SDL Specification and Description
Language
SDT SDL Design Tool
SHN Session Handler Network
SHRU Special Handover Request
User
SHT Session Handler Terminal
SI Service Identifier
SIM Subscriber Identity Module
SM State Machine
SMS Short Messaging Service
SNL Signalling Network Layer
SNL Signalling Network Layer
SNLC Signalling Network Layer
Control
LIST OF TABLES xiii
SOMT SDL OMT
SRBCF Specialised Resource Bearer
Control Function
SRCE Software Radio Control Entity
SRF Specialised Resource
Function
SS7 Signalling System 7
SSF Service Switching Function
TACAF Terminal Access Control Agent
Function
TBR Technical Basis for
Recommendation
TCAP Transport Control Application
Part
TCCU Target Cells and Connections
for User
TCH Traffic Channel
TCP Transmission Control
Protocol
TCSM Terminal Communication
Session Manager
TDD Time Division Duplex
TDMA Tine Division for Multiple
Access
TE Transit Exchange
TINA Telecommunications Information
Network Architecture
TINA-C TINA Consortium
TMTA Temporary Mobile Terminal
Address
TMTI Temporary Mobile Terminal
Identifier
TN Transport Network
UCC UMTS Call Control
UCCA Call Control Agent
UCCA UMTS Call Control Agent
UDD Unconstrained Delay Data
UMS UMTS Mobility Server
UMTS Universal Mobile
Telecommunications System
UNI User Network Interface
U-Plane User Plane
UPT Universal Personal
Telecommunication
UTRA UMTS Terrestrial Radio
Access
VBR Variable Bit Rate
VLR Visitor Location register
VPN Virtual Private Network
WAN Wide Area Network
xiv LIST OF TABLES
Chapter 1
Introduction
This thesis presents a control architecture for the Mobile Terminal of the Universal Mobile Telecommu-
nications System (UMTS). The Universal Mobile Telecommunication System is a third generation mobile
system being developed in Europe to cater for the needs of mobile users at the turn of the millennium and
beyond. It is required to encompass the numerous different environments currently supported by separate
systems and provide more open and flexible service provision for the mobile user of the future. In addition,
the bandwidth provided by UMTS will be significantly greater than of current systems. Recent studies in
Europe, both by the European Telecommunications Standards Institute (ETSI) and as part of the European
Union’s ACTS and RACE programs, have investigated radio solutions capable of providing services at two
megabits per second. Coupled with this, the UMTS system must also provide backwards compatibility with
the existing, deployed 2nd generation systems, most particularly GSM, from which UMTS is expected to
evolve.
Within this thesis, a flexible control architecture for the UMTS mobile terminal is developed. The
mobile terminal is a core part of any mobile telecommunications system. It acts as a point of contact for the
user and is involved in every major system procedure. However research into mobile communications has
tended to concentrate mainly on the air interface and on the fixed network part of UMTS with the aim of
extending the service and data capacity offered by these parts of the system. This thesis aims to apply many
of the concepts developed for UMTS to the MT and to show that these can be used to provide a flexible
architecture for the MT, capable of supporting any radio access technology and of providing a wide range
of data services. This project contributed to work of the ACTS Rainbow project investigating architectural
and design aspects of the UMTS Access Network.
Initially the requirements and application areas for UMTS are presented. Existing second generation
mobile systems, such as DECT and GSM, are widely used. However they are each limited to a small range
of deployed environments and only provide limited bandwidth for the support of multimedia services. While
these technologies will continue to evolve they are not expected to provide more than 640kBit/s before the
1
turn of the millennium and for GSM at least, the provision of services other than voice and messaging is
leading to a significant reorganisation of both the GSM fixed network and the GSM radio interface. Also, the
different second generation technologies are incompatible with each other. This has led to the introduction
of dual mode and even tri mode phones to enable users to use the same terminal in different environments.
The requirements on UMTS include the support of data services up to 2Mbit/s; to allow the MT to be
used anywhere, in the home, the office or the public environment, both rural or urban. Furthermore UMTS
should be an open ended system allowing the easy introduction of new technologies and facilities. Right
from the start UMTS must be a flexible open system capable of supporting a wide range of existing and
innovative air interfaces capable of offering both voice and data services to users in any location.
Three major concepts and technologies for designing flexibility into UMTS are identified. This thesis
firstly shows how B-ISDN architectures and technology can be exploited in UMTS to provide wideband
multimedia data services. Secondly, the adoption of IN techniques provides a platform for the development
and deployment of UMTS services, to cater for the mobility of the user and the terminal. Neither B-ISDN
nor IN can be directly applied to UMTS. A set of requirements on B-ISDN and IN to cater for mobility are
identified.
Thirdly, a clear boundary between the core and the access networks in the UMTS network architecture
is identified. This allows for the support of many different access networks, each supporting a different
radio access system. The UMTS access network can then itself be split into radio independent and radio
dependent parts. The radio independent part of the access network provides generic system functions, such
as call control and mobility management and can be applied over any radio access technology. The radio
dependent part is closer to the edge of the access network and its functions and behaviour will be different
for each radio access technology. Network architectures, incorporating both B-ISDN and IN technology
and utilising both a core network/access network division and a radio independent/radio dependent division
are presented for the intended application environments of UMTS.
Following this, the focus of the thesis shifts to the UMTS mobile terminal. The UMTS MT provides
access to the system for the UMTS user and is involved in every major UMTS procedure, call setup and
management, handover procedures, bearer setup, mobility management and the manipulation of user plane
data. The MT consists of a control plane and a transport plane. The control plane functions include call
control, mobility control, handover control, bearer control and transport control. Together these provide a
flexible and adaptive set of functions to cater for the manipulation of call, bearers and services in the UMTS
system.
The transport plane in the MT provides data manipulation functions, grouped based on whether they
act on data according to radio, mobility or service considerations. The transport plane is layered. This
enforces separation between the various transport functions and serves to abstract the higher layer service
dependent functions from the mobility and radio related functions provided by the lower layers. To cater for
the communication requirements of functions in the control plane a Signalling Network Layer is proposed
2
for use in UMTS. The SNL provides for the transport of control plane messages between the MT and the
network, while abstracting the control planer functions away for any transport consideration due to the
movement of the MT in the system.
The RACE Monet Methodology is used to derive functional elements for the MT control plane. A
control/transport split is also used both to separate the control and transport planes and to identify those
FEs in the control plane most closely related to transport. Within the MT functional architecture directed
associations between the FEs are identified to facilitate more detailed design and implementation of the
MT. The MT architecture is analysed for radio independence. A radio dependent/independent boundary is
identified separating the radio independent FEs from the radio dependent ones.
A variation of the Object Modelling Technique (OMT); SDL OMT (SOMT) is adopted as the design
methodology for the MT. SOMT combines three separate views in the modelling of a system; the object
model, the dynamic model and the functional model. The object model and the functional model can be
derived from the functional architecture and the functional description of the UMTS control procedures.
The dynamic view of the system is modelled using the ITU’s Specification and Description Language
(SDL) which is used to describe the dynamic behaviour of the MT FEs as a set of interacting extended
finite state machines.
Having derived the basis for a model of the functional aspects of the MT, the MT design is further
extended to envelop the non functional requirements of the system from a control viewpoint. The non func-
tional requirements of the MT are those functions which are necessary for the implementation of the MT
but which do not have any major impact on the control related design of the MT. These include: interfacing
with system management, handling of node internal FE relationships and the implementation oriented as-
pects involved with interfacing with the transport plane. A SDL model catering for both functional and non
functional requirements of the MT is derived using SOMT.
Finally, the MT architecture is applied to existing and proposed telecommunications architectures. The
reasons for this are two fold, to prove that the MT is capable of supporting a number of different radio
access systems and also to prove that the design of the MT is open, adaptive and robust and able to cater for
the introduction of new technologies into the UMTS system. Initially the MT architecture is applied to the
GSM MT and the DECT PP to prove that the MT architecture is compliant with a radio independent/radio
dependent split and can be applied to different radio systems. Differences do arise in the MT architectures
for DECT and GSM. These are due to the overall behaviour of the individual systems and not any particular
radio aspects. These differences and their impact on the MT architectures are detailed.
The Telecommunications Information Networking Architecture (TINA) architecture has been developed
to provide a software architecture which is flexible so as to be applicable to a wide range of technologies and
modular enough to enable the reuse of components. As such it has similarities to the developed MT model,
including a control transport division and a rudimentary radio independent/radio dependent division. The
role and functions of the TINA MT are compared and contrasted with those of the UMTS MT developed
3
in this thesis. The UMTS MT is then analysed for its capability to cater for software radio, a new and
innovative technology in mobile telecommunications.
1.1 Summary of Thesis
Chapter 2 presents the necessary background on mobile systems and on UMTS. It describes the architec-
tures and application areas of existing second generation systems focusing on GSM and DECT. Following
this the requirements and application areas of UMTS are identified and an evolutionary path from existing
systems towards UMTS is presented.
Chapter 3 focuses on flexibility in the UMTS system. It shows how B-ISDN and IN can be utilised
in UMTS. Requirements placed on IN and B-ISDN by UMTS are identified in this chapter. Next a net-
work architecture for UMTS is presented. A radio independent interface between the core network and
access network is identified. The UMTS Access network is further decomposed into radio independent
and radio dependent components for the support of multiple radio access technologies. Finally a UMTS
network architecture utilising B-ISDN and IN capabilities and capable of supporting a number of different
air interfaces is presented
Chapter 4 addresses the role of the Mobile Terminal in the UMTS system. The MT consists of a control
plane, which is involved in the UMTS control procedures such as call control and handover and a transport
plane, which performs data manipulation a and transport functions. This chapter presents the functions of
the MT control plane and their role in UMTS procedures. A layered transport plane catering for service,
mobility and radio functions is described. The transport of signalling data in UMTS and the MT, as provided
by the UMTS SNL, is also presented.
Using the terminal architecture developed in chapter 4 and the network architecture presented in chapter
3, chapter 5 presents a functional architecture for the UMTS MT. A control/transport split is applied to this
architecture. The resulting FEs and the relationships between them are documented in this chapter. The
Functional architecture is then analysed to identify a radio independent/dependent boundary in the MT.
Finally some of the data storage aspects of the MT are described and an alternative architecture based on
object oriented paradigms is proposed.
Chapter 6 proposes some ideas for the detailed design of the UMTS MT. A design for the MT FEs
based on SOMT and SDL is presented. The non functional requirements for the MT are described. A
SOMT model which provide and integrated view of both the functional and non functional requirements of
the MT is developed.
In chapter 7 the MT architecture is applied to existing and innovative telecommunications systems,
firstly to GSM and DECT and then to the TINA system. For each system, the resulting architecture is
analysed and compared to the template architecture developed in chapter 5. Software Radio is introduced
as a new technology which may have a significant impact in mobile telecommunications in the future. The
4
capabilities of the MT architecture to facilitate this new technology is explored in this chapter.
Chapter 8 presents the thesis conclusions and proposes some further areas for study.
5
6
Chapter 2
Development of Mobile Systems
2.1 Introduction
Mobile handsets have been in existence for over 40 years. Initially, because of power constraints these
mobiles were mounted on vehicles. The power issue was partially solved by devising a system whereby
several fixed receiver stations were constructed for every fixed transmission station, enabling hand held
mobile terminals. However, the main constraint for mass market penetration remained, which is that the
bandwidth reserved for mobile communication and hence the number of users remained fixed for a given
operator in a given area; once the capacity was used up no additional users could be added.
The breakthrough came with the advent of cellular planned systems. The key behind cellular planned
systems is frequency reuse. Frequency reuse enables frequencies used in one cell to be reused in different
cells at a safe distance away. The number of users that can be supported by a base station or frequency
is still fixed by the bandwidth available, but now cells can be subdivided into smaller cells is areas where
demand is high. A cellular system solves the problem of limited bandwidth, but the complexity of the
system is increased greatly.
To deliver a call to a user the location of the user needs to be known. Two mechanisms are used to
locate the user: paging; and location update. The network is subdivided into groups of cells known as
location areas. Location update involves the network being informed when the terminal moves into a new
location area. Paging involves sending a broadcast message to all terminals in a location area whereby
the correct terminal identifies itself to the network. It is possible that a mobile system may be constructed
such that only one locating mechanism is used either location update or paging. If location update is
only used, the terminal informs the network each time it moves cell. Using paging as the sole locating
mechanism involves paging every cell within the network in which the terminal is registered. In reality,
both locating mechanisms coexist where the size of the location area (number of cells) is determined such
that the optimum solution is obtained. Achieving the optimum solution means minimising the traffic on the
7
air interface due to location updates and paging.
Also depending on the mobility of the user and cell size, a user may travel through several cells during
a single call, the user therefore needs to be assigned a new transmitter/receiver station and hence a new
frequency for each new cell. There is a requirement that the system maintains a call if the user moves
between cells. This procedure is known as handover and is one of the most complex and important of all
mobility procedures.
2.1.1 First generation systems
The first proposals for cellular systems were made in the USA by Bell Laboratories in the late 60s. The
system Advanced Mobile Telephone System (AMPS) provided locating and handover but was not put into
commercial operation until 1983 [Hil95] A system based on AMPS called Total Access Communications
System (TACS) was developed in Britain. The Nordic Mobile Telephony system (NMT) put into service in
1981 was the first mobile telephony system and even allowed for roaming between Scandinavian countries.
Most European countries have first generation systems based on NMT.
Limitations of first generation systems
While first generation systems like NMT proved very successful in terms of market penetration and reducing
both the size and cost of mobile terminals it became evident that they had several short comings. Firstly, the
market for mobile telephony was severely underestimated. Secondly, except for NMT in Scandinavia, users
could not use their mobiles in other countries. This was a major restriction especially within a European
market where business interests and travel transcend several nation states.
2.2 2nd generation systems
To overcome the capacity and service limitations of analogue systems a new set of mobile systems, based
on digital transmission technologies were developed and standardised.
The most widespread second generation system is the Global System for Mobile Communications
(GSM) and its variant GSM1800 which have been standardized in Europe and adopted worldwide. These
are cellular systems which provide extensive mobile services (e.g. speech, data, roaming) in the public en-
vironment. Another GSM variant GSM1900 has been adopted in the US. Other second generation cellular
systems include D-AMPS and IS95, a CDMA based system in the US and the Personal Digital Cellular
system (PDC) in Japan.
In parallel to these cellular systems, cordless technologies like the Digital Enhanced Cordless Telecom-
munications (DECT) have been standardised in Europe to replace nationally standardised cordless systems
(e.g. CT1 and CT2). Cordless telecommunications systems work by using a mobile handset which is con-
8
nected to either a public telephone network or private telephone exchange via a radio transceiver, called a
base station.
In addition paging systems such as the European Radio Message Exchange Service (ERMES) and
Private Mobile Radio (P-MR) have been standardised in Europe.
Overall these systems serve a worldwide market well in excess of 200 million users [Kra98].
The next sections examine the architecture and deployment of two of the most popular second genera-
tion technologies GSM and DECT and examine the role of the terminal in each system.
2.3 GSM
Within Europe the national markets were too small for any one manufacturer or operator to develop a second
generation system alone. The task of setting up a pan European second generation mobile system was
undertaken by the Conference Europeenne des Postes et Telecommunications (CEPT) which established
Groupe Special Mobile (GSM) in 1982. GSM’s task was to specify a unique radio communications system
for Europe, at 900 MHz [MP92]. The work of GSM was eased by the reservation of a pan-European
frequency band around 900 MHz (890-915, 935-960) for land mobile use in 1978.
Further developments in the Mobile Market have led to the adoption of other frequency allocations for
GSM. In 1989 the 1800 MHz band was adopted for use by Personal Communications Networks (PCN). The
PCN system, initially known as DCS-1800 is used to provide denser coverage, and hence higher capacity,
than standard GSM -renamed GSM900 -for use in densely populated, highly urbanized areas. In 1997 DCS-
1800 was renamed GSM1800. A variant of GSM in the 1900 MHz band was adopted in the United States
in the early 1990s. Originally known as DCS-1900, it too was renamed by the GSM MoU as GSM1900
in 1997. Today there are more than 200 operators running mobile networks based on the three variants of
GSM, serving over 100 million subscribers in 106 countries globally.
2.3.1 GSM Architecture
To enable a multi-vendor environment the interfaces between the physical component in the GSM system
had to be standardised. The network architecture of GSM is shown in Figure 2.1.
BTS BSC Relay MSC Anchor MSC Gateway MSC
HLR/VLR
MSPublicFixed
Network
Figure 2.1: GSM Network Architecture [MP92]
9
The first component is the mobile station (MS) and usually is the only equipment the user ever sees.
The MS provides the radio resources needed to access the GSM system. The MS contains a Subscriber
Identification Module (SIM) used to store some subscriber information, lists of frequently used numbers
and up to five short messages. The SIM is associated with a user’s subscription and can be removed from
one MS and put in another. The ability to move SIM cards between MSs provides for personal mobility
between GSM handsets.
The Base Station Sub-system (BSS) has both a radio interface and a fixed interface, and consists of
two entities: the Base Transceiver Station (BTS) and the Base Station Controller (BSC) The BTS can be
considered as complex radio modem, and has little other function. A BTS is comprised of radio transmission
and reception devices and handles all the signal processing specific to the radio interface [MP92]. The BSC
can be viewed as a small switch whose main responsibility is the management of radio channels such as
allocation, release of radio channels and handover management.
The Mobile Switching Centre / Visitor Location Register (MSC/VLR) in GSM is typically a high ca-
pacity switch suitable for regional capitals of up to 1 million inhabitants [MP92]. The VLR is used to store
temporary information for subscribers served by that MSC. The VLR also has functionality to interact with
the HLR for management of visitor subscriber information. The MSC is a connection point between the
external network on one side and the mobile network on the other.
The difference between the Home Location Register (HLR) and the VLR is that the HLR is the per-
manent home of subscriber data, whereas the VLR is used to temporarily store subscriber information for
those subscribers who are registered on that particular MSC. The HLR may be physically separated from
the MSC and has no switching capability. The HLR is more than a simple database, it could be more cor-
rectly described as an ”intelligent database” in that it manages the location information in the network by
telling the MSC/VLR to create, update or erase a subscriber record [MP92]. The VLR is an integral part of
the MSC and can be viewed as a much simpler database where the MSC deals with the protocol complexity.
GSM Protocol Architecture
Figure 2.2 below shows the general protocol architecture of GSM [MP92].
Mobility Management
Radio Resource Management
Transport
Connection Management
Mobility Management
Radio Resource Management
Connection Management
TransportTransportTransportTransport
MS BTS BSC MSC HLR
Figure 2.2: GSM Protocol Architecture [MP92]
• The Transmission Layer provides a means of transport for data between users, as well as for infor-
mation transfer between machines.
10
• The Radio Resource (RR) Layer is concerned with the management of transmission resources.
The RR layer provides for stable links between the MS and the MSC, coping in particular with the
movement of the MS during a call. Much of the RR functions reside in the BSS.
• The Mobility Management (MM) Layer is responsible for the management of subscriber databases
and in particular subscriber location data. It adds to the functionality provided by the lower layers, by
providing the mechanism to track mobile users when not engaged in communication. The MM layer
is also responsible for security and authentication in the network.
• The Communication Management (CM) Layer makes use of the stable basis provided by the RR
and MM layers to provide communications services to the users. It consists of several independent
components providing call and messaging services to the users.
2.3.2 The GSM Mobile Station
The GSM Architecture [MP92] identifies the Mobile Station as consisting of a number of different elements
as shown in figure 2.3 below.
Mobile Station
MobileTermination
TerminalAdapter
TerminalEquipment
S
Figure 2.3: GSM Mobile Station Configuration [MP92]
• The GSM Mobile Termination (MT) contains the functions needed to access the GSM network and
invoke GSM services.
• The Terminal Equipment(TE) carries out service specific functions without any regards to GSM,
e.g. a fax machine or a laptop connected to a GSM MT via a modem interface.
• The Terminal Adapter(TA) which acts as a gateway between the TE and the MT. the Terminal
Adapter is used when the external interface of the MT follows the ISDN standard for a terminal
installation. That is when the MT supports an ISDN ”S” interface [IT93d]
Functions of the GSM MT
Figure 2.4 below shows the MT architecture. The MT is the only piece of the equipment in GSM which
contains all the protocol layers described above in section 2.3.1. As well as showing the MT as being made
up of the CM, MM, RR layers, figure 4.3 further decomposes the Transmission Layer into the LAPDm
layer which provides access to the radio channels which provide a range of channel types for the transport
of signalling and user data.
11
Mobility Management
Radio Resource Management
LAPDm
Connection Management
Radio Channels
Figure 2.4: GSM MT Architecture
The functions of each of the planes in the MT are as follows [MP92]
1. Mobility Management The MM Plane updates the network on the location of the user through the
location updating procedure. This allows the network to track users and provide services to them as
they move throughout the network. The MM is also responsible for the MT side of the authentication
and encryption procedures.
2. Connection Management The CM plane in the MT is responsible for the setup, negotiation and
maintenance of calls between the MT and the Network. From the CM’s point of view the path
between the MT and the Network is considered to be a fixed link, and so is concerned only with the
call control and service provision. As well as providing for speech and data calls, the CM also caters
for the GSM Short Messaging Service (SMS).
3. Radio Resource Management The RR Plane in the MT is in charge of the management of trans-
mission paths over the air. The RR handles access and paging functions in the MT and sets up any
necessary signalling and data channels in the MT. TheRR also reports measurement information re-
lated to the active radio channels to the network. Using this measurement information, the network
decides when a handover is necessary. During a handover the network will command the RR in the
MT to switch to a new Base Station and a new set of radio channels.
4. LAPDm The LAPDm Protocol is based on ISDN ”D” channel Link Access Protocol [IT91b] and
handles the reliable transmission of signalling data between the MT and the BTS.
5. Radio Channels There are a variety of radio channels available in GSM for both control purposes
and for the transmission of data.
Common channels can be accessed by any MT and are primarily concerned with access support, they
allow an MT to synchronise to a base station and to receive information broadcast by the base station.
Other common channels provide a mechanism for an MT to request access to the Base Station and for
12
the BS to respond, allocating a channel. Another type of common channel allows the BS to broadcast
page messages when searching for a particular MT.
Dedicated channels are used for the transport of signalling and user data. For the transport of user
data two types of channels, known as Traffic Channels (TCHs) are defined.
• TCH/F The ”full rate” traffic channel allows for transmission of 13kbit/s speech or of data at
12,6 or 3.6kbit/s.
• TCH/H The ”half rate” traffic channel supports speech coded at around 7 kbit/s or data at rates
of 6 or 3.6 kbit/s.
Associated with each type of traffic channel are two channels for the transport of signalling data. A
Slow Associated Control Channel (SACCH) carries TCH related measurement information, at a rate
of about two messages every second; while a Fast Associated Control Channel (FACCH) carries more
urgent information related to a handover command or user authentication.
An additional type of channel, known as a Stand-alone Dedicated Control Channel (SDCCH), is used
when there is a need to establish a connection between the MT and the network solely for signalling
purposes, e.g. for the setup of a call or to perform a location updating procedure. The SDCCH is
equivalent to an eighth of a traffic channel and is also referred to as a TCH/8 [MP92].
2.3.3 The Future of GSM
GSM has an important role to play in the evolution of mobile systems towards UMTS. It has already been
agreed that the UMTS Core Network will be largely based on an evolved GSM infrastructure [IT97a]. In
the meantime the first steps are been taken towards that evolved infrastructure with the phased introduction
of new advanced data carrying capabilities in the GSM system:
• High Speed Circuit Switched Data (HSCSD) is being developed to provide data rates up to 64
kbit/s. Technically, HSCSD requires a new radio link protocol; a modification of the existing pro-
tocol used to provide the GSM voice channel. GSM uses TDMA (Time Division Multiple Access)
technology, which divides each 200kHz carrier into eight timeslots. HSCSD uses one timeslot to
provide a unidirectional 9.6kbit/s data circuit. All eight slots will be used to provide one 64kbit/s
circuit.
The main benefit of this approach is that it is designed for the existing GSM infrastructure. There is
no need for operators to change their entire network infrastructure in order to implement it. Operators
will therefore be able to implement HSCSD in a quick and efficient way, once the specification has
been ratified.
• General Packet Radio Services (GPRS) is a packet radio network service, which will be ready for
market deployment by 1999. GPRS will provide fast call set up times so that data users will not have
13
to wait for the phone to dial, as they do with a circuit switched call. Instead, they will get through
immediately. Like High Speed Circuit Switched Data, GPRS will enable higher-speed data services
for mobile users. But as a packet-switching technology, GPRS will be suited to the highly bursty
nature of most data applications. GPRS will be ideal for email and database access services, for
example, where users will not want to pay high call charges for short transmissions. It will also offer
more efficient connectivity with Internet-type networks, based on the TCP/IP protocol.
GPRS will handle rates from 14kbit/s, using just one TDMA slot, up to 115kbit/s and more, using
all eight TDMA slots. This will allow it to handle all types of transmission from slow-speed short
messages, to the higher speeds needed for browsing complex Web pages with high graphics content.
GPRS will also permit the user to receive voice calls simultaneously when sending or receiving data
calls.
From the operator’s perspective, GPRS will permit more efficient use of the network than circuit
radio data, and so it will enable the operator to offer more favourable tariffs. With circuit radio
transmission, a channel is allocated to a single user for the duration of a call. With a packet radio
network like GPRS, the same radio resources are shared by all users in a cell. The spectrum is used
only when the user has something to send. When there is no data to be transmitted, the spectrum
is free to be used for another call. Thus if the data is bursty in nature the network resources can be
balanced more efficiently, because the operator can use the gaps in transmission for other calls. As
with HSCSD, GPRS is being designed to work within the existing GSM infrastructure. This is good
news for operators because it means that GPRS coverage can be introduced quickly.
• Evolved Data for GSM evolution (EDGE) The second step for evolving GSM is the implementation
of Enhanced Data rates for GSM Evolution (EDGE), known as GSM++. This will allow GSM opera-
tors to use existing GSM radio bands to offer wireless multimedia IP-based services and applications
at speeds of 384kbit/s with a bit-rate of 48kbit/s per timeslot and, under good radio conditions, up to
69.2kbit/s per timeslot.
EDGE will allow the full advantages of GPRS to be explored, with fast set-up of connections and
higher bandwidth than traditional GSM. The combination of EDGE and GPRS will result in much
improved utilization of the radio network. Introducing EDGE will have little technical impact, since
it is fully based on GSM, and will require relatively small changes to network hardware and software.
For example, EDGE uses the same TDMA (Time Division Multiple Access) frame structure, logic
channel and 200kHz carrier bandwidth as today’s GSM networks, allowing existing cell plans to
remain intact.
EDGE will be particularly beneficial to existing operators. Channels with EDGE functionality will
be able to operate in either existing GSM or EDGE mode, allowing coexistence and seamless step-
by-step introduction of EDGE.
14
2.4 DECT
Another important 2nd generation system standardised within Europe and adopted globally is the Digital
Enhanced Cordless Telecommunications(DECT) [ETS95a]. DECT is a digital cordless telecommunica-
tions system which aims to provide a flexible, generic cordless access technology for innovative telecom-
munications systems.
The DECT standard, is specified in ETS 300 175 1-9 [ETS95a], the DECT Common Interface. It has
been developed within ETSI by the DECT Project; originally known as ETSI STC RES-03 Committee; to
be the pan-European standard for (cordless) access to telecommunications networks.
This standard, which is based on a multi-carrier time-division multiple-access time-division-duplex
(TDMA/TDD) based approach, designed to operate in the 1.88GHz to 1.90GHz band is designed to support
a wide range of advanced services and requirements. DECT supports voice telephony, high speed data,
video and other multimedia applications at data rates up to 552kb/s; far superior to those provided by GSM.
DECT data services are best suited to low data-rate Wide Area Network(WAN) services, rather than high
bandwidth LAN services. Examples of there low rate data services include remote e-mail access, and web
browsing. Figure 2.5 below shows some of the application areas for DECT.
• Telephon y• Voice Mail
• Printing
NetworkServices
• PDA/PO Applications• PDA/PO Communications
DECTBasestation
Storage
Telephon y
Fax
LAN/WAN
Messaging
Video
• LAN access• Fax• Modem• X.25• Video• CTI
Figure 2.5: DECT application areas [EBG96]
DECT provides a high-quality low-cost solution for digital cordless networking in a home environment
and a useful solution for a wireless business environment. As well as this, recent trials have shown DECT
to be a viable solution for virtual business organisations, using virtual private networks [Del96a].
2.4.1 DECT Architecture
DECT is an access technology, which means that it must be connected to a core network, such as the
PSTN or ISDN. The DECT Common Interface Reference Model is shown in Figure 2.6, illustrating the
15
relationship between DECT and core networks. The IWU between a network and DECT is network specific
and thus is not considered part of the DECT common interface, although subsets and extensions to the
DECT Common Interface have been specified for interworking to specific core networks such as N-ISDN.
Global Network
Local Network Local Network
Portable Part
ES
PT
Portable Part
ES
PT
Portable Part
ES
PT
Portable Part
ES
PT
Fixed Part
IWU
FT
Fixed Part
IWU
FT
Fixed Part
IWU
FT
Fixed Part
IWU
FT
Common Interface
IWU InterWorking UnitFT Fixed TerminationPT Portable TerminationES End System
Figure 2.6: DECT Common Interface Reference Model [ETS95a]
A DECT system consists of a Fixed Part(FP) and a terminal, called a Portable Part. The FP, can encom-
pass numerous base-stations, in which case each base-station is referred to as an RFP (Radio Fixed Part),
and a controller, referred to as a CCFP (Cluster Controller Fixed Part) which interfaces to the RFPs and the
core network. The FP interfaces to attached core networks such as N-ISDN, PSTN, GSM, Internet, LAN,
B-ISDN, and UMTS. DECT provides a standardised means of wireless interfacing (interworking) to many
different telecommunications and datacomms networks and services. These services provided by DECT
on the access network side can be either private (residential, business or VPN) or public (e.g. wireless
extensions of the core network).
DECT Standards
One of the great strengths of DECT is the level of standardisation which has been developed to allow
interoperable access to multiple voice and data services via multiple networks. This comprehensive set of
standards in fact provides for all the services which would today be expected of a multimedia technology.
DECT standardisation is based around its base standard, ETS 300 175 [ETS95a], the set of Interworking
Profiles (IWPs), ETSI issued TBR/CTRs and full Test Specifications. The main networks and services with
which DECT interworking is specified are shown in Table 2.1
DECT provides, in a standardised way, many of the communications services which a mobile multime-
dia user would require. Furthermore, as new services are developed, such as CTM or V.34 modem video
16
Profile Reference ApplicationGeneric Access Profile (GAP) ETS 300 444 TBR 22 Voice TelephonyISDN IW Profile - End System ETS 300 434 ISDN telephony, supplementary
services and 64 Kbps dataDECT/GSM Interworking Profile ETS 300 370, ETS 300 466 GSM telephony with full roaming
and mobilityData Services Profile A/B.1 ETS 300 435 Ethernet, Token-Ring
and IP accessData Services Profile C.2 ETS 300 651 Modems, RS-232 and X.25Data Services Profile F.2 ETS 300 755 G3 Fax, SMS, e-mail,
G4 Fax, WWWData Services Profile A/B.2 ETS 300 701 IP, Ethernet, and Token Ring with
roaming, Frame RelayData Services Profile D.2 ETS 300 NTD Isochronous data services,
including real-time videoPPP Interworking Profile ETS 300 NTD PPP over modems, ISDN
and X.25 via DECT packet service
Table 2.1: Summary of DECT Standards and Data Profiles
telephony (H.324), additional DECT interworking profiles will be added to meet such additional require-
ments.
The efficient support of a packet data service is provided in the A/B and PPP profiles. These support
asymmetric transmission fof data; vital to achieve reasonable radio spectrum usage with multimedia data
services since most data transmission is highly bursty and asymmetric in nature. The most obvious example
of this type of traffic is web-browsing traffic. It has been shown that providing a packet data service over
the air, rather than a circuit switched one, is much more efficient with this type of service [EBG96].
DECT Layered Architecture
The complete common interface specification corresponds to the lower three layers of the ISO OSI reference
model, with some additions to cope with the requirements of maintaining a reliable quality link in a variable
radio environment. Figure 2.7 below shows the DECT layered Architecture and how it corresponds to the
OSI Architecture.
OSI layer 1 comprises DECT’s physical layer (PHL), which modulates and demodulates the radio car-
riers to provide the physical link between the FP and the PP. Together with the lower aspects of the DECT
Medium Access Control layer (MAC), which chooses the appropriate channel or channels for carrying the
information.
The rest of the MAC layer, together with the Data Link Control (DLC) layer make up the OSI layer
2, and are responsible for maintaining information flow when cells and channels are being switched (han-
dover). The DLC layer is split into a C-Plane (control plane), and a U-Plane (user data plane). The DLC
C-Plane is responsible for maintaining a reliable transport link to the network layer signalling protocols,
and the DLC U-Plane is responsible for user data services to user applications.
17
Network Layer
MAC Layer
Physical Layer
DLC-Layer
Network Layer
MAC Layer
Physical Layer
DLC-Layer
Portable Part Fixed Part
OSI Layer 3
OSI Layer 2
OSI Layer 1
Figure 2.7: DECT Layered Architecture [ETS95a]
The network layer, which corresponds to the OSI layer 3, is responsible for call control, mobility man-
agement, call unrelated supplementary services, connection-oriented message services, and connectionless
message services. There is no U-Plane interaction in the network layer.
2.4.2 DECT PP
Figure 2.8 below describes the functional architecture of the DECT Portable Part. The DECT PP contains
DECT layered protocol stack, as outlined above. The following subsections describe the role of each layer
in the PP.
Network Layer
MAC Layer
Physical Layer
DLC-Layer
CC MM CLMSCOMS
LCE
C-Plane U-Plane
Figure 2.8: DECT PP Architecture
Network Layer
The DECT Network Layer provides a set of functions and messages to request, allocate, manage and aban-
don resources in the PP. The network layer in the PP can be broken down into a number of constituent
elements handling Call control, mobility management, messaging systems and interaction with the lower
layer.
18
• Call Control The CC is responsible for the setup, negotiation and maintenance of calls between the
MT and the DECT Fixed Part.
• Mobility Management The MM controls the mobility management procedures in the PP. These
are used to inform the Fixed Part of the PPs current location. The MM also manages security and
authentication in the PP.
• Messaging Messaging services in DECT are provided either in a connection oriented or a connec-
tionless manner. Two entities exist in the PP network layer for the handling of messaging services,
the Connection Oriented Messaging Service (COMS) and the connectionless Messaging Service
(CLMS).
• Link Control Entity The LCE manages the relationships between the network layer functions and
the underlying DECT layers, by providing a mapping between the lower layer connections and the
network layer functions.
Data Link Control
The DLC layer is responsible for maintaining the logical link between the DECT PP and the Fixed Part. It
provides reliable transport of data even during handover. The DLC works closely with the MAC layer to
provide better data integrity than can be provided by the MAC layer alone. The DLC layer has two parts,
a control plane part and a user plane part. The C-Plane DLC is used for control signalling, and also for
limited data signalling by the network layer messaging services. It provides two independent services, the
data link service for point to point transport and a broadcast service. The U-Plane DLC provides transport
services to the user application as described in table 2.2.
Profile Reference DescriptionLU1 Transparent protected data Speech Mainly, can be used for dataLU2 Frame Relay Frame relay service with error correctionLU3 Frame Switching Frame Switching with FECLU4 Forward Error Correction Data with FEC protectionLU5 Basic Rate Adaptation Transparent synchronous connection to ISDNLU6 Secondary Rate Adaptation V110 rate adaptation to ISDN using LU5LU7 64kb/s data bearer IOSDN services
LU16 Escape Non standard services
Table 2.2: DECT U-Plane DLC services
2.4.3 Medium Access Control
The MAC chooses a suitable radio channel, called a bearer in DECT terminology, and passes information
through this channel. The MAC layer consists of a Signalling (C) Channel, a paging (P) Channel, an
Information (I) channel and a Broadcast (Q) channel. The C, P , Q channels are multiplexed together into
19
the 48 bit A filed of a DECT MAC Bearer. the I field channel is always transmitted in the B-Field of the
bearer. The I channel can be transmitted either as unprotected 32kbps ADPCM encoded voice (Is) or as
protected 24kbps data (Ip). The structure of a DECT bearer is shown if figure 2.9.
A Field B-Field
16 bit CRC48 bit C, P, Q field I Channel 320 bits32 kbps ADPCM24 kbps Data
Figure 2.9: Structure of a DECT Bearer
Physical Layer
The Physical Layer provides physical access to radio interface by dividing the allocated DECT spectrum in
both frequency and time. The physical layer modulates and demodulates carriers to create an RF physical
channel. The physical channel in the MT observes the radio environments and activates physical channels
on request of the MAC.
2.4.4 Future trends in DECT
DECT is a pan European digital cordless telecommunications system which is a flexible, generic cordless
access technology for innovative telecommunications systems. It has the potential to be a high quality
low cost solution for digital cordless networking in a home environment, a useful solution for a wireless
business environment, and as the ACTS EXODUS phase I demos [Struili, 1997] have shown, a viable
solution for virtual business organisations, using virtual private networks. However, the DECT Telepoint
[Candy et al., 1997] concept has suffered from a lack of market focus and presently does not exist in any
meaningful fashion. More innovative DECT data services are suffering from a similar lack of focus in the
marketplace, with division between ETSI unrealised standardised data profiles and realised unstandardised
implementations [Gloger, 1998].
In DECT’s favour the voice quality is excellent, as user acceptability trials have shown [Struili, 1997].
Also DECT offers a significant degree of security to users through strong encryption. The data rates achiev-
able from DECT are superior to GSM, at present operating at 4 times GSM data rates and with standard-
ised data rates up to 552Kbps, which have been recently achieved [Gloger, 1998] This 552Kbps compares
favourably with GSM GPRS and EDGE systems described in section 2.3.3.
The broad focus of DECT on the voice oriented Generic Access Profile GAP [ETSI, 1996e] and on
a wide range of data service profiles has contributed to a slow market takeup, as organisations remain
unconvinced of the possibilities of expensive digital cordless systems, especially as GSM seems to have
closed the market in mobile voice technology. However, despite the high terminal costs several million
DECT units are expected to sell by the year 2000 [Schneider, 1997]. Also, the recent development of
20
dualmode DECT/GSM mobile phones by Ericcsons can be expected to further drive the sale of DECT
products. DECT data products have been extremely slow in reaching the market place, perhaps due to the
perception of DECT data as a slow wireless LAN solution; at best a niche market, and possibly due to the
slow acceptance of data as a key expansion market by public operators in general. Recent reports to the
DECT Group on the takeup of DECT based subscriptions offered by Telecom Italia have been encouraging.
However the Italian has been terminated because of licensing issues with the Italian Government and the
European Community, throwing the whole concept of DECT in the public environment into disarray.
The next few years are likely to see a continued, slow take up of DECT in the home and business
environments for voice and data access. In the medium term, new bandwidth will be allocated to the DECT
spectrum allowing for data rates up to 2Mb/s suitable for use with wireless LANs. The long term future
for DECT is less secure. DECT has had little or no influence to date on the UMTS standardisation process
and is in danger of being sidelined altogether. However the range of services and capabilities offered by
DECT as well as new interworking profiles should ensure that DECT remains a viable access technology
for UMTS and B-ISDN networks [McN98].
2.5 Third Generation mobile Systems
Even though second generation systems are relatively new and the demand for them is expected to continue
for the near future, the limitations of these systems are already been reached. In the last ten years, much
money and time has been spent in the specification and development of third generation mobile systems
[PCK98].
It is the aim of third generation systems to encompass all the application areas of exsiting second gen-
eration systems, and more, by a single system; thus providing a single pocket terminal which provides the
same interface to the user independent of the application area to which the user belongs. One advantage of
this system is that it allows an overlap of application areas, which more coherently matches the mobility
characteristic of users (i.e. no user belongs exclusively to a single application area, but is more likely to
belong to two or more). This overlap of application areas is likely to be feasible prior to the deployment of
3rd Generation systems through the use of dual mode terminals (i.e. a DECT/GSM hybrid terminal) and
the standardisation of extensive interworking.
Another aim of 3rd generation mobile systems is to bridge the gap between developments in the fixed
networks and mobile networks. This narrowing of the mobile-fixed gap should allow for services deployed
in mobile networks to closely match service deployment in fixed networks. Other developing concepts like
the separation of user mobility (i.e. Universal Personal Telecommunications - UPT) and terminal mobility
have also to be embraced by 3rd generation systems.
For third generation systems to compete successfully with 2nd generation systems and analogue sys-
tems, mass usage of their telecommunications services will be required. In addition, they have to provide
21
all the services currently provided by the fixed network systems at a quality that is perceived to be the same
as is provided by the fixed network.
2.5.1 Requirements of third Generation Mobile Systems
Third generation systems are currently being investigated under the auspices of the International Telecom-
municatios Union (ITU) and by regional standardisation bodies such as the European Telecommunica-
tions Institute (ETSI). The ITU system, International Mobile Telecommunications - 2000 (IMT2000) aims
provide a global systems framework for the development and standardisation of third generation systems
[IT97a]. As such the ITU are aiming to promote the standardisation of adaptable, flexible architectures for
the support of multiple systems capable of offering access to broadband mobile services anytime, anywhere.
To fulfil these requirements, the ITU has identifed the following requirements for third generation mobile
systems [Kra98].
Service Adaptation
Third generation mobile systems must provide universal coverage and to enable terminals to be capable
of seamless roaming between networks, which may be of differing types. Services will negotiate with the
radio bearer via an adaptation layer to secure channels in each direction, having the required characteristics
of bandwidth, delay and quality, also recognising that many multimedia communications will be highly
asymmetric. The need to provide for future non standardised services, which can be created independently
in a competitive, multi operator environment places radically new requirements on the radio interface con-
cept. No longer will the various elements of the radio interface (e.g. channel coder, modulator, transcoder
etc.) have fixed parameters, rather, they would be in the form of a ”toolbox” whereby the key parame-
ters of bandwidth, transmission quality and delay can be selected, negotiated, mixed and matched by the
requirements of the teleservice, according to the instantaneous capability of the radio channel.
Greater Flexibility
There is a growing need to accommodate a maximum level of interworking between networks of different
types to provide customers with greater coverage and consistency of services. This includes cellular, PCS,
paging and data networks and services. What is needed in support of this interworking is a system that
provides much greater flexibility. Such flexibility would enable operators to configure and manage their
networks in accordance with the service demands of the market. Ideal flexibility includes the following
characteristics: multi-functionality, multi-environment capabilities, multi-mode operation, and multi-band
flexibility. Furthermore pre-IMT2000 systems will continue to add new features and functionality as dic-
tated by the needs of the market and that some of these advancements might facilitate some of the needed
flexibility.
22
Support for Multiple Environments
A good Radio Access system, particularly an adaptive one, should be capable of supporting operation
with good spectrum efficiency, coverage efficiency and service quality in all the physical environments
in which wireless and mobile communication will take place. Third Generation systems should be more
flexible than Second Generation systems which are something of a compromise. It is a multi-dimensional
situation, involving physical environments such as in-building, outdoor congested (urban), and outdoor
rural. There are different mobility environments such as stationary, pedestrian, vehicular mobility, and high
speed applications. The Radio Access system needs to optimally adapt to all propagation environments
(terrestrial and satellite) and all traffic environments which result, including mixed environments, where,
for example, fast moving vehicles may be moving on a roadway which is physically close to a pedestrian
precinct.
Modulation and Multiple Access Selection
Third Generation Wireless Multimedia terminals will have to exist in a world of multiple standards. A single
Third Generation air interface standard would ease the requirement for world-wide roaming. However,
the different regional interests and different rates of progress will have to be taken into account. Also,
mobile network operators want backward compatibility so that the new terminals will still to be able to
interwork with the old infrastructure. Adaptive technology and over-the-air software download will make
multimode/ multiband, multimedia terminals feasible which can interwork with different standards, old and
new. Intelligent cell sites will be needed as well as a flexible switching and transport infrastructure. At the
same time, low cost is essential in order to assure a mass market.
Flexible Control
There is a need to evaluate the feasibility of more flexible control techniques for the radio interface. Flexible
control is needed not only to adapt a mobile terminal to a number of different interfaces and environments,
but also to enable real-time control and dynamic tuning of basic parameters (modulation, channel coding,
etc.) to optimise performance and spectrum efficiency.
Fixed Wireless Access
The capability of IMT-2000 to support fixed wireless access services is an essential need in developing
countries and will be utilised for providing competition and/or supplement capacity to the fixed wired
network in many developed countries.
23
2.5.2 Universal Mobile Telecommunications System
The Universal Mobile Telecommunications System (UMTS) is one third generation system, currently being
developed in Europe. It is intended to be the Pan-European third generation system to begin deployment at
the start of the next century (i.e. 2000-2005). However, while the UMTS system is targeted at the European
market initially, and is to be standardised by ETSI, it is likely to have a significant bearing on IMT2000, the
world wide 3rd generation mobile standard being developed by ITU.
UMTS Requirements
An extensive set of operational and functional requirements for UMTS have been identified for UMTS
[Del95c], [Swa97] the most crucial of which are the following :
• To support existing mobile services and fixed telecommunication services up to bit rates of 2Mbit/s.
• To support unique mobile services such as navigation, vehicle location and road traffic information
services, which are becoming increasingly important in a pan-European market.
• Flexible and modular service support, including multimedia.
• To allow the UMTS terminal to be used anywhere, in the home, the office and in the public environ-
ment, both in rural areas and city centres.
• To offer a wide range of terminals; from low cost pocket telephones ( to be used by almost anyone
anywhere) to sophisticated terminals to provide advanced video and data services.
• Friendly interoperator roaming. ( i.e seamless handover)
Additional requirements are that 1) UMTS should provide a clear division between terminal and per-
sonal mobility and 2) provide an ’open ended system’ which would allow the easy introduction of new
technologies and 3) provide integrated security and authentication.
The requirement for the clear separation of terminal and user mobility is required to enable the flexible
support of Universal Personal Telecommunications (UPT). In GSM the same identity is used to support both
terminal mobility and Subscriber Identity Module (SIM) mobility, thus providing SIM mobility instead of
personal mobility, complicating the support of UPT. True separation would allow a UPT user to register on
a UMTS terminal without a mobile network subscription [FN/12].
The development of UMTS as an open ended system, will allow for the continuing extension of its
functions and smooth growth over a wide range of size and complexities. The UMTS functions should
be modular and generic [SSD]. In addition, the UMTS system should be ’lean and mean’ containing the
smallest possible set of generic functions from which a very large set of applications can be built.
24
The security mechanisms of UMTS must provide adequate protection for the user and system informa-
tion flows. End-to end encryption of user information must also be supported, and the privacy of the mobile
user maintained.
Finally, UMTS must support backwards compatibility with existing radio access systems. That is it
should be possible to support existing mobile systems and services as well as new and advanced access
techniques using a single UMTS infrastructure.
Development of UMTS
In recent times, UMTS has ceased to be a revolutionary concept in the evolution of mobile systems. Rather,
it has become to be viewed as the next natural step forward in mobile systems [Kra98]. As such it will be
built on existing technologies and infrastrucures. Figure 2.10 shows the devlopment of UMTS from existing
second generation systems. UMTS will incorporate all of the services and featuires provided by existing
mobile systems. Primarily, UMTS will be will built on the future GSM network infrastructure comprising
support of HSCD, GPRS and EDGE as described in section 2.3.3, to provide ubiquitous wireless access to
a range of mobile, multimedia and internet services [T.N98].
First Generation Second Generation Third Generation
Digital Cordless
CT2, DECT
Digital Cellular
GSM, DCS1800
Paging Systems
ERMES
Digital Radio
TETRA
Satellite
Irridium
Analogue Cordless
CT0, CT1
HSCSD, GPRS,EDGE
Analogue Cellular
TACS, NMT
UMTS
Figure 2.10: Evolution of Mobile Systems
UMTS Radio Access
ETSI is also specifiying a new radio interface for UMTS, known as the UMTS Terrestrial Radio Access
(UTRA) [ETS98]. The UTRA is a compromise solution and incorporates two different technologies to
provide radio access in different UMTS environments. A Wideband CDMA interface will be used to provide
access to UMTS services in the public environment. A TD/CDMA hybrid will be used in the business and
domestic envronments for access to UMTS.
25
2.6 Conclusion
This chapter has presented an overview of the development of mobile systems and techologies.
Initial first generation analogue systems offered little by way of services and provided minimal support
of user and terminal mobility. Secomd generation systems as well as making more efficent use of the
available radio resources, have increased the range and flexibility of mobile services. This is reflected in
the phenomenal growth and of these systems, particularly GSM which has made the mobile market one of
the most important, if not the most important telecommunications market in the world today.
As the mobile market has continued to grow and evolve, so too have the services and features offered by
mobile systems. However existing second generation systems are limited in the type of data services they
can offer. Third generation systems are being developd by the ITU and local standardisation bodies to meet
the data service requirements, especially for multimedia and internet services, of mobile users well into the
next century.
Within Europe UMTS is being developed as evolutionary step from existing second generation systems,
particularly GSM. UMTS is intended to be a flexible open system efficently supporting high data rates in
order to offer an extensive range of existing and innovative services to mobile users. At the same time
UMTS will provide backwards compatibility with existing, deployed mobile systems and architectures.
The following chapter investigates the capabilities of UMTS to provide an open and flexible mobile
architecture. Two technologies, B-ISDN and IN are identifeid as essential to the provision of a wide range
of flexible data and mobile services in ther UMTS network. Coupled with this, the UMTS network itself,
must be flexible and able to support a range of radio access technologies.
26
Chapter 3
A Flexible Architecture for UMTS
3.1 Introduction
Flexibility is the key requirement for UMTS. This chapter looks at the adoption of three elements necessary
to create a flexible UMTS architecture; the Broadband Integrated Services Digital Network (B-ISDN),
the adoption of Intelligent Network (IN) techniques and the division of the UMTS network into Radio
Independent and Radio Dependent parts.
The Broadband Integrated Services Digital Network provides a fast and flexible switching framework
for the deployment of high bandwidth multimedia services. B-ISDN and its associated link layer, Asyn-
chronous Transmission Mode (ATM) are used in UMTS as the basis for the development of data services
in the UMTS access and core networks. This chapter explores the data services and switching architecture
offered by B-ISDN and describes the modifications needed for the support of UMTS.
Intelligent Network techniques have been developed to separate the switching aspects and service as-
pects in telecommunications networks. Intelligent networks are so named because they take the intelligence
in the system used to support user and network services out of the switch and into separate network nodes.
This means that new services can be introduced without modifying the switch software. UMTS requires a
whole new set of services to support the mobility of the user. Section 3.3 describes how IN can be utilised
in UMTS for the provision of new services for personal and terminal mobility.
Thirdly, this chapter examines the requirements of the core and access networks in UMTS. UMTS is
required to support a wide range of new and innovative radio systems, while at the same time providing
backwards computability for legacy second generation systems. The support of multiple systems in a single
network requires that that network be both flexible and adaptive. Section 3.4 describes how a clear sep-
aration between the UMTS core and access networks using a standardised interface facilitates the use of
multiple radio access technologies in UMTS. Furthermore by adopting a radio independent/ radio depen-
dent division in the access network it is possible to support any number of radio access systems using a
27
single network infrastructure.
Finally a network architecture incorporating B-ISDN, IN and a radio independent /radio dependent
division are presented for use in UMTS.
3.2 Network Transport Mechanisms
UMTS is expected to provide the capability of offering multimedia wide-band services integrating voice,
data, video and other service to users while at the same time providing seamless, wireless access [Ric94].
In offering such a wide array of services, it is essential that the underlying transport system used be capable
of offering
• good performance in terms of achievable rates, switching capacity, network management, signalling
features, QoS, adaptation layers, etc;
• expandability.
As well as these aspects UMTS expects high bandwidth on the radio interface, requiring a technology
with a high switching capacity in the transport network. As UMTS is deployed in the mass market and
the number of users increases worldwide the control/signalling traffic will reach significantly high levels
[ETS93]. This is particularly true when considering the mobility aspects of the system. The necessity of
supporting different environments and architectures will increase the demands on the switching capabil-
ity of the transport network. The concept of call and bearer separation is a desirable feature for UMTS,
as is separation between the basic switching functionality of the network and the intelligence in the sys-
tem. These allow further degrees of freedom in the system architecture and the support of mobility related
services.
The Broadband Integrated Services Digital Network (BISDN) and its chosen transport technology,
Asynchronous Transfer Mode(ATM) offer the best potential transport network for UMTS, in terms of both
offered transport services and ease of protocol and system integration [Nor94]. The next sections describe
the functionality and services provided by B-ISDN and how these are utilised within UMTS.
3.2.1 B-ISDN
The B-ISDN Protocol Reference Model (PRM) is composed of three separate planes: User Plane, Control
Plane, and the Management Plane [IT91a]
The User Plane, or U-Plane, is concerned with peer-to-peer transfer of user data. It contains a physical
layer, an ATM layer, and several AALs that support different higher level services, such as voice and data.
The U-Plane supports application data transfer between two ATM end users.
28
C-Plane U-Plane
Plane Management Functions
ATM
AAL
Services
Physical
Figure 3.1: B-ISDN Protocol Reference Model [IT91a]
The Control Plane’s set of associated protocols perform the necessary signalling for call set-up and tear-
down. The C-Plane shares the physical and ATM layers with the U-Plane but contains a separate signalling
AAL and higher-level function.
The Management Plane is further divided into a Plane Management Plane and a Layer Management
Plane. The former is concerned with the interaction between different planes and performs management
functions for the complete system. The latter performs management functions relating to resources. It also
supports the information flows of Operation, Administration and Maintenance (OAM) cells.
The protocol reference model for B-ISDN is composed of four protocol layers: the higher/applications
layer, the ATM adaptation layer (AAL), the ATM layer, and the Physical layer [IT91a].
B-ISDN Layers
The higher layer or application layer is hidden from the complexity of the ATM network by the underlying
AAL. Application data is transported by the ATM Adaptation Layer(AAL). An application or higher layer
protocol can choose from a range of AAL-SAPs, each with an associated QoS.
The AAL of the protocol reference model accepts variable length data streams and maps these into
fixed size ATM cell payloads. The AAL enhances the services provided by the ATM layer and performs
functions for the user, control and management planes, such as Segmentation and Reassembly (SAR), cell
loss detection/recovery, flow control and padding [IT93a].
The ATM layer operates independently of both the underlying physical layer and the AAL layer above
it. The ATM layer is responsible for a number of functions involving the contents of the ATM cell. In
the transmit direction (i.e. from source), data is accepted from the AAL and encapsulated in ATM cell
payloads. The ATM layer generates cell headers containing, among other things, path identifiers used for
switching. The cell headers are extracted from arriving cells and their payloads are passed to the AAL. Cell
payloads are not manipulated at this layer.
29
The physical layer performs the functions necessary for converting the flow of cells into a flow of bits
which can be transmitted and received by physical layer devices. These functions include the generation
and recovery of frames, the adaptation of cells to frames (e.g. SDH frame format) and adaptation of the rate
of ATM cells to physical capabilities.
ATM Adaptation Layers (AALs)
ATM is capable of handling a variety of media (e.g. voice, video and data) over a single interface. The ATM
layer is common to all services and provides the cell switching and transfer capabilities in a broadband
network. The AAL is service dependent and can therefore support higher layer functions of the user plane,
the control plane and the management plane. An AAL maps the services from their native format into
cells. Different services require different AALs. ITU-T has defined four classes of services and number of
protocols to provide those services: AAL1, AAL2, AAL3/4, and AAL5 [IT93a].
AAL1 is designed for synchronous constant bit rate traffic. Services which are subject to delay con-
straints but not sensitive to data corruption can be transported using this protocol.
AAL2 is used to support connection-oriented, variable bit rate traffic where a time relation exists be-
tween the source and the destination. Traffic generated from a video source using compression would use
this protocol for the transfer of data over a B-ISDN. Lately, the AAL2 protocol is being defined to support
low rate, short packet, delay sensitive services [FH98].
Originally there were separate specifications for AAL3 and AAL4, each providing variable bit rate ser-
vices which are sensitive to data loss but not to delay. AAL3 was intended to provide a connection-oriented
mode with AAL4 providing the same service expect in a connectionless mode. Due to the similarities in
functionality required, the standards were merged. AAL3/4 provides a set of services suitable for use by
computer data traffic [Gri97], including support for multiplexing of data streams.
AAL5 was developed to provide services suitable for computer data, but in a more reliable and efficient
manner than AAL3/4. It provides the same set of services as AAL3/4 with the exception of support for
multiplexing of streams, but with less overhead and better detection.
The Signalling AAL (SAAL) [IT94] has been developed based upon AAL5. SAAL provides a highly
reliable transmission service to the signalling layer above it. The SAAL supports many functions to ensure
reliable delivery including [Kya95]: flow control, error correction and data retransmission and Automatic
Repeat Request (ARQ) mechanisms.
Signalling in B-ISDN
ATM is a connection-oriented switching technology. In order to support dynamic connection set-up, con-
nection re-negotiation and connection tear-down, a signalling protocol must be used. The ATM signalling
protocol consists of the protocol and messages that are exchanged between an ATM end user and the net-
work. In order to meet the wide variety of demands, a large degree of flexibility must be afforded both the
30
network and the users when establishing a connection. To support this, a number of parameters, or traffic
descriptors, have been standardised [IT95]. The signalling protocol allows connections to be set-up with
characteristics that meet the needs of both the users and the network.
There are two functional interfaces in an ATM network: the User to Network Interface (UNI), and
the Network to Network Interface (NNI). The UNI defines procedures and protocols that enable an ATM
end host to connect to and function with an ATM switch. The UNI functions and protocols have been
standardised by the ITU [IT95] and the ATM Forum [For93] [For94] [For96]. The UNI specifications have
been derived from Q.93B, the narrowband ISDN signalling protocol. Signalling is out-of-band, that is,
signalling PDUs (i.e. Q.2391 messages in the case of ITU-T defined signalling [IT95]) are carried on a
separate pre-assigned connection. The NNI is defined as the interface between two adjacent ATM switches.
3.2.2 B-ISDN and UMTS
In contrast to the existing second generation system, e.g. GSM, which are standalone systems; a primary
goal of UMTS is integration into the existing B-ISDN network [KS94]. This is justifiable given the en-
hanced broadband services provided by UMTS. Integrating UMTS and B-ISDN requires maximum re-use
of any existing B-ISDN infrastructure and equipment and so it is most beneficial to consider UMTS as the
mobile access to B-ISDN and consider UMTS users as mobile broadband users in B-ISDN.
The basic idea behind integrating UMTS and B-ISDN is the commonality of required functions [Nor94].
While UMTS needs also to support handover, paging and mobility management functions which are not
required in B-ISDN, functions such as call handling, transport of user data and switching need to be avail-
able in both systems, By integrating UMTS and B-ISDN into a single network, duplication of common
functionality can be avoided.
An example physical configuration of an integrated UMTS/B-ISDN is given in figure 3.2 below [Del95d].
The MT communicates with the Radio Access System(RAS) over the radio interface. The RAS has an ATM
connection to the LE with the UNI located on this connection.
B-ISDN Backbone Network
MobileTerminal
TransitExchange
LocalExchange
RadioAccessSystem
RadioInterface
UNI NNI
Figure 3.2: UMTS as Access to B-ISDN [Del95d]
3.2.3 UMTS requirements on B-ISDN signalling
Integration of UMTS and B-ISDN requires maximum reuse of B-ISDN infrastructure and signalling proto-
cols at the B-ISDN UNI and NNI. As B-ISDN does not have built in mobility support some requirements
31
on the BISDN signalling protocols can be identified [KMS94]. Requirements on the B-ISDN NNI include;
• support for interrogation triggers The B-ISDN must be able to distinguish between a call destined
for a mobile or a fixed user. As mobile users change their point of attachment while roaming, it is
necessary that some data interrogation procedure be invoked to give an approximate location for the
user. After this a paging procedure may be used to find the actual point of attachment, before the call
is offered.
• Support for look ahead procedures Due to the mobile nature of UMTS, users will have a greater
probability of being unreachable for incoming services. It is therefore desirable that a separation
between call and bearer control is supported so that network resources and bearers are not seized
before the user status and location are revealed.
• Handover Requirements Handover imposes stringent requirements to the underlying broadband
infrastructure. This is because handover should be speedy and seamless to the mobile user and at
the same time achieve efficient usage of the network resources. The requirements on the NNI for
handover are mostly related to inter LE handover. In second generation systems the anchor approach
to handover has been adopted [MP92]. One LE controls the call for the lifetime of that call. If an
inter-LE handover is required then the call is simply related through the LE closest to the new point
of attachment. For UMTS user density will be much greater than for GSM and a more optimum
strategy should be adopted [Del94a]. If a call is considered to consist of a set of interconnected call
and bearer control points then those points, based in local or private exchanges, can be rearranged to
provide optimum call routing and resource usage. Support for such an inter-LE handover mechanism
requires abilities in the network to
– Move calls between network entities supporting call control
– Add or remove call control entities between communicating end users
– retain a call even if signalling association between the MT and the network is released
– Reroute connections and bearers based on the movement of call control entities
As well as the requirements identified for the NNI, further requirements on the UNI, for access sig-
nalling, have also been identified as follows:
• Support for Redundant branches of a call In order to support seamless handover, it will be neces-
sary to establish a new call path between the access network and the switch before releasing the old
call path. During the handover both paths are available in the switch and simultaneous switching of
data from the old to the new path can be performed.
32
• Addressing of several MTs over same physical interface. Currently the B-ISDN UNI is little more
than a dedicated link and needs to be enhanced to support addressing of the MTs in the complete
UMTS access network [Del93a].
• Support for addressing and interaction with network entities other than the LE. The UMTS
access network will be made up of different Network Entities(NEs) in addition to the LE. As well
as supporting the addressing of multiple MTs in the access network, the UNI should also include
support for the addressing of different NEs in the access network by the MT.
Supporting Mobility in B-ISDN
In addition to the signalling requirements identified above, mobility related transport functions, such as
transcoding and handover of call-related connections must also be supported in UMTS. The main aim is
to introduce UMTS mobility into the B-ISDN network without placing (difficult) mobile specific require-
ments on the B-ISDN components. This objective is achieved by maintaining B-ISDN with a minimum
of enhancements, and by implementing UMTS services on top of the existing B-ISDN. This entails the
introduction of UMTS-specific devices into the core network, other than the switches. These will handle
functionality specific to mobile services, using existing B-ISDN transport and control where possible and
appropriate.
Figure 3.3 below shows a network architecture for UMTS integrated with B-ISDN, with mobility sup-
port provided by a UMTS Mobility Server(UMS), attached to the LE [Del95d].
B-ISDN Backbone Network
UMTSMobilityServer
TransitExchange
LocalExchange
RadioAccessSystem
MobileTerminal
Figure 3.3: Integrated UMTS and BISDN with UMS [Del95d]
The UMS contains all mobile specific transport functionality required to support the necessary mobile
specific transport functionality required in the system. It performs any multicasting and combining needed
for seamless handovers. For services that require transcoding, e.g. speech, or other interworking functions
these functions can also be located in the UMS. For the UMS to perform these functions, requires that it
is included in the call path. Otherwise the call needs to be modified to be routed through the UMS when
handover or transcoding functionality needs to be invoked. However including the UMS in the call-path
only on demand is equivalent to performing a handover, which would also require a UMS.
33
In B-ISDN fixed networks, different connections are used between terminal and the LE for every call.
In the figure 3.3 separate connections are used between the UMS and RAS for every call. These are setup
and released using the normal connection control of B-ISDN, and can be setup between the UMS and the
RAS as required, e.g. during handover.
While B-ISDN control is used to setup the individual connections between the UMS and LE and the LE
and the RAS, these connections are not necessarily related to the overall service of the UMTS call. That is
some functionality must be included to be aware of the aggregate effect of the bearers in a UMTS context.
A dedicated UMTS call control is required.
UMTS call control can be located in the UMS [LdLGdV96]. It interacts with the MT for call related
signalling messages and co-ordinates the setup and release of the different connections required in the call.
When setting up a call between a fixed and mobile terminal, the fixed terminal(FT) will not have UMTS
call control functionality. The FT will use normal B-ISDN call control to setup the call and the connections
required in that call. Some interworking is required between the standard B-ISDN call control and the
UMTS Call control used by the MT. This interworking is also provided in the UMS.
LE
MT UMS FT
LE
UMTSCCA
UMTSCC
B-ISDNCCA
B-ISDNCC
B-ISDNCC
B-ISDNCCA
Figure 3.4: Call Control Entities in a Fixed-Mobile call
A UMS can also be included in the RAS, to support mobility within the RAS. Figure 3.5 details a
physical architecture where a Cell Site Switch(CSS) is used to support local switching in the RAS. The
CSS can then be extended to support mobility by the addition of a UMS. Unlike the UMS attached to the
LE in the core network, The UMS in the RAS will not be involved in UMTS call control but only provides
any support necessary for handover and interworking in the RAS.
3.3 Advanced Service Provision
The integration of Third Generation Mobile telecommunication systems with fixed networks will offer
unlimited mobility and a wide range of communications services [AGT93]. Current Fixed Networks offer
a wide range of services, such as call forwarding, voice mailbox, call waiting to the subscriber. As UMTS
is deployed, it will be expected to not only offer the same range of services as the fixed network, but it will
also have to cope with the mobility of the user and the terminal in the network. A set of mobility procedures
34
B-ISDN Backbone Network
MobileTerminal
TransitExchange
LocalExchange
Radio Access SystemRadioInterface
UNI NNI
UMTSMobilityServer
UMTSMobilityServer
Cell SiteSwitch
Figure 3.5: UMTS Architecture, UMS in Core and Access [Del95d]
must be adopted, such that UMTS is capable of delivering services to the user anytime, anywhere.
As a user roams in the system, the user’s location is tracked so that services may be delivered to the
correct location. Also a record of the user’s terminal type and capabilities must be maintained. All terminals
will not have the same set of capabilities and so care must be taken to ensure that, for example, no attempt
is made to invoke a video service for a user using a voice terminal.
In the course of a day as a user moves from home to work he can be expected to roam between different
UMTS environments. Possibly he will invoke services on a range of terminals, for voice, video, fax and
Internet services. In each environment there may exist different network operators and service providers,
offering a range of services and capabilities, to whom the user and terminal must be authenticated. Some
mechanism must be used to ensure the easy exchange of data between the user and the network and between
different network operators and service providers to provide for the easy tracking and delivery of services
to the UMTS user.
Intelligent Network techniques are used to support a wide range of services in the Network and to
facilitate the easy introduction and modification of new and existing services. The key principle of Intelli-
gent Networks is the separation of the software that controls basic switching functionality, such as setting
up switch parts, from the software that controls call progression. This allows more advanced features to
be rapidly introduced [Abe95]. More detail on the structure and capabilities of Intelligent Network are
contained in Annex A. The following sections describe the application of IN to UMTS.
3.3.1 IN and UMTS
Within UMTS, the provision of advanced user and terminal services using IN techniques is being investi-
gated by ETSI and the ITU. A number of mobility specific services have been identified for UMTS [Ric94].
• Session Handling Before a user or a terminal can invoke services in the network a session must be
established [Del96e]. There are two session types, a user session and a terminal session. A user
session is required when the service requires the agreement of the user, e.g. because they are being
charged for use of the service or because an incoming service involves personal delivery. A terminal
35
session is sufficient for procedures involving no user interaction or charging. Authentication is carried
out as part of the session procedure.
• User registration This procedure is invoked by the user to inform request the network to register the
user for a particular service on the current terminal. Location monitoring procedures are then used to
track the location of the terminal and user in the network. A user should be able to register on different
terminals for different services, hence the a mapping should be maintained between a terminal and a
user/service pair. The association between the user/service and the terminal is valid until and explicit
deregistration is performed. A User Session is required for user registration/deregistration.
• Location Update / Domain update Both of these procedures are part of location monitoring. UMTS
will consist of a number of service domains. Different service providers will offer UMTS services in
each service domain [Del95c]. As users roam between UMTS domains their user registration must
be updated so that they can receive services in the new domain. A UMTS system will contain many
service domains, which in turn contains a number of Location Areas (LA). The current location of the
terminal in terms of its domain and LA needs to be known prior to the delivery of a call to the mobile
terminal. The main purpose of location monitoring is to inform the network when a user has crossed
a location area or domain boundary. Also, location update may be initiated at specific time intervals
even though the user has not moved between location areas. Therefore these procedures are active
even though there is no call active and are often referred to as idle state procedures [CS96]. These
procedures come under the realm of call unrelated functions in Intelligent Networks. A terminal
session is sufficient for these procedures.
• Paging For delivery of a service to a user the Location Area (LA) must be known. However a LA may
be composed of a number of Paging Areas (PA). The most likely PA is determined algorithmically
determined using intelligent paging strategies [Gra97].
• Mobile Originating Call Handling. This is similar to call handling in the fixed network, except user
authentication and access rights procedures are more complicated due to security considerations on
the air interface. Also, unlike a fixed connection, the user does not have a permanent physical/logical
connection. A User Session is necessary for this procedure.
• Mobile Terminating Call Handling is similar to mobile originating call handling but has an extra
requirement, which is that the location and attachment point of the terminal must be determined,
before the call can be presented to the terminating user. This procedure needs the Paging procedure.
A User Session is necessary for this procedure.
• Attach / Detach The detach procedure temporarily detaches a terminal from the network and indi-
cates that the terminal is currently unreachable. The attach procedure is used to attach a previously
detached terminal. The attach/detach procedure can occur as a result of direct user interaction where
36
the user explicitly attaches or detaches, this involves using the Link Establishment procedure. Alter-
natively, the detach procedure can occur implicitly where the detach procedure is associated with the
Location Update procedure. For example, if a location update has not been received after a specific
period of time from the last location update, the terminal is automatically detached. The subsequent
attachment of the terminal is performed on the receipt of a location update. If a terminal is detached,
the Paging procedure is not initiated.
• Handover Handover is the most complex and important of all mobility procedures. Handover enables
the user to move within the network while in call and involves the reconfiguration of the communica-
tion channels. Handover enables procedures related to call handling to be for the most part ignorant
of the terminal mobility aspects of the call [Del95c].
3.3.2 IN Functional Model Enhancement for UMTS
The IN Distributed Functional Plane Model has been enhanced and extended to cater for UMTS specific
procedures. Figure 3.6 below presents the IN Functional Model for UMTS [NA696]
MCCF
TACAF
MSF
MBCF
MCF
SDF
SCF
SRF
SRBCF
CCF
SSF
BCAF
CCAF BCF
RACF
RBCF
Figure 3.6: IN Functional Plane for UMTS [NA696]
• Service Data Function(SDF). The role of the SDF is the data storage function in the system. It
includes functionality to store service and mobility related data such as location information or user
service profiles. The SDF must also be capable of interacting with other SDFs for the exchange of
user service profiles or security related data.
• Service Control Function(SCF). For UMTS the SCF contains the overall service and mobility con-
trol logic and handles services related processing activity. Service logic is invoked by service requests
from other functional entities to support location monitoring, paging, user registration, session han-
dling and in some cases handover.
37
• Mobile Storage Function(MSF). This is a pure data function located in the mobile terminal. It stores
subscription and service related parameters as well as location information, security parameters and
subscriber profile information.
• Mobile Control Function(MCF). The MCF contains the service logic and service related processing
required at the mobile terminal. It supports all mobile specific functions, such as location monitoring,
user registration, paging recognition and provides local service control.
• Mobile Call Control(MCCF). The MCCF is the agent between the user and the network call control
functions. It is equivalent to the CCAF and also includes call control adaptation functions due to the
radio interface.
• Bearer Control Functions(BCF, BACF, RBCF, MBCF). These functions represent B-ISDN and ra-
dio bearer control in the IN functional model and together with the CCF and the CCAF they represent
a call/bearer split in the architecture. These bearer control functions interact with the CCF, and CCAF
and are involved in the setting up of any necessary bearer connection elements in the fixed network
and to establish, maintain and release radio bearer connections in the radio access sub network and
in the mobile terminal.
• Terminal Access Control Agent Function(TACAF). The TACAF is responsible for the control of
handover at the terminal side. It interacts with the MBCF for initiation of radio bearer connections
during handover execution. The TACF is also responsible for the control of handover related func-
tions, e.g. switching and bridging, combining and multicasting.
• Radio Associated Control Function(RACF). This FE provides the control functionality required in
the radio access subsystem. Its role is to drive the actions to be performed by other FEs for radio
resource allocation, radio bearer setup and release. The RACF is also responsible for the supervisory
role needed for handover monitoring and decision phases and co-ordination between the RBCF and
BCF during handover execution.
• Call Control Function(CCF). The CCF represents the underlying network (POTS , ISDN , B-ISDN)
and contains call and connection handling for basic switching and bridging as well as triggers or
hooks for invocation of IN service logic.
• Call Control Agent Function(CCAF). This entity provides user access to the network and represents
the attachment of the user’s terminal equipment to the network.
• Service Switching Function(SSF). The SSF enables interaction between the SCF and the CCF; and
modifies call/connection processing as required by IN service logic.
• Specialised Resource Function(SRF). The SRF provides specialised resources required for the ex-
ecution of IN services. It may also contain logic to send, receive and translate user information.
38
The application of IN techniques to UMTS provides a framework for the fast development and deploy-
ment of new mobile specific services. A number of enhancements are needed in the IN model to cater
for mobility. To support mobility in IN a UMTS specific Functional Plane has been developed by ETSI
[NA696]. This includes extra functionality needed to control the handover of bearers in the switching net-
work. Extra functionality is also included in the terminal and the network for the tracking of the user’s
location.
3.4 Support for multiple Air Interfaces
UMTS will be deployed in Europe in parallel to existing mobile telecommunications infrastructure and
systems such as GSM900 and GSM1800. As well as supporting new feature-full air interface techniques,
UMTS should also provide an easy migration path for existing technologies. One very important aspect of
this is the ability to support new and existing air interface access systems using a common infrastructure
and network architecture.
The UMTS network system can be seen as being made up of a number of parts, an Access Network a
Core Network and a Service Network [BCM+97].
AccessNetwork
CoreNetwork
Service Network
Figure 3.7: UMTS Network Architecture [BCM+97]
• The Core Network part, likely to be B-ISDN, encompasses the majority of the switching functions.
• The Access Network Part provides mainly radio related aspects, and in some cases local switching
functionality.
• The Service Network Part, likely to be IN provides network and user related services.
In identifying the best mechanisms for the support of multiple air interface access techniques two ap-
proaches have been proposed, concentrating on the access network and core network parts of the UMTS
system [BCM+97].
39
3.4.1 Access Network Proposal
The access network proposal addresses the access network part of UMTS and views UMTS as a wireless
access network providing wide area coverage and giving transparent access to different core networks. The
access network radio network architecture comprises of a radio interface and a minimum amount of network
elements able to deliver UMTS radio functionality. This Generic Radio Access Network (GRAN) is directly
connected to a core network, offering the services of the core network over the air. If the core network is
a UMTS core network then the full set of UMTS services can be delivered. The main goal of the access
network concept is to offer broadband, wireless services to the users of various core networks.
Figure 3.8 details the access network concept. The UMTS core network comprises a web of new and
existing networks, such as B-ISDN with mobility support or the GSM network. The UMTS Radio Access
System is comprised of an innovative interface able to deliver the bearer and service capabilities required in
UMTS, and is currently being standardised within ETSI [ETS96]. This approach allows for the coexistence
of UMTS and existing second generation systems, as well as providing a possible evolution path towards
UMTS.
UMTSGenericRadioAccessNetwork
UMTS Radio Access Part(s)
GSM IWF
GSM
N/B-ISDN IWF
N/B-ISDN
Internet IWF
Internet
Figure 3.8: UMTS - Generic Radio Access Network view [ETS96]
Messages crossing the GRAN interface are related to call and bearer handling, service control, terminal
and user mobility management. Connection to the various core network is performed by Interworking
Functions (IWF) in the access network. However, the GRAN must be designed to work optimally with one
core network, it cannot be designed to work optimally with all possible networks. The network of choice
for this would be B-ISDN, as B-ISDN will be the network of the future and will support the same flexibility
in service creation and deployment as UMTS. Any other design for optimality, e.g. the GSM core network,
would underutilize the service and bearer elements of UMTS and would therefore not justify the design and
development of enhanced radio access mechanisms.
3.4.2 Core Network Proposal
The core network Approach proposes a generic interface between the UMTS core network and the different
Radio Access Subsystems(RAS). This approach centres around the development of a generic core network
40
for UMTS embodying all the functions needed to
• Ensure compatibility with expected evolution of the fixed network
• Supply the innovative features associated with third generation systems, e.g. wide-band and variable
bit rate connections, advanced mobility management connections.
• Provide for different transport and control mechanisms required in the core network by the innovative
radio access techniques, e.g. resource allocation.
The core network Concept is illustrated in figure 3.9 below. A single generic UMTS core network is
assumed, with differing radio access systems connected to the core via a generic interface. This structure
provides the ability to connect different radio access module into the same network infrastructure, allowing
for both the introduction of new and innovative air interface techniques. This configuration can also facili-
tate the evolution of second generation systems towards UMTS by permitting the reuse of second generation
base systems and mobile stations [VSB+97]
GSM Access Adaptation
GSM Radio AccessPart
DECT AccessAdaptation
DECT Radio AccessPart
UMTS Radio AccessPart(s)
UMTS Generic Core Network
UMTS Radio AccessPart(s)
UMTS Radio AccessPart(s)
Figure 3.9: UMTS - CORE Network view [BCM+97]
One of the main impacts of using a single generic interface in figure 3.9 concerns the use of access
adaptation functions in the RAS. Assuming that any new UMTS radio access subsystem will be designed
for the generic interface, then adaptation functions are only necessary for the 2nd generation subsystems.
Support of the generic interface requires the identification of a common set of functions across all radio
subsystems facing that interface. In general, a split can be made between those functions supporting the
generic interface and those functions which embody the radio features of the particular deployed radio
access part and so cannot be represented in a generic manner.
In effect a split can be identified between the radio independent parts of the RAS and the radio dependent
parts. The former supports the generic interface and the latter represents the particular features of the
deployed radio access part [BCM+97].
The identification of a radio independent/radio dependent split allows for the extension of the modular
concept of UMTS into the radio access system. It enhances the flexibility in both using new and innovative
access techniques and reusing functions and nodes of the access part of evolving second generation systems.
The division of network functions as radio independent and radio dependent is discussed in the next section.
41
3.4.3 A unifying view and common interface
Both ITU and ETSI studies[ETS96],[IT96] highlight the need for a clear split between the radio access and
fixed network subsystems of future mobile system architectures and identify the relevant border for defini-
tion of a standardised interface. Adoption of a standardised interface also provides support for increased
modularity in the system. It is not should be necessary to modify the access segment each time access to a
new core system has to be introduced, as in the access network view.
The two different views of UMTS supported by the core and access network views are not complimen-
tary as they do not define the same interface between the core and access segments of UMTS. It is desirable
that evolution of UMTS take place based on the definition of a single interface between the radio access part
and core network part. The next sections reconcile the differences of the access network and core network
views through, the identification of a common interface, the radio independent/radio dependent concept and
support for evolution of 2nd generation systems.
Identification of a common interface
The adoption of a common interface between the core and access networks is proposed in [BCM+97]. This
interface, denoted the Iu interface is intended to provide a single standardised interface between the core
and access networks.
The current access network and core network views of UMTS are not compatible as regards the location
of a common interface. The core network view considers a single interface between the Core and Access
segments of UMTS. The access network view, however considers multiple interfaces between different core
networks and a single Generic Radio access network. Within the GRAN adaptation to each of the different
core networks is carried out by the UMTS access segment.
The GRAN Access segment can then be further broken down into a number of core network adaptation
functions plus one or more Radio Access Parts encompassing an innovative air interface. If the adaptation
functions associated with the GRAN are considered to be network-driven then it is possible to derive an
interface which separates the Core Networks + Adaptation Functions from the remaining Radio Access
Parts.
This separation of core and access segments harmonizes the access network and core network views
of UMTS. The Iu interface can now be identified, separating the core and access networks as illustrated
in figure 3.10. The network adaptation functions are now defined between two standardized interfaces, the
existing core network interfaces and the new common interface. Furthermore the GRAN can be redefined to
encompass the Radio Access Part only. This allows the GRAN to model the UMTS innovative air interfaces
as envisioned by the core network view.
42
GSM
GSM NetworkAdaptation
Internet
Internet NetworkAdaptation
N/B-ISDN
N/B-ISDN NetworkAdaptation
UMTSGenericCoreNetwork
UMTS Generic Radio Access NetworkGSM
Access PartDECT
Access Part
GSM Access Adaptation DECT Access Adaptation
Iu Interface
Figure 3.10: Identifying a common access/core interface [BCM+97]
Radio Independence in the RAS
Section 3.4.2 illustrated how a radio independent/radio dependent split can be adopted using the core net-
work view, based on a single generic interface and a set of access adaptation functions in the RAS. This
generic interface is now identified as the Iu interface and the UMTS radio access parts can be identified as
corresponding to the modified GRAN from the access network Proposal.
The radio independent functions can be seen as adapting between the comparatively error-less, high
bandwidth fixed network and the more error-prone, band-limited radio transmission part. In addition each
physical radio access system will require its own adaptation to the radio independent part. The UMTS radio
access segment can then be modelled as a radio independent part which interfaces to the Iu interface, a radio
access subsystem and any radio dependent functions needed to interface between the two. This architecture,
presented below in figure 3.11, is extremely modular and flexible, and is open to many different innovative
radio access techniques.
43
UMTS GRANRadio Independent Part
t
GSM
GSM NetworkAdaptation
Internet
Internet NetworkAdaptation
N/B-ISDN
N/B-ISDN NetworkAdaptation
UMTSGenericCoreNetwork
GSMAccess Part
DECTAccess Part
GSM Access Adaptation DECT Access Adaptation
Iu Interface
UMTS GRANRadio Dependent
Part #1
UMTS GRANRadio Access
Part #
UMTS GRANRadio Dependent
Part #n
UMTS GRANRadio Access
Part #n
Figure 3.11: Radio Independence in the GRAN [BCM+97]
Evolution from 2nd generation systems
The uniqueness of the Iu interface implies that a variety of possible core networks can be compatible
with the proposed arrangement. This allows for different evolution paths towards UMTS from both the
Core Network and Radio Access parts, allowing existing and innovative radio access systems to connect to
existing and evolved core networks. provided that each comply with the common interface.
Previously in the core network view, 2nd generation systems were modelled as a radio access part and
an Access Adaptation part to a generic interface. Considering that each physical radio access technique
needs its own adaptation to the radio independent part then it is also possible to model existing 2nd gen-
eration systems as consisting of a radio access part plus radio dependent adaptation to the identified radio
independent functionality in the RAS. Thus the GRAN concept can be extended to include 2nd generation
radio access systems as illustrated in figure 3.12 below. In the case where a GSM radio access part connects
to a GSM core network then no adaptation is necessary. This extension of the GRAN to be generic for
all radio types, existing or innovative, can be used to drive GSM/DECT convergence with UMTS from the
Radio Side. In other words this model allows for the preservation of much of the existing 2nd generation
infrastructure within UMTS.
44
GSM InternetN/B-ISDN
Iu Interface
UMTS GRANRadio Dependent
Part #1
UMTS GRANRadio Access
Part #1
UMTS GRANRadio Dependent
Part #n
UMTS GRANRadio Access
Part #n
UMTS GRANGSM Radio
Dependent Part
GSMRadio Access
Part
UMTS GRANDECT Radio
Dependent Part
DECTRadio Access
Part
UMTS GRANRadio Independent Part
t
GSM NetworkAdaptation
Internet NetworkAdaptation
N/B-ISDN NetworkAdaptation
UMTSGenericCoreNetwork
Figure 3.12: Generic UMTS Architecture [BCDH96]
3.4.4 Generic UMTS Network Architecture
The ACTS Rainbow project [BCDH96] has adopted a generic network architectures for UMTS [Del95b].
This architecture comprises both IN and B-ISDN functionality. It also supports the separation of the core
and access networks using a standardised interface as defined in [Del96b]. Figure 3.13 below presents the
reference configuration for the UMTS Network.
MSCP
UMS
B-ISDNTransit
Exchange
B-ISDNLocal
Exchange
UMS
MSCPMSCP
CSSBTS
BMobile
Terminal
UMTS Access Network UMTS Fixed Network
ATMSignallingNetworkIu
Interface
BTSA
BTSC
Figure 3.13: UMTS Network Architecture [Del96b]
The Mobile Service Control Points(MSCP)s represent the Physical Plane architecture of the IN Dis-
tributed Model described in section 3.3.2. These contain the SCF, RACF, SDF and are the control points
for handover and mobility management in the core and access networks. The underlying call and bearer
support is provided by B-ISDN, with the UMS in the core and access implementing the required mobility
45
support for transport.
A radio independent/dependent division is utilised in the UMTS access network. This supports the sue
of different radio access technologies using a single access network infrastructure. Figure 3.14 below shows
the division between radio independent and radio dependent parts in the UMTS Access network.
MSCP
UMS
CSS
UMTS Access Network
DECTBTS
GSMBTS
UTRABTS
DECTMT
GSMMT
UTRAMT
Radio Independent Functions
Radio Dependent Functions
Figure 3.14: Radio Independent/Radio Dependent Division in UMTS Access Network
The BTSs contain the functionality needed to access the different radio interfaces and as such are fully
radio dependent. The MSCP and UMS support functions and procedures which are common across all
radio access technologies and so are radio independent.
3.5 Conclusions
This chapter has examined the technologies and concepts necessary to support a flexible adaptive UMTS
Network.
The Broadband Integrated Services Digital Network is an advanced transport mechanism which can be
utilised to provide flexible and adaptive switching and transport services in UMTS. However, B-ISDN does
not provide support for mobile services and so this chapter has described a number of modifications and
extensions to B-ISDN to allow the better integration of B-ISDN with UMTS.
The B-ISDN UNI must be extended to allow the MT to address network entities in the UMTS Access
Network, other than the Local Exchange. Furthermore during handover it will be necessary to support
multiple redundant branches in a call so that simultaneous switching between them can be performed. Also
transcoding and interworking functions must be provided in the network for voice and data services.
It is desirable that the modifications to B-ISDN to cater for UMTS do not place any large requirements
on the B-ISDN standards. For this reason, a UMTS Mobility Server has been introduced to fulfil the mo-
bility requirements placed on B-ISDN. The UMS provides extended call control capabilities in the UMTS
46
access network, including support for handover of connections. It also provides transport functions such as
transcoding and interworking.
The Intelligent Network is utilised in UMTS to provide a flexible architecture for the development and
deployment of UMTS services. As with B-ISDN the IN model must be extended to cater for mobility. This
chapter has presented an IN architecture for use with UMTS and detailed the types of services for which IN
will be required in UMTS.
The support of multiple air interfaces is a core concept in UMTS. It is essential that a flexible network,
capable of supporting any number of air interfaces is adopted. Two proposals have been examined in this
chapter. The Generic Radio Access Network concept proposes that use of a different radio access networks
for UMTS, containing interworking functions to different core networks. In essence UMTS becomes a
”plug-in” access network to any existing or new core network.
The UMTS Core Network concept proposes the use of a single core network for UMTS. This core
network is capable of supporting any number of radio interfaces without adaptations, so long as these radio
systems conform to a standard interface between the core and access networks. The power of the Core
Network concept when compared to the GRAN is that in the GRAN concept every radio access system
needs to be interworked to every core network type, whereas in the Core Network concept each radio
access system need only be interworked to a single standardised interface.
Combining the GRAN and core network concept yields a network architecture whereby the core and
access networks are separated by a standardised interface, the Iu interface. Any access network can then be
utilised with any access network as long as both the access and the core support the standardised interface.
This combines the best ideas of both proposals. It allows UMTS to be seen as a ”plug-in” access network
providing mobility in any network. At the same time the UMTS core network can support any number of
different radio access networks as proposed by the core network concept.
The flexibility of the UMTS Access Network is further increased through the adoption of a radio in-
dependent/radio dependent split in the UMTS Access Network. This split recognises that many of the
functions supported in the Access Network, such as call setup, are common across all radio access tech-
nologies. It proposes that a common set of protocols and functions be used, where possible in the access
network. Furthermore, it proposes that radio dependent functions and protocols should be isolated as much
as possible to the edge of the network, close to the radio interface. In this way it is possible to design
a UMTS access network such that much of the functionality and network entities can be used to support
multiple radio access technologies.
A generic reference for the UMTS access network model has been presented, incorporating IN and
B-ISDN techniques. In this model, the Iu interface has been adopted between the UMTS access and core
networks. The UMTS access network has been divided into radio independent and radio dependent parts.
The radio dependent functionality is isolated to the BTSs at the edge of the network. Radio independent
functionality is supported by the MSCP and UMS in the access network.
47
The next chapters describe the role of the Mobile Terminal in UMTS. The MT is involved in all network
functions, both radio independent and radio dependent. The following chapter describes the role of the MT
and the functions it performs in UMTS. Chapter 5 proposes a functional architecture for the MT and using
this architecture, analyses the MT to derive a radio independent/ radio dependent split for the terminal.
48
Chapter 4
Mobile Terminal Functions in UMTS
4.1 Introduction
The last chapter presented a number of concepts and technologies to be adopted in UMTS to provide a
flexible, modular system capable of delivering a wide range of services in a number of diverse environments.
This chapter looks at the role of the MT in the UMTS system. The MT is involved in almost all network
functions, either as an integral part of the system, e.g. the opening of bearers during call setup, or as a proxy
for the user, e.g. updating of user service information as part of domain update. The terminal architecture,
consisting of a control plane and a transport plane is presented. The control and transport functions present
in the MT are also described.
4.2 MT Reference Architecture
A reference architecture for the mobile terminal is presented in figure 4.1. The MT consists of a control
plan, which contains sytem control and transport contol functions and a transport plane which contains
transport functions.
49
MobilityControl Group Call
Control Group
TransportControl Group
BearerControl Group
HandoverControl Group
Service Adaptation Layer(SAL)
Mobility Adaptation Layer(MAL)
Radio Lower Layers(RLL)
Radio Adaptation Layer(RAL)
Signalling Network Layer(SNL)
Control Plane Transport Plane
Figure 4.1: MT Control and Transport Architecture
The mobile terminal control plane functions are divided into groups, each of which has a particular
focus i.e. mobility control, call control, radio control or transport control. Mobility control is IN based
and is concerned with tracking the movement of the terminal and the user in the UMTS Network. The
setup and control of calls is performed by Call control. Handover control is concerned with the handover
of active calls as the mobile roams in the network. The setup and control of radio bearers between the MT
and the network is the responsibility of Bearer Control. The control of transport functions in the MT, such
as segmentation and reassembly or switching and bridging is performed by Transport control.
Many of the control procedures in the control plane in the MT must communicate with peer functionality
in the network. Ideally functions in the MT and the network should be able to exchange signalling messages
without being concerned with the movement of the MT in the network. That is the transport of signalling
messages should happen transparently to the control plane regardless of the mobility of the terminal. Extra
functionality in the network is identified to allow the control plane functions in the MT to communicate with
peers in the network, regardless of their location or the network architecture. This functionality is provided
by the Signalling Network Layer(SNL), which provides location transparent routing for the transport of
signalling messages in UMTS [MLKN96].
The transport plane is concerned with the exchange of user and signalling data between the MT and the
Network. It consists of relatively dumb functions which manipulate data in a pre-defined manner. These
functions are managed by Transport control functionality in the control plane which activates or de-activates
transport functions as appropriate. The Transport plane is layered according to the services provided. The
are three main types of service: basic transport; mobility dependent/radio independent transport and service
dependent/mobility independent transport [FNA+97].
50
4.3 Control Plane Functions
Control plane functionality can be classified into a number of broad groupings, call control, mobility control,
handover control, bearer control and transport control as illustrated below in figure 4.2. These groups
interact in the terminal to allow for user and terminal roaming in the network, setup and release of calls and
call-related bearers and to perform handovers on calls in progress. The following sections describe each of
the control groups in the MT and their relationships with the other control groupings and the transport plane
in the terminal.
MobilityControlGroup
CallControlGroup
TransportControlGroup
BearerControlGroup
HandoverControlGroup
Figure 4.2: Control Plane groupings in the MT
4.3.1 Mobility Control Group
Unlike traditional telecommunications, a mobile user is not tied to a specific telephone line, mobile terminal
or network attachment point. Mobility control procedures are involved with interrogation or modification
of user and terminal related information in the network. Section 3.3.1 identified a number of mobility
procedures to be implemented in UMTS. These procedures are used to keep track of the user’s location in
the network and the services for which the user is registered. Mobility control in the terminal is responsible
for handling the terminal based information and decision making involved in these procedures. It is directly
equivalent to the combined functionality assoicated with the MSF and MCF identified in figure 3.6. Mobility
control in the terminal interacts with the network and is responsible for the following functions.
Data and Address Storage
One of the main functions of the mobility control group is the storage and maintenance of both user and
terminal related data. User related data stored on the terminal concerns the current state of the user in the
network; which services the user is registered for, what encryption keys are in use and so on. Terminal
51
related data is assigned/deassigned as the terminal roams in the network or when the terminal enters or
leaves the network. This information used to identify the terminal in the network, encryption keys related to
the terminal and information on the location of the terminal in the network. Much of this data is interrelated
and may be updated at the same time, e.g. as the terminal moves in the network the terminals location will
change and its address and/or encryption keys may also be updated by the network.
Some of the major identifiers used in the MT and their descriptions are given in table 4.1 [Del96e]
Identifier Description Source
International Mobile Identifies the user to Read from SIMUser Identifier (IMUI) the network. Can indicate
users home networkService Identifier Identifies a service Read from SIM
(SI) offered by the networkTemporary Mobile Identifies the terminal DynamicallyTerminal Identifier in the network allocated by
(TMTI) networkLocation Area Identifies the Terminals Broadcast byIdentifier (LAI) current location network
Domain Identifies the Current Broadcast byIdentifier (DI) Service Domain network
Table 4.1: Major Identifiers used by Mobility control in the MT
Session Handling
A terminal session can either be network or terminal initiated. Terminal initiated sessions are setup by
mobility control in the terminal when the user or the terminal need to gain access to the network, e.g. for
user registration or domain update or to make an outgoing call A network initiated session is setup by the
network, allow for delivery of incoming services with personal delivery to the user, e.g. for an incoming
call or message. An information flow describing Session Setup between the MT and the Network is given
below in figure 4.3.
Mobile Terminal Network
SessionSetupReq
SessionSetupResp
MobilityControl Group
MobilityControl Group
[IMUI, SI]
Figure 4.3: Information flow for Session Setup
The MT sends a SessionSetupReq message to the network. This message contains the user identifier
and the service type to be invoked. The service type may indicate that the user wishes to regioster/deregister
52
for a network service, or that the user wishes to make a UMTS call. The network determines if the user is
allowed to invoke this service and responds with a SessionSetupResp message.
User Registration
The network must be informed of the user’s location so that it is able to deliver incoming services to the
user. A user registration procedure is used to inform the network of the user’s current location and the
services which the user wishes to have delivered to that location. Before a user can register for a service,
the capabilities of the terminal to handle the particular service must be checked, e.g. a video service cannot
be handled on a voice phone. Mobility control in the terminal then interacts with the network, which checks
that the user is allowed to invoke that service in the network. If user registration succeeds then the network
updates it’s internal information on the users location for the registered service. The User Registration
procedure is illustrated in figure 4.4.
Mobile Terminal Network
UserRegistrationReq
UserRegistrationResp
MobilityControl Group
MobilityControl Group
[IMUI, SI, TMTI]
Figure 4.4: User Registration Procedure
A UserRegistrationReq message containing the user identifier, user’s current location and the service to
be registered for is sent to the network. The network confirms that the user is allowed to register for the
specified service and update its user related data to reflect the location of user and the registered service.
The network then replys to the MT with a UserRegistrationResp message.
When a user no longer wishes to user a service in the network, then a user deregistration procedure is
invoked. As a consequence of this the user related data in the network is updated so that the service is no
longer delivered to the user at the specified location.
Location Update
As the terminal roams in the network, it must inform the network of its location. This is done in response to
the terminal changing location area in the network. As the terminal moves in the network, it receives LAIs
which are broadcast by the network which tells the MT what location area it is in. Whenever the terminal
changes location area; the received LAI will also change. The MT then initiates a location update, informing
the network of it’s location. The network, may return a new TMTI to the terminal when acknowledging
the update. Normally the location update should also occur periodically, e.g. every 15mins in GSM. This
53
allows the TMTI to change rather frequently, as a security precaution, and also allows the network to know
which terminals are active in the network. Location Update is illustrated below in figure 4.5.
Mobile Terminal Network
LocationUpdateReq
LocationUpdateResp
MobilityControl Group
MobilityControl Group
[TMTI, LAI]
[TMTI]
Figure 4.5: Location Update Information Flows
A LocationUpdateReq message containing the MT’s TMTI and the new LAI is sent to the network. The
network updates the location of the MT and may allocate a new TMTI. The network replys to the MT with
a LocationUpdateResp containing the TMTI.
Domain Update
When the terminal roams into a new service domain, for the user to access services in the new domain then
the user related information in the network must be updated. The domain update procedure has two parts as
shown in figure 4.6. First the user must gain access to the network. Then the user registration information
in the network must be updated. A new TMTI is allocated to the terminal, for use in the new domain, as
part of this procedure.
Mobile Terminal Network
AccessReq
AccessResp
MobilityControl Group
MobilityControl Group
UserReRegistrationReq
UserReRegistrationResp
[IMUI, DI]
[TMTI]
[IMUI, TMTI]
Figure 4.6: Domain Update Procedure
An AccessReq message is sent by the MT containing the user identifier and the domain identifier of
the new domain. The network confirms that the user is allowed enter the new domain and replys to the
MT with an AccessResp message. This message may contain a new TMTI for the MT. Following this the
MT sends a UserReRegistrationReq message to the network to reregister the user for services in the new
54
domain. When the reregistration procedure in the network is complete a UserReRegistrationResp message
is sent by the network to the MT.
4.3.2 Call Control Group
The call control group in the terminal, is solely concerned with the setup and management of calls. As
described in section 3.2.3, the parties involved in call control in the UMTS access network are the UMTS
call control functions located in the MT and the UMS. The call control group in the MT contains the
UMTS call control functionality, based on the B-ISDN call control agent [LdLGdV96]. It also includes
functionality to fulfill the requirements placed on B-ISDN signalling by UMTS, identified in section 3.2.3,
as they apply to the MT.
Support for Call and Bearer Separation
In standard B-ISDN access signalling [IT95] there is no difference between call and bearer control. This
means that the same messages are used for the control of the call and the related bearers, with simultaneous
set up of the call and the resources needed for the call [Tas94]. As a result bearers cannot be acted upon
independently in the B-ISDN UNI.
Support of call and bearer separation moves away from the view that the UNI is a dedicated link between
the terminal and the network. Instead the UNI can be seen as consisting as a call and one or more associated
bearers that can be manipulated independently.
As detailed in chapter 3, the UMTS access network, is made up of a number of different nodes and
entities, many of which maybe involved in a UMTS call. Even though the UMTS call control functionality
is located in the MT and UMS, there may exist no single network path over which to setup a bearer between
the MT and UMS. Also, during handover of a call, it is necessary to setup new bearers in the access
network for the transport of data between the MT and UMS. Rather than having to setup a new UMTS call,
and the associated bearers each time a handover needs to be performed; a single call control relationship
is maintained between the MT and UMS. Only the bearers that are associated with that call need to be
changed.
Call and bearer separation allows for the manipulation of different network bearer types involved in
the same call, while still maintaining a standard UMTS call in the access network. The call is translated
into the required number and types of bearers necessary to support the call, each of which can then be
setup independently. This is most obvious in the MT where, once a call has been negotiated, a number
of radio bearers may need be setup. As the UMTS call control is based on that of B-ISDN, then ATM
characteristics will be used to negotiate the call setup. These characteristics must then be used by the call
control functionality to setup the necessary bearers. Figure 4.7 below illustrates part of the call and bearer
setup in the MT. Bearers setup is triggered by call control as part of the call setup procedure.
55
Mobile Terminal
BearerControlGroup
Network
CallSetupReq
CallProceeding
BearerSetupReq
BearerSetupResp
CallControlGroup
BearerControlGroup
CallControlGroup
BearerSetupReq
BearerSetupResp
Remainder of Call Setup Procedure [Q.2931]
BearerOpenReq
BearerOpenResp
Figure 4.7: Call and Bearer Setup in the MT
A CallSetupReq message is sent to the network from the MT. This messages contains all the information
needed to describe the call including the called number, the ATM characteristics of the call and the MT
location. The network decides to accept the call and responds with a CallProceeding message. Call control
in the MT now instructs Bearer Control to setup the necessary bearers between the MT and the Network.
More than one bearer may be established to handle the call.
Hierarchy of calls and bearers in UMTS
To support call and bearer separation in UMTS, some means must exist to distinguish between a call and
a bearer. In the B-UNI separate call references and connection identifiers are used to indicate a given call
and its associated bearer [IT95]. The call reference is assigned by the call control function and uniquely
identifies the call, the connection identifier is used to identify the virtual circuit between the terminal and
the network.
In UMTS a number of bearers are likely to be associated with a call and these will change during the
lifetime of the call. While the call reference can be used to indicate the totality of the bearers making up
the call, the call control functionality must then be able to cope with the dynamic modification of bearers
during a handover. B-ISDN call control, contains no such functionality and so for compatibility reasons
it is desirable that UMTS call control does not allow such dynamic behaviour either. However it is still
necessary to have a mechanism which associates all the bearers constituting a UMTS call together.
The B-ISDN Connection identifier can be used to provide a mapping between the UMTS call and the
bearers making up that call [Del96c]. Each call has an associated call reference and connection identifier.
These are allocated as part of the call setup procedure and are static for the duration of a call. As bearers
56
are setup, a relationship is maintained between the connection identifier and the bearers. As handover
is performed and the bearers making up the call are changed, different bearers are associated with the
connection identifier.
For a Multimedia call with multiple data streams, multiple data paths may be needed between the MT
and the network [LdVMP97]. In this case each data stream can be seen as a separate connections in the
network. Extending the concept of a connection to refer to any independent data stream making up a call
yields the call-connection-bearer hierarchy illustrated in figure 4.8 below.
Call
Bearer
Connection
Figure 4.8: Call, Connection and Bearer Hierarchy
Call control in the terminal, needs to contain more than just a modified B-ISDN call control, while this
remains its main role, it must also cater for the additional requirements of UMTS regarding call and bearer
control. Call control is responsible for.
• Interacting with call control functionality in the network for the setup and control of UMTS calls.
• Maintaining a mapping between the call reference and the connections and bearers making up that
call. As handover is performed in the network, the relationship between bearers and connections is
updated.
• Mapping between ATM and other bearer descriptions. UMTS is based on B-ISDN call control func-
tionality, and as such calls are negotiated using B-ISDN and ATM service descriptors and character-
istics [LWF+97]. Call control must map between the B-ISDN service description for a call and the
underlying bearer type used in the MT to provide the same service.
• Initiating setup of the user plane and return of SAPs to the application.
4.3.3 Handover Control Group
Handover is the procedure of changing the radio connection in order to maintain the quality of the link be-
tween the network and the mobile terminal. This may involve a change in base station due to the movement
of the MT in the network, but may also be a change in radio bearers on the same base station.
There are different classifications of handover; based on their impact on the user, the type of switching
used, the initiator of the handover and the base station through which the handover is initiated [Del92].
57
• Seamless Handover. This is a handover in which no loss of information occurs.
• Non-Seamless Handover. In this handover, there may be a temporary interruption in the transmission
of data between the MT and the network and loss of information may occur
• Hard Handover. This is a handover where there is an abrupt switch between the old and new connec-
tion.
• Soft Handover. This is a handover where there is a state in which the MT is receiving information via
the old and new link simultaneously.
• Network Initiated Handover. In this handover the network monitors the quality of the active links.
It decides when a handover is necessary and takes appropriate action to perform the handover when
required.
• Terminal Initiated Handover. This is a handover where the MT decides a handover is necessary and
determines the base station to which the handover is to take place. The MT informs the network of
the decision and then both MT and Network cooperate to perform the handover.
• Forward Handover. This is a handover where all handover related signalling is through the new base
station, to which the MT is to handover. All control related interaction between the network and MT
is conducted through the new base station. In some systems, e.g. DECT, user data is transferred to
the new base station at the same time as control [ETS95b]. However this may occur before bearers
have been setup in the network to the new base station and so some data loss may result. In order to
ensure a seamless handover, the user plane should not be switched until the necessary bearers have
been setup in the network.
• Backward Handover. In this handover the MT and the network exchange signalling information
through the old base station. When the network has set up the necessary bearers to the new base
station, then the control and user plane connections can be transferred simultaneously.
In all the above cases, handover is controlled by the network. Terminal controlled handover is difficult
to implement. The terminal does not have a precise view of available network resources and topology and so
cannot manage resources on a network level scale. One second generation system, DECT, does implement
a portable part based handover mechanism [ETS95b].
Handover is not only relevant for user data, but also for signalling data. Even when no call is active
a signalling relationship can still exist between the MT and the network and handover may need to be
performed. However the transport and handover of signalling data has requirements and characteristics
which are separate to those of user data. These are discussed in section 4.4.
To be able to support many handover types in the mobile terminal, it is necessary to find a generic view
of handover which enables the MT and the network to provide for as many of the different classifications of
58
handover as possible. The handover classifications given above are not all mutually exclusive. It is possible
to have a forward hard handover, as in ATDMA [USM95] or a backward hard handover as in GSM [MP92].
Like wise different types of soft handover can be supported in different systems. CODIT [BSSE95] supports
a backward soft handover, while ATDMA can also support a forward soft handover [USM95].
The most pressing requirement for handover in UMTS is that it be seamless. Non-seamless handover
may be applied, for example, to speech services where very short interruptions may occur without any
significant degradation of perceived quality by the user. However for data transmission seamless handover
is required.
Assuming that the handover is terminal initiated, but network controlled; the next sections examine the
functionality needed in the MT to control a seamless handover in UMTS.
Handover in the MT
In the MT, the handover control group supports the initiation and execution of a handover in the terminal.
From the MT Point of view, the decision to perform a handover is based on the perceived quality of the
active radio channels. If the quality of an active radio channel drops below a predefined threshold, then a
handover needs to be performed. The procedures used during handover are quality monitoring, handover
decision and handover execution.
Quality monitoring
Quality monitoring is concerned with the gathering and processing of data on the quality and status of active
radio bearers. In the MT handover control functionality monitors the status of the active radio bearers used
in the terminal. If the quality of the active bearers is perceived to drop below a certain level then the
handover decision functionality in the MT will initiate a handover.
Handover Decision
When the quality of the active radio bearers begins to deteriorate the MT will decide if a handover is
necessary. The handover decision functionality in the MT will initiate a handover. First the MT selects
the best base station to handover to. Base stations may be selected according to relative signal strength
or according to user operator preferences stored in the MT. When the new base station has been selected,
the terminal initiates a handover in the network. This informs the network that the MT wishes to handover
to a new base station. The network selects the most suitable point of control for the handover and begins
to setup bearers towards the new base station [Gra97]. Once the handover control point is identified the
network returns a message to the MT indicating that the handover initiation is complete. An information
flow for handover initiation in the MT is given in figure 4.9
The MT sends a HandoverInitiationReq to the network. This includes information on the base station
to which the MT wishes to handover. When the network selects the point of control for the handover, a
59
Mobile Terminal Network
HandoverInitiationReq
HandoverInitiationResp
HandoverControl Group
HandoverControl Group
[BTS, ConnectionID,…]
Figure 4.9: Handover Initiation in the MT
HandoverInitiationResp is sent to the MT
Handover Execution
The first phase of handover execution in the MT, involves the setup of new radio bearers towards the net-
work. This is triggered by the receipt of a HandoverInitiationResp message in the MT. Simultaneously
bearers will be setup in the network towards the new base station.
As described in section 4.3.2 a call/connection/bearer hierarchy exists in the MT. As new radio bearers
are setup they will be associated with existing connections involved in the call. When the new bearers are
setup, they are not active. That is there is no data being transmitted or received on the new bearers. The
setup of new bearers is coordinated by the control group. As the handover control group does not know
which bearers are associated with which calls and connections and so cannot setup bearers or associate
them with connections. The handover control group must be able to invoke the functionality contained in
the call control group to setup bearers and associate them with calls and connections in the MT.
The second phase of handover execution concerns the actual transfer to the new bearers. This is per-
formed under control of the network. When the necessary bearers have been setup in the network; handover
functionality in the network instructs the MT to proceed with the handover. If the handover is a hard han-
dover, the bearers to the old base station are deactivated and the new bearers activated. The MT is then
transmitting on bearers towards the new base station.
If the handover is a soft handover then the bearers to the new base station are activated and the MT is
receiving and transmitting on both the old and new bearers simultaneously. The old bearers may be dropped
when the bearer quality reaches a predefined threshold or after a predetermined period of time.
The handover control group in the MT does not contain the functionality necessary to manipulate con-
nections and bearers. Instead it invokes services provided by the call control group in the MT to manipulate
the data streams in the terminal, and the bearers they are carried on. The call control group, having setup
the bearers and knowing which bearers are associated with which call and connection, is in the best position
to oversee the switching of data from one bearer to another for hard handover, or the simultaneous trans-
mission of data over multiple radio bearers for soft handover. Handover execution in the MT, for a hard
handover, is illustrated in figure 4.10
60
Mobile TerminalBearerControlGroup
Network
HandoverInitationResp
HandoverControlGroup
HandoverControlGroup
HandoverExecuteResp
BearerSetupReq
BearerSetupResp
BearerReleaseReq
BearerReleaseResp
CallControlGroup
BearerModifyReq
HandoverResp
BearerOpenReq
BearerOpenResp
BearerCloseReq
BearerCloseResp
HandoverExecuteReq
HandoverReq
SwitchResp
SwitchReq
TransportControlGroup
Figure 4.10: Handover Execution in the MT
When a HandoverInitiationResp message is received in the MT, the handover control group triggers the
setup of bearers to the new base station. Bearer setup is coordinated by the call control group, but the actual
setup of bearers is performed by the bearer control group in the MT. Sometime after the bearers have been
setup, a HandoverExecuteReq is received from the network. This triggers the switching of data from the
old to the bearers. The actual switching of bearers is performed by the transport control group, under the
control of the call control group. When the bearers have been switched, the old bearers are released and a
HandoverExecuteResp message is sent to the network.
Call Control and Handover Control interaction in the MT
As described in section 4.3.2, call control in the MT contains functionality to associate bearers with calls
and connections. Any modifications of these bearers is handled by call control. This functionality can be
used as a bridge between call and handover control [Del96c] in the MT. When the handover control needs
to setup new bearers, it invokes the connection and bearer modification functionality in call control. This,
in turn invokes the relevant bearer control functionality to setup the bearers. During handover execution
call control functionality to manipulate transport control in the MT is invoked by handover control.
While the handover control entity in the MT and its relationship with handover functionality in the
network, can be described in terms of IN [NA696], this is only true in terms of the exchange of information
and control needed for handover. Handover, is a mechanism for updating bearers involved in a call and
61
expressing handover solely as an IN procedure does not provide for this view. The links identified between
handover and call and bearer control in the UMTS IN Distributed Functional Plane (DFP) described in
section 3.3.2 do not take into account the call, connection and bearer model for UMTS presented in section
4.3.2. At the same time, the DFP is more concerned with inter-node relationships, than with relationships
internal to a node. In the DFP call and handover procedures can be effectively decoupled because the
relationship between them is not visible external to the MT, on the MCCF-SSF/CCF and the TACAF-RACF
interfaces.
A modified version of the UMTS DFP showing the MCCF and TACAF as linked entities is proposed
in figure 4.11. In this figure the TACF, which controls handover in the MT has access to the functionality
and services of the MCCF controlling the call and connections in the MT. In this way functionality required
for the setup and manipulation of bearers during a call and a handover is available to both the MCCF and
TACAF.
TACAF
MCCF
MSF
MBCF
MCF
SDF
SCF
SRF
SRBCF
CCF
SSF
BCAF
CCAF BCF
RACF
RBCF
Figure 4.11: A modified IN DFP for UMTS
4.3.4 Bearer Control Group
The bearer control group in the terminal handles the setup and release of radio bearers between the MT and
the network. Just as a UMTS call is made up of a number of connections, each of which are made up of a
number of bearers; so too can a radio bearer be subdivided into a number of constituent elements, as shown
in figure 4.12. Each of these elements is a radio channel. A radio channel represents an actual physical
radio link between the MT and the network. These can then be combined into the logical bearers, which
are visible to the call control group in the terminal.
62
Radio Bearer
Radio Channel
Figure 4.12: Radio Bearer, Radio Channel hierarchy in the MT
Radio Channel Types
A radio system will support multiple channel types. As well as the channels necessary to support transport
of user and signalling data, channels exist for paging, broadcast, access and control purposes. some common
channel types are [MP92] [Del95e] [Del95a].
• Traffic Channel (TCH) Used to carry user Plane information. Can be unidirectional or bi-directional.
• Dedicated Control Channel (DCCH) A Bi-directional channel, used to carry signalling information
between control Entities in the MT and the network, including signalling for the setup of Traffic
Channels.
• Random Access Channel (RACH) Used on the uplink, from the MT to the network, to request a
DCCH.
• Access Grant Channel (AGCH) Used on the downlink, from the network to the MT, to allocate
DCCHs
• Broadcast Channel (BCH) Used on the downlink to broadcast cell specific information, e.g. Loca-
tion Area Identifier.
• Paging Channel (PCH) Used on the downlink to page users on an MT
• Synchronisation Channel (SCH) Used on the Downlink for synchronisation purposes.
All the above channels, except for the DCCH and TCH are setup and allocated by the network and
are collectively known as system control channels. Bearer control in the MT must synchronise to these
channels and use them to gain access to the network for the setup and control of DCCHs and TCHs. The
procedures for accessing DCCH and TCH channels in the MT are described below.
Setup of a Dedicated Control Channel (DCCH)
The procedure used to setup a DCCH in the MT is shown in figure 4.13. When the MT wishes to setup
a DCCH, bearer control places a request for access on the RACH. The network allocates the necessary
resources for the channel. A reply is sent on the MT, on the AGCH, describing the radio resources available
for the MT to use as a DCCH.
63
Mobile Terminal Network
RACHReq
AGCHResp
BearerControl Group
BearerControl Group
[DCCH]
[Resources]
Figure 4.13: Setup of a DCCH using the RACH and AGCH
Setup of a Traffic Channel (TCH)
TCHs are more complex than DCCHs. There is only one type of DCCH in a system using a constant set of
resources. There may be many different types of TCH, each of which has a different description and uses
a different number of resources. TCHs are not allocated using the RACH and AGCH channels as these do
not have enough bandwidth to support the TCH description. Furthermore a radio bearer may be made up
of a number of traffic channels and it is more convenient to be able to send a single request to setup all
traffic channels making up a bearer, than to send individual requests for each bearer. For this reason setup
messages for traffic channels are transported over the DCCH. The setup of a radio bearer is illustrated below
in figure 4.14
Mobile Terminal Network
BearerSetupeq
BearerSetupResp
BearerControl Group
BearerControl Group
[BearerDescription]
[TCH1, TCH2, TCH3,…]
Figure 4.14: Setup of a radio traffic bearer in the MT
To setup a radio bearer, the MT sends a BearerSetupReq to the network. This message contains a
description of the TCHs needed to makeup the radio bearer. The network allocates the resources needed for
each TCH and sends a BearerSetupResp to the MT.
Call Control and Bearer Control in the MT
The setup of radio bearers in the MT is coordinated by the call control group. The call control group is
aware of the connections making up a call and of the bearers necessary to support those connections. As
connections are setup for the call, the call control group instructs the bearer control group to setup the
bearers making up the connections in the MT. The setup of bearers in the MT during call setup is shown in
figure 4.15 below.
64
Mobile Terminal
BearerControlGroup
Network
CallSetupReq
CallProceeding
CallControlGroup
BearerControlGroup
CallControlGroup
BearerOpenReq
BearerSetupeq
BearerSetupResp
[BearerDescription]
[TCH1, TCH2, TCH3,…]
[BearerDescription]
BearerOpenResp
[BearerID]
Figure 4.15: Bearer Setup during Call Setup in the MT
During handover the bearers making up a connection will change. The call control group requests that
new bearers be setup and then associates these bearers with existing connections in the MT. The old bearers
making up the connection are then released.
4.3.5 Transport Control Group
The bearer control provides for the allocation of radio resources needed by DCCHs and TCHs in the MT.
When the bearers and channels have been setup in the MT, they are not yet ready to be used for the transport
of data. First they must be activated. Activation of radio channels is one of the roles of the transport control
group in the MT.
As well as activation of radio channels, the transport control group is also responsible for the setup,
configuration and control of any transport plane functions which are tailored towards the radio bearers
and channels in the MT. Such functions include Segmentation and Reassembly (SAR) of signalling data
transported over a DCCH, or the multiplexing/demultiplexing of user data over one or more TCHs making
up a radio bearer. Other Transport Functions, such as switching and bridging during handover, or encoding
and decoding of speech data are also controlled by the transport control group in the terminal.
Call Control and Transport Control in the MT
The call control group plays a coordinating role for the activation of the transport in the MT. Once the
channels, bearers and connections making up a call have been setup then the transport plane can be activated.
The call control group instructs the transport control group to activate the transport plane. The activation of
transport plane in the MT is shown in figure 4.16
During a handover, new bearers will be setup in the MT. Depending on the handover type user data is
65
Mobile TerminalBearerControlGroup
TransportControlGroup
CallControlGroup
BearerActivateReq
[BearerID]
BearerOpenResp
[BearerID]
BearerActivateResp
Figure 4.16: Managing the Transport Plane for Call Setup in the MT
switched to the new bearers if it is a hard handover, or transmitted on both bearers simultaneously if it is a
soft handover. The call control group is responsible for the setup of bearers during handover and it instructs
transport control to execute the handover when the bearers have been setup in the MT. The transport control
group then instructs the transport plane to execute the handover. the interaction between call control, bearer
control and transport control groups during handover is presented in figure 4.17
66
Mobile Terminal
BearerControlGroup
TransportControlGroup
CallControlGroup
SwitchReq
[BearerID1, BearerID2]
BearerOpenResp
[BearerID2]
SwitchResp
BearerOpenReq
[BearerDescription]
BearerCloseResp
[BearerID1]
BearerCloseReq
[BearerID1]
Figure 4.17: Call Control and Transport Control during handover
4.3.6 Summary
The control plane in the MT contains mobility control, call control, handover control, bearer control and
transport control. Mobility control is concerned with the movements of the user and MT in the network.
The other control functions are concerned with the setup and maintenance of calls, connnections, bearers
and channels in the MT.
Call control is reposnsible for the setup of calls in the MT. As well as this, it is the main coordinat-
ing function in the MT. It coordinates the setup of connections and bearers during call setup and during
handover. Call control is also responsible for coordinating the manipulation of the transport plane.
Handover control supports handover of calls in the MT. It decides when a handover is necessary and
interacts with the network to initate and execute a handover in the MT. Handover control invokes the call
control coordinating function to setup bearers and to manipulate the transport plane during handover.
Bearer control sets up radio bearers and channels in the MT. DCCHs are setup to carry signalling data
to the network. Traffic channels are setup for the transport of user data. TCHs are aggregated together
to provide radio bearers to call control. Transport control is responsible for activating functionality in the
transport plane required during a call or a handover.
67
4.4 The UMTS Signalling Network Layer
Many of the control functions in the MT need to communicate with peer functionality in the network. This
section introduces the UMTS Signalling Network Layer (SNL) which is used for the routing of messages
between control functions in the MT and the network and discusses its role and impact in the MT.
4.4.1 Requirements on Access Signalling
UMTS has a number of unique signalling characteristics which need to be taken into account in signalling
in the access network[Del94b].
• Extend the B-ISDN UNI The UMTS access network will contain a large number of network nodes
and functionality. At present the B-ISDN UNI is not able to cater for the addressing of such nodes
andfunctionality in the access network. Some mechanism must be found to extend the B-ISDN UNI
to be able to address different nodes in the access network and to cope with the routing of messages
towards a, potentially large, number of terminals in the system [KS94]
• Support for a large number of environments As described in chapter 3 the UMTS environments
can differ significantly in the number of access network elements and interconnections. The UMTS
access network must be able to support different allocations of network functionality in a flexible
manner.
• Reuse of Fixed Network Protocols UMTS will reuse fixed network protocols, such as Q.2931 and
INAP in UMTS which are mobility unaware. To minimize modifications to these protocols a method
should be devised whereby mobile unaware protocols can be used without modification.
• Support for different cell sizes To achieve high system capacity and broadband services, UMTS
will employ micro and pico cells in some environments. Having a large number of cells will result
in a large number of handovers. A way to allow signalling associations to be maintained without
interruption by handover is required.
SNL Characteristics
To fulfil these requirements a Signalling Network Layer is included in the UMTS protocol stack in the
access network. The main features of the SNL are [MLKN96]
• Dynamic and Distributed routing To enable routing of messages, the routing information pertaining
to the MT must be constantly updated. A protocol has been devised which distributes the relevant
information to those nodes affected by the movement of the terminal.
68
• Location TransparencyLocation Transparency allows for the routing of messages towards control
functionality in the network, even if the physical location of that functionality is unknown. It allows
the MT to roam into different network environments and topologies.
• Connectionless Operation The SNL utilises a connectionless mode of operation. This is more robust
in dealing with changing paths to the terminal than a connection oriented mechanism as it is not
necessary to frequently release and establish signalling whenever the signalling point of attachment
to the network changes.
• Tree Topology The UMTS access network is typically tree structured. As a result there are no
alternative routes to the terminal and so no requirement for a mechanism to re-route messages due
to link failures or outages. As well as this functionality in the network can only communicate with
entities which in the sub-area ofthe tree directly below them, meaning that signalling messages are
only relevant in a particular sub-branch of the tree, and do not need to be routed out of the sub-
branch; but should be returned to the message originator. Furthermore mobile to mobile associations
are not allowed; these constraints greatly simplify the specification, operation and testing of the SNL
[MH96]
4.4.2 SNL Functions
The main function of the SNL is the routing of signalling messages between control functions in the ter-
minal and the network. In doing this the SNL must provide location transparency for the terminal in
accessing control functionality in the network so that free allocation of functions is supported. Also the
SNL must operate in a number of different network topologies, with the details of the topology and the
distribution of functions in that topology hidden from the upper layer protocols. In addition the SNL must
transport signalling messages to and from the terminal while hiding any mobile specific transport aspects
from the signalling applications. To achieve this,the following core functions have been identified for the
SNL [Mad97]
• Routing The SNL must be able to support routing of messages from the terminal to the network, from
the network to the terminal and between network entities. The only routing type which places any
requirements on the SNL is routing from the MT to the network. In this case it is not assured that the
destination address of the message is known explicitly. Implicit Addressing [Del93a] is supported by
the SNL so that messages may be directed towards functionality in the network even when the exact
location of that functionality is unknown.
• Routing Update As the MT roams in the network, its signalling point of attachment will change. The
SNL uses a simple protocol to update routing information in the network so that signalling messages
are routed to the MT through the correct point of attachment.
69
• Route Finding Route finding is used to locate the terminal when no active signalling association
exists between a signalling application in the network and in the terminal.
• Address Assignment To route messages towards the terminal and to update routing information
about the MT in the network; an address is allocated to the terminal by the SNL. This address is the
Temporary Mobile Terminal Address (TMTA) and is dynamically assigned so that the movement of
the terminal, and hence the users on it cannot be tracked over a large area [Del93a].
4.4.3 The SNL in the Mobile Terminal
Figure 4.18 below shows the position of the SNL in the MT [ZBGN97].
BearerControlGroup
Signalling Bearer Related Transport
HandoverControlGroup
CallControlGroup
MobilityControlGroup
Signalling Network Layer
Transport
Control
Figure 4.18: Positioning of the SNL in the MT [ZBGN97]
The SNL is a transport function in the MT and transports messages between the MT and the network.
The SNL transport function in the MT is quite trivial when compared with that of the SNL in the network
[Mad97]. This is because there is no routing decision to be made. There is only one possible path to route
outgoing messages; through the current point of attachment to the network. Incoming messages also require
no routing, only delivery to the correct signalling application.
The SNL in the MT interacts with bearer control for the setup and closing of DCCHs to transport sig-
nalling information. This can be a connectionless or a connection-oriented bearer. Using a connection
oriented bearer means that the SNL must explicitly establish and tear down the signalling link with the net-
work each time a signalling operation is complete, or each time the signalling point of attachment changes.
From the point of view of the SNL it is much simpler to use a connectionless radio bearer for the transport of
signalling messages [NBFM96]. This means that the SNL can simply deliver messages to the radio bearer
and not have to be involved in the control of the bearer.
This does not mean that the radio bearer itself is connectionless, but only the service offered to the SNL.
The decision to use a circuit-switched radio bearer or a packet-switched one that may be established and
torn down each time a message is to be transmitted, is then a choice for the underlying radio technologies
and bearer control. The SNL in the terminal, initiates the route updating procedure when the signalling
point of attachment to the network changes. When the SNL needs to send a message into the network, it
70
requests a Service Access Point(SAP) for a signalling radio bearer from bearer control. This SAP represents
the point of attachment in the network. A different SAP indicates that the point of attachment to the network
has changed and that route updating should be initiated by the SNL inthe MT.
To be able to route messages to the MT, the MT must have an address allocated to it by the SNL. This
address, the Temporary Mobile Terminal Address (TMTA) is allocated to the SNL when the SNL enters
the UMTS access network. The terminal is considered to be active in the network if there is a user session
active, or if there is a valid user registration present. User sessions and user registrations are maintained by
mobility control in the terminal, with which the SNL interacts to initialise the allocation or de-allocation of
TMTAs.
4.5 Terminal Transport Functions
The Mobile terminal must also provide for the transport of user and signalling data between the MT and
the network. The SNL has already been introduced as a mechanism for transporting signalling information
between the MT and the network. This section presents the ransport function necessary for the exchange of
user data with the network and the transport of both user and signalling data over the air interface.
Transport Functions, are grouped into layers, according to the services provided as illustrated in figure
4.19 below [Del96d]. The Service Adaptation Layer (SAL) provides the transport functions required for
the support of different services, e.g. source coding for speech or ARQ for non delay sensitive services.
The Mobility Adaptation Layer (MAL) abstracts the higher layers from any mobile specific features of the
lower layers by providing a set of mobility transparent services such as switching and bridiging during
handover. The Radio Adaptation Layer (RAL) provides access to the set of radio bearers provided by the
underlying radio layers. The Radio Lower layers (RLL) provide access to the physical radio channels at the
air interface.
Service Adaptation Layer(SAL)
Radio Lower Layers(RLL)
Radio Adaptation Layer(RAL)
Mobillity Adaptation Layer(MAL)
Figure 4.19: MT Transport Layers [Del96d]
71
Service Adaptation Layer
In contrast to current mobile telecommunication systems, UMTS will not be designed to support a specific
set of services. The SAL is a servide specific layer which offers the required transport capabilities to support
the whole range of third generation mobile services.
The most important service in mobile systems will remain the speech service [FEHD+98]. This service
is also important from a technical viewpoint for its typical charateristics and requirements: low delay,
synchronous service, moderate Bit Error Rate (BER) tolerated and speech coding function for the efficent
use of radio resources.
Other real time data services, such as MPEG, place even more requirements on the SAL. These services
have much in common with speech e.g. need for low delay and synchronous requirements. However, there
are some differnences; MPEG data, for example, is encoded end to end. Also the necessary BER for this
service is a number of magnitudes smaller than that for speech.
Another set important services is the support for unconstrained delay data services, such as WWW
running over TCP/IP. These services are quite different from the previous ones. High delays in transmis-
sion and delay variations can be tolerated. Also there is no need for synchronisation between source and
destination. To reduce the error rate, ARQ can be provided in the SAL to improve the perfromance of de-
lay insensitive services such as these and overcome the inherent assumption in many wired network based
trabsport protocol, such as TCP, that errored packets are due to congestion instead of unreliable links.
Mobility Adaptation Layer
The MAL performs those functions which are necessary to fulfil the requirements of the above services in
a mobile environment; while abstracting the SAL away from mobility aspects and functions of the lower
layers.
The functions and operations of the MAL do not change depending on the radio access scheme being
supported. Rather the MAL has to deal with the mobility features of the underlying system and abstarct
the higher layers away from those features. To do this the MAL provides a toolox of functions, to cater for
the different types of handover, which can be invoked to cater for the needs of the supported services. For
example, the MAL supports switching and bridging for hard handovers and combining and multicasting
functions for soft handovers [SFB+97].
Radio Adaptation Layer
The RAL provides a generic interface for the provsion of radio bearers for the transport of both user data
and signalling in UMTS. It utilises the specific channels of the services offered by the radio lower layers to
offer a set of generic services to the higher layers.
To support the transfer of signalling messages over the air interfaces a segmentation and reassembly
72
function (SARF) and ARQ are required for each DCCH. The SARF segments outgoing higher layer sig-
nalling messages into the segment size supported by the underlying radio specific layers. Incoming seg-
ments are reassembled by the RAL to construct signalling messages. ARQ is used to ensure the correct
transmission of each segment across the air inetrface.
The RAL offers only two bearer types to the higher layers, Real Time Data (RTD) and Unconstrained
Delay Data (UDD). While these are the capabilities provided on the service interface to the RAL, internally
in the RAL these services can be provided in different ways, depending on the capabilities of the particular
radio system. For the transport of user data the RAL supports different bearer functions, for CBR, VBR
and ABR data [SFB+97].
If packet access and Discontinous Transmission (DTX) are supported in a radio system an RTD service
becomes a real tine VBR service across the air interface requiring the bearer function for VBR. Similarly
if the radio system supports in call bearer modification then a UDD service becomes an ABR service
across the air interface. Figure 4.20 presents an overview of the RAL functions for signalling and user data
services.
The RAL also offers a multiplexing/demultiplexing service, although this is not visible to the higher
layers. As described in section 4.3.4 radio bearers can be up of more than one radio channel. The data
received on a radio bearer will then need to be transmitted over a number of radio channels. the multi-
plexing/demultiplexing function in the RAL provides for the transmission of a stream of data received on a
radio bearer over multiple radio channels.
RAL
SARFSARF SARFSARFSARFSARFSARF (M)BFabr(M)BFvbr(M)BFcbr
SignallingServices
RTDServices
UDDServices
SARF Segmentation and ReassemblyFunction
(M)BFcbr (Multi) Bearer Function for CBR
(M)BFvbr (Multi) Bearer Function for VBR
(M)BFabr (Multi) Bearer Function for ABR
Figure 4.20: Overview of the RAL [SFB+97]
Radio Lower Layers
The RLL provides access to the radio channels supported by the underlying radio access sytem. It is
responsible for the transmission of and reception of information over the air.
4.5.1 Call Setup in the Transport Plane
Figure 4.21 presents the architecture of the MT showing the control plan and transport plane. The following
sections detail the interaction between the transport and control planes during call setup and handover.
73
MobilityControl Group Call
Control Group
TransportControl Group
BearerControl Group
HandoverControl Group
Service Adaptation Layer(SAL)
Mobility Adaptation Layer(MAL)
Radio Lower Layers(RLL)
Radio Adaptation Layer(RAL)
Signalling Network Layer(SNL)
Control Plane Transport Plane
Figure 4.21: MT Control and Transport Architecture
4.5.2 Call Setup in the Transport Plane
During call setup, once the channels, bearers and connections making up a call have been setup in the MT
they are activated by transport control. In effect this means that the relevant functionality in the transport
plane needs to be activated and associated with those channels, bearers and connections. Service Access
Points (SAPs) are used at the interfaces of each layer to identify the functionality in that layer associated
with the call, e.g. RAL SAPs are used to identify the functions in the RAL dealing with the radio bearers
making up the call.
Functionality in the transport plane is activated from the bottom up. That is the RLL is activated first,
opening the channels at the air interface. Transport control allocates an RLL SAP (or SAPs) to be used to
access the radio channels. Next the RAL is activated. The RLL SAPs are passed to the RAL so that it can
access the radio channels in the RLL. A RAL SAP is allocated by transport control, providing access to the
radio bearers making up the call. After this the MAL is activated and the radio bearers are aggregated into
connections making up the call. At this stage the bearer is setup and activated. All that remains is for the
SAL to be setup for use by the application. SAL activation is performed by the call control function. The
activation of the transport plane during call setup is shown in figure 4.22
74
Mobile Terminal
BearerOpenResp
[BearerID]
BearerActivateReq
[BearerID]RLLActivateReq
[RLL_SAP]
RLLActivateResp
RALActivateReq
[RLL_SAP, RAL_SAP]
RALActivateResp
MALActivateReq
[RAL_SAP, MAL_SAP]
MALActivateResp
BearerActivateRespp [BearerID]
SALActivateReq
[MAL_SAP, SAL_SAP]SALActivateResp
RLLRALMALSALTransportControlGroup
BearerControlGroup
CallControlGroup
Figure 4.22: Activation of the transport plane during call setup
4.5.3 Handover in the Transport Plane
Handover involves the setup of a new set of radio bearers in the MT. This means that a new set of function-
ality is used in the transport plane to support those bearers. If a hard handover is used then the exsisting
bearers must be deactivated before the new ones are activated. For a soft handover both bearers can be
active simultaneously. Figure 4.23 shows the hard handover procedure in the MT.
75
Mobile Terminal
SwitchReq
[BearerID1BearerID2]
RLLActivateReq
[RLL_SAP2]
RLLActivateResp
RALActivateReq
[RLL_SAP2, RAL_SAP2]
RALActivateResp
MALSwitchReq
[RAL_SAP2, MAL_SAP]
MALSwitchResp
BearerSwitchResp
RLLRALMALSALTransportControlGroup
HandoverControlGroup
CallControlGroup
BearerControlGroup
BearerOpenResp
[BearerID2]
HandoverReq
BearerOpenReq
RLLDeActivateReq[RLL_SAP1]
RLLDeActivateResp
RALDeActivateReq[RAL_SAP1]
RALDeActivateResp
BearerCloseResp[BearerID1]
HandoverResp
BearerCloseReq
Figure 4.23: Management of the Transport Plane during Hard handover
76
4.6 Conclusion
In the UMTS access network, the MT is involved in call setup, handover and mobility control procedures.
Ideally these procedures should be as generic and flexible as possible, and incorporate concepts such as
call, connection and bearer separartion, support for different handover types and be able to support different
radio systems. The Transport plane in the MT must also be flexible so as to be able to provide a wide range
of user services over differening radio systems.
To support these procedures and concepts, functionality has been identified in the terminal control
plane for call control, mobility control, handover control, bearer control and transport control. Call control
functionality plays a major role in the MT, only it knows the mapping between the connections and bearers
making up a call and contains functionality to manipulate them. It acts as a coordinater between the different
control functionality in the MT for the setup and manipulation of bearers and the transport plane.
Handover in UMTS is assumed to be network controlled. Handover control in the network allocates
radio resources to be used during the handover and controls the execution of the handover in the MT and
the network . The MT play a major role in deciding that a handover has to take place and deciding the
base station to handover to. Handover control in the MT does not contain the functionality necessary to
setup and modify bearers during handover. It involes call control functionality in the MT to perform these
functions. The IN DFP for UMTS has been modified to reflect the link between handover and call control
in the MT.
In the transport plane a layered approach has been used to group functionality used to manipulate user
and signalling plane data according to service, mobility and radio aspects. Service sepcific functions, such
as ARQ for delay insensitive services, are provided by the SAL. The MAL abstracts the higher layers away
from the mobility functions in the underlying system. However the MAL itself is not dependent on the
underlying radio system, instead it provides a toolbox of data manipulation functions which can be used to
support different types of handover. Tbe RAL utilises the services provided by the undeying radio system
to provide a generic set of bearers and functions to the higher layers.
The transport plane also incorporates the UMTS Signalling Network Layer, which abstracts the sig-
nalling applications of the control plane away from the signalling transport aspects caused by mobility of
the terminal.
In the next chapter, the control plane of the MT is further broken down into its constituent functions and
procedures and analysed in terms of radio independence/radio dependence criteria. A design is feveloped
and presented for the MT with the aim of identifying the radio independnet/dependent boundary in the MT.
77
78
Chapter 5
MT Functional Architecture
5.1 Introduction
The UMTS mobile terminal is required to support many different radio access systems, each of which will
support different radio features and services. There will be a significant overlap in system features and
procedures, such as call setup or handover mechanisms which can be exploited to support a set of common
protocols and procedures across all radio access systems. In effect this means that it is possible to divide the
MT into two parts consisting of the general functions necessary in all radio access systems, and the more
specialised functions needed to support an individual radio access system.
Before the terminal functions can be divided into general functions and radio specific ones, a more
detailed architecture is required. The last chapter identified the role of the mobile terminal in the network
and characterised the major terminal functions. This chapter uses the Monet design methodology to refine
the previous models of the control architecture for the UMTS mobile terminal. It presents a more detailed
architecture for the terminal, by firstly deriving a set of functional entities and then detailing their roles and
relationships in the terminal.
Some system features, which can be classified as being common to all radio systems, are not required
in all radio systems. In particular the manipulation of data and the transport plane may be different from
system to system. To further increase the flexibility of the MT a control/transport split is also adopted in
the MT. This is used to identify those control functions most closely related to the transport aspects of
the system and which must be changed to support differing system features such as hard handover or soft
handover.
Those functional entities which support generic features are characterised as being radio independent.
Radio specific functions and services are performed by radio dependent functional entities. The interfaces
and protocols used between different FEs in the MT and between the MT and the network can also be
classified as radio dependent or radio independent. A radio independent interface which can be used to
79
separate the radio independent and radio dependent functions of the MT is identified.
5.2 Monet design Methodology
The Monet Design Methodology consists of seven steps as detailed in figure 5.1 below [Fle94].
Requirements
Functional Models
ArchitectureNetwork
Realisation
Logical Models
Reference Configurations
Functional Architecture
Figure 5.1: Monet Design Methodology [Fle94]
• Requirements. The inputs to the methodology are the operational and functional requirements which
reflect the needs of the UMTS system users; including end users, network operators and service
providers.
• Logical Models. Logical models are derived from the requirements. They identify, at a system
level, the services to be provided in the system. A logical model may consist of a number of service
providing logical entities which, like the logical models, are distribution transparent [Del94c].
• Functional Models. From each logical model a Functional Model(FM) can be obtained by taking
distribution into account. In the functional model, the logical entities from the logical models are sub-
divided into non-overlapping groups of functionality called Functional Entities (FEs)[IT97b]. These
FEs are combined into an FM and the relationships between them identified. Relationships between
FEs are described using information flows.
• Reference Configurations. A reference configuration is a combination of functional groups and
reference points that show possible network arrangements [IT88]. Reference configurations are used
to identify the entities in the functional architecture.
• Functional Architecture. A functional architecture defines the network entities of the system and
the functional interfaces between those entities. A network entity is a grouping of functional entities
and is an atomic unit of implementation [Del93b]. A functional interface exists between two network
80
entities when at least one pair of functional entities, having a relationship in the functional model is
mapped onto different network entities.
• Network Architecture. The network architecture partitions the system into physical entities, iden-
tifying and defining the physical interfaces between them. A physical entity is an atomic unit of
implementation and is always mapped onto a single piece of equipment. Multiple physical entities
can be implemented on a single piece of equipment.
5.2.1 Application of the Methodology
The Monet methodology has been applied fully in the RACE Monet Project to yield an initial functional
and network architecture for UMTS [Del95c].
Within ACTS Rainbow and for this thesis, the requirements and logical models have been adopted from
Monet and the remaining steps in the model applied anew. The main difference has been the use of different
reference configurations, than those applied in Monet. The applied reference configuration is presented in
section 3.4.4 and is further detailed in [Del95b].
Functional models, functional architecture and network architecture for UMTS have been developed in
the ACTS Rainbow project [Del96c]. Here, these models are expanded and applied to the Mobile terminal
and together with the terminal functionality identified in chapter 4, form the inputs for the specification of
the UMTS MT detailed here.
5.3 Identifying a Radio Independent Interface
Section 3.3 identified a Radio Independent/Dependent split of the UMTS Access Network. The aim of
this split is to decouple the radio interface from the fixed network aspects of UMTS, allowing both to be
developed and enhanced independently of each other [FEHD+98]
Achieving a high level of radio independence in UMTS can be achieved by pushing the Radio Depen-
dent aspects of the system as close to the network edge as possible, confining radio-specific components to
the MT and BTS [FNA+97]. In this way the MT can be modelled as consisting of separate radio dependent
and radio independent functionality. To maximise the radio independence of the MT, the radio dependent
aspects should be located as far down into the protocol stack as possible.
5.3.1 Defining Radio Independence
A functional entity is radio independent if it implements only general radio features and can be applied to a
number of radio techniques in a generic fashion. The entity is not replaced or adapted to support different
interfaces. Examples of general radio features, which may be categorised as radio independent include
call control, mobility control, and handover [DS98]. Some radio independent features, such as the use of
81
macrodiversity, use of forward or backward handover, are only used by a subset of radio technologies and
they are considered to be radio independent as they can be described and implemented in a common fashion
across the subset of radio technologies in which they are required [FNA+97].
A functional entity is radio dependent if it depends on the specific characteristics of the radio technol-
ogy. Radio dependencies exist based on the particular type of power control, resource allocation, control
channels, paging or multiple access strategy implemented in the particular radio technology.
5.3.2 Specifying a Radio Independent Interface
A message or protocol is radio dependent if it cannot be understood without knowing the radio technology
for which the message is intended. The name, structure and meaning of the messages depends on the
associated radio system.
For a message to be radio independent, the name of the message as well as the number and types of the
parameters must be standardised. The meanings of the parameter values may be radio dependent. That is a
radio independent message can be used to carry radio dependent information as long as that information is
described using standard, well defined information types.
Radio independent protocols must be used between radio independent FEs. They must also be used
between radio independent FEs and radio dependent FEs. Otherwise the radio independent FEs would
have to be to able interpret and understand different protocols and messages from radio dependent FEs in
different radio systems and so would no longer be radio independent. Radio independent protocols can also
be used between radio dependent FEs. That is the same protocol can be used between FEs in different radio
systems, even though the radio dependent FEs in each system will respond differently to the messages and
data in the protocol. Radio dependent protocols can only be used between radio dependent FEs in a single
radio system. So each radio system uses a different set of radio dependent protocols between the radio
dependent FEs in that system.
5.3.3 Constraints on a Radio Independent/Dependent Boundary
The radio independent/dependent boundary in the MT separates the radio independent functional entities
from the radio dependent ones. The interface between the radio independent and dependent parts must be
radio independent, so as to be understood by the radio independent FEs.
Use of a radio independent interface, limits the services offered by the radio dependent functional
entities. This is because it is not practical to define so generic an interface that it encapsulates the totality
of all available radio dependent services and characteristics. In any case a radio independent/dependent
boundary can only be defined in terms of the available and intended radio technologies for UMTS and their
respective feature and characteristics. So any radio independent interface defined for the UMTS Access
Network or within a node in the Access Network will provide only a limited number of services, described
82
in a generic standardised manner [FEHD+98].
This solution means, that even though the services offered to the radio independent entities, may not
reflect the full range of services supported by the underlying radio technologies; it will be relatively easy to
introduce new air interfaces into UMTS as long as they are able to support the standardised range of radio
independent services.
5.4 Control Transport Split
To further develop the architecture a division between control and transport functions has been used in the
design of the considered nodes [USM95]. In line with this division, transport functions are considered to
be relatively non-intelligent functions which manipulate data in a pre-defined manner, and can be grouped
into a hierarchy of layers. Typical transport functions are segmentation and re-assembly and buffering of
user data. These layers have been identified as the SAL, MAL, RAL and RLL in section 4.5.
In contrast, control functions encompass the intelligence of the nodes and the system. The control
functions can be split into two different categories. Firstly, there are the system control functions which
encompass call control, mobility control, handover decision, etc. The second set of control functions are
responsible for configuring and controlling the transport functions in the system and will be referred to
as transport control functions. These respond to stimuli from the system control functions and utilise a
transport/control interface to setup and modify the transport functions.
5.5 Functional Architecture
The control plane in the MT consists of groups of functionality performing call control, handover control,
mobility control, bearer control and transport control in the MT. Each of these groups can be further broken
down, using the Monet design methodology, to yield a set of functional entities in the MT. Figure 5.2 below
presents the functional architecture of the MT, where each of the control groups described in chapter 4 has
been broken down into its constituent functional entities. The following sections describe the individual
functional entities and their role in the MT. Each group is isolated and defined and in each case functional
entities from other groups with strong associations are identified. Furthermore the cardinality and direc-
tion of associates, in a client server sense, are identified and documented. This is not explicit in existing
documentation and is a prerequisite for later design and implementation.
83
AHT
RHTLMT SHTMSF
UCCA
RBC
SBC
TCCU
SHRU HC
LC
HUPU
HOCA
SNLC
SBE
RAL
MAL SNL
MEF
RC
HD
CMCAU
SAL
RLL
LEGEND
Mobility Management FEs
Call Management FEs
Handover Management FEs
Bearer Management FEs
Transport Management FEs
Transport Layers
Figure 5.2: MT Functional Architecture
AHT Access Handler Terminal TCCU Target Cells and Connections for UserAU Authentication User LC Link ControlLMT Location Management Terminal MEF Measurement Environment FunctionMSF Mobile Storage Function RBC Radio Bearer ControlRHT Registration Handler Terminal SBE Signalling Bearer EntitySHT Session Handler Terminal CMC Combining and Multicast ControlRC Resource Control SBC Switching and Bridging ControlUCCA UMTS Call Control Agent SNLC Signalling Network Layer ControlHC Handover Criteria MAL Mobility Adaptation LayerHD Handover Decision RAL Radio Adaptation LayerHOCA Handover Control Agent RLL Radio Lower LayerHUPU Handover User Profile User SAL Service Adaptation LayerSHRU Special Handover Request User SNL Signalling Network Layer
84
5.5.1 Mobility control FEs
Figure 5.3 below isolates the Mobility control FEs from the MT Functional Architecture.
RHT
SHT
AUMEF
LMT
AHT
MSF
UCCA
Figure 5.3: Mobility control FEs
Location Management in the Terminal. The LMT receives the latest location information broadcast
by the network via the MEF. It compares these with the location area identifiers and domain identifiers
stored in the MSF. When there is a mismatch it initiates the location update or domain update procedures.
Authentication User. The AU handles any authentication procedures initiated as part of user registra-
tion, session setup or domain update procedures. For simplicity, relationships between the AU, AHT, RHT
and SHT are not shown.
Registration Handler Terminal. The RHT controls the user registration and de-registration proce-
dures. It also handles the user re-registration part of domain update, under the control of the LMT.
Access Handler in the Terminal. The AHT handles the access part of the domain update procedure.
Session Handler Terminal. The SHT manages user and terminal sessions in the MT.
Mobile Storage Function. The MSF stores user and terminal related data in the MT.
Figure 5.4 below describes the associations between the mobility control FEs in the MT and the network.
There is a single instance of each FE in the MT. The LMT interacts with the AHT for the access phase of
the domain update procedure and with the RHT for the reregistration phase. The RHT interacts with the
SHT for the setup of a user session, prior to user registration. All user and terminal related data is stored in
the MSF.
During the Location Update procedure, the LMT interacts with the Location Update Handler (LUH) in
the network. The RHT and the Registration Handler(RH) interact for the user registration and reregistration.
The AHT, SHT and AU also have peer FEs in the network for the access procedures, session handling and
authentication. Thses are the Access Handler Network (AHN), the Session Handler Network(SHN) and the
Authentication Network(AN), respectively.
5.5.2 Call Control FEs
Call control FEs in the MT are identified below in figure 5.5
85
RHT
SHT
AU
MEF
LMT
AHT
MSF
AN
LUH
RHN
SHN
AHN
UCCA
Figure 5.4: Associations between Mobility control FEs
UCCA
RC
RBC
SHT
HD
HOCA
Figure 5.5: Call control FEs
UMTS Call Control Agent. The UCCA encompasses the UMTS call state model. It interacts with
Call Control in the network for the establishment of UMTS calls. In the MT the UCCA interacts with the
RC for the setup and control of connections and radio bearers. It interacts with the SHT for call related
session control. The UCCA also controls the activation and control of transport functionality in the SAL.
The UCCA is based on standard B-ISDN Call Control, with extensions to cope with mobility [LWF+97].
Resource Control. The RC provides a level of abstraction between the call control and the radio bearer
control. It models the aggregate of the bearers necessary to support a connection or multiple connections
involved in a UMTS call. It is responsible for translating the ATM description of a call into a form that can
be understood by the RBC for the setup of radio bearers.
The RC performs a coordinating role between call control, handover control, bearer control and trans-
port control in the MT. It provides services to the UCCA and to handover control for the setup and manip-
ulation of connections and bearers and the transport plane. As such the bearer setup and control functions
of the RC can be invoked by HD and the HOCA during handover. The RC interacts with the RBC for the
setup of bearers necessary during a call or a handover. When bearer setup is complete the RC triggers the
SBE and CMC for the activation and manipulation of the transport plane.
The associations between Call Control FEs are shown in figure 5.6 below. The UCCA offers services
86
for call setup and release to UMTS Applications in the MT. The UCCA intercats with the SHT for session
setup. The UCCA has a peer entity, the UCC, the call control functionality in the network. As part of call
setup, the UCCA invokes Resource Control to establish the connections needed in a call. The RC in turn
invokes the RBC to setup the required radio bearers. There is one RC associated with the call, and this
models the aggregate of the connections required in the call. There may be multiple RBCs, each handling
the radio bearers required for a single connection. The RC also interacts with transport control entities for
the activation of the transport plane. Services of the RC for manipulation of bearers or the transport plane
can be invoked by handover control FEs in the MT.
UCCA
RC
RBC
SHT
n
USERApplications
UCC
RBC
HD
HOCA
Figure 5.6: Associations between Call control FEs
5.5.3 Handover control FEs
The Functional Architecture for Handover in the MT is shown in figure 5.7.
MEF
RC
HD
TCCU
SHRU HC
HUPU
HOCA
Figure 5.7: Handover FEs
Target Cell and Connections User. The TCCU maintains an ordered list of potential target cells to
which the MT may move during handover.
87
Handover User Profile User. The HUPU contains the subset of the user profile relevant to handover,
such as QoS parameters, operator preferences and access rights.
Special Handover Request User. The SHRU provides a facility whereby a handover may be directly
forced by the user.
Handover Criteria. The HC contains the handover criteria used in the handover algorithm. Typically
this would contain Quality Thresholds which must be met before a handover takes place.
Handover Decision. In the MT the HD peforms the quality monitoring and handover decision proce-
dures. It uses the information provide by the MEF, TCCU, HUPU, SHRU and HC to decide if a handover
is necessary and to identify the target cell. When a HO is deemed to be necessary a handover initiation
message is sent into the network. When the network replies, the HD interacts with the RC for the establish-
ment of radio bearers necessary for the handover. Once the bearers have been established, control of the
handover is passed to the HOCA for handover execution.
Handover Control Agent The HOCA co-ordinates with Handover Control in the network for handover
execution. It manages the manipulation of radio bearers by the RC during handover.
Associations between the FEs involved in handover are shown in figure 5.8. There is one instance of
each FE in the MT. The TCCU uses the MEF to gather information on surrounding base stations. The
SHRU can force a handover on behalf of a user at any stage. The HD uses the services of the HUPU,
TCCU, MEF, and HC for information gathering purposes. The HD also uses the services of the RC to setup
new bearers required for the handover. The HD invokes the HOCA to control the handover execution in the
MT. The HOCA uses the RC to execute the handover between bearers in the MT.
The HD interacts with the Handover Decision in the Network (HDN) for the handover initiation proce-
dure. Handover Control (HOC) in the network controls the handover execution. It triggers the HOCA in
the MT during the handover execution procedure.
MEF
RCTCCU
SHRU HC
HUPU
HOCA
HD
HOC
HDN
Figure 5.8: Associations between Handover control FEs
Many of the handover control FEs are primarily concerned with data storage. A more object oriented
approach to MT functional architecture would see many of these FEs combined with the HD.
88
5.5.4 Bearer control FEs
Bearer control FEs and their relationships are illustrated in figure 5.9.
MEFSBE
LC
RBC
Figure 5.9: Bearer control FEs
Measurement and Evaluation Function The MEF monitors the status of the active radio bearers and
reports quality information to the HD. It also monitors the information broadcast by surrounding BTSs to
determine the relative strength of each BTS and to gather LAIs and DIs broadcast by each BTS. Information
on BTS strength is sent to the TCCU. Location information is sent to the LMT
Radio Bearer Control The RBC manages the setup of radio bearers for user traffic between the MT
and BTS. The RBC interacts with its peer for the allocation of resources for the bearers, by the network.
Signalling Bearer Entity The SBE manages the setup of radio bearers for signalling between the MT
and BTS. It interacts with its peer in the network for the setup of a logical signalling link to the BTS and
with the LC in the MT for the activation of a signalling channel, the DCCH, to the network. It is triggered
by the SNLC.
Figure 5.10 presents the association between bearer control FEs. Both the RBC and SBE invoke the
services provided by Link Control (LC) for the setup and control of radio channels in the MT.
MEFSBE
LC
RBCn
SBE
RBC
Figure 5.10: Associations between Bearer control FEs
5.5.5 Transport control FEs
Figure 5.11 below describes the Functional entities involved in managing the transport plane. Many of these
FEs are described in earlier sections.
SNL Control. The SNLC manages the SNL in the MT. It monitors the current point of attachment of
the MT to the network and triggers the SNL Route Updating whenever the point of attachment changes. The
SNLC interacts with the SBE to ensure that a signalling link exists for the transport of signalling messages
to the network.
89
Transport PlaneUCCA
RBC
CMC
SNLC
SBE
RAL
MAL
SNL
SAL
RLL
LC
SBC
RC
Figure 5.11: FEs for Transport control
UMTS Call Control Agent. The UCCA is responsible for the allocation of SAL SAPs and for config-
uring the SAL. It is abstracted away from the bearer and transport control functions by the RC. The UCCA
will setup and activate the SAL once all the connections and bearers making up a call have been setup and
activated. The UCCA has the same view of bearer setup as the standard B-ISDN call control [IT95]. That
is, connection setup is invoked as part of the call control procedure but the setup procedure is transparent to
the UCCA.
Switching and Bridging Control. The SBC controls the activation of functionality in the MAL and
the allocation of MAL SAPs. It is triggered by the RC once bearer setup is complete. For call setup, in
order to setup the MAL correctly the SBC needs to have a RAL SAP and so the SBC first instructs the
RBC to activate the RAL. Once the RAL has been successfully activated, the SBC activates the MAL. The
SBC maintains a mapping between MAL SAPs and the associated RAL SAPS. During handover the SBC
controls the switching of the data streams in the MAL. When a new bearer is setup, the SBC receives a
switch request from the RC. First the SBC instructs the RBC to deactivate the old bearer. The new bearer is
then activated and the data streams in the MAL are switched to the new bearer.
Combining and Multicast Control. The CMC performs a similar function to that of the SBC. During
handover, instead of switching between bearers, the MAL is instructed to multicast and combine informa-
tion on more than one active bearer.
Radio Bearer Control. As well as being responsible for the setup of radio bearers in the MT, the RBC
also activates the RAL for the handling of user data. As described in section 4.3.4 radio bearers are made
up of a number of radio channels. After the bearer setup procedure, the RBC knows the type and number
of radio channels needed to makeup the requested bearer. This information is used to request the setup of
radio channels by the LC and for the configuration of the multiplexing function in the RAL.
90
Signalling Bearer Entity. The SBE is responsible for configuring and managing the RAL for the
transport of signalling data between the MT and the network.
Link Control. Radio channel control is performed by the LC. It synchronises to the system control
channels broadcast by the network. In response to request from the RBC and SBE it activates the physical
radio channels used for user and signalling traffic.
Associations between transport control FEs are shown below in figure 5.12. The RC interacts with
the SBC or the CMC to setup and manipulate the MAL during call setup and handover. These in turn,
interacts with the RBC to activate and deactivate the RAL. The SNLC is and the SNL interact for the setup
of signalling links between the MT and the network. The SNLC in turn uses the services of SBE for the
establishment of DCCHs in the RAL for signalling. The LC is used by the SBE and the RBC to activate the
physical signalling and traffic radio channels. Only one the SBC and CMC will be present in the MT.
Transport Plane
CMC
SBCSNLC
SBE
RAL
MAL
SNL
SAL
RLL
LC
RBC
UCCA
RC
nn
Figure 5.12: Associations between Transport control FEs
91
5.6 Radio Independence of Terminal Functions
The majority of the functions in the control plane are radio independent, these represent the system features,
such as call control, mobility control and handover that are required in all radio systems. The SBC and CMC
represent system features that are needed only in a subset of radio systems that support forward or backward
handover, respectively. On the transport plane, the MAL and SAL are most abstracted from the radio system
and are also radio independent.
The radio dependent functional entities represent, for the most part the low level aspects of the radio
systems involved in radio bearer manipulation and channel control. These are the LC and MEF which must
be tailored for the particular radio channel structure of each radio system, the RLL which is manipulated by
the LC is obviously radio dependent also. The SBE and RBC interpret requests from the RC, SBC, CMC
and SNLC for radio bearers and interact with the LC to ensure that the correct type and number of radio
channels are established. The RAL must also be configured according to the different radio channel types
used and is hence radio dependent. The HC entity is radio dependent as it contains information specific to
each radio system.
When identifying the radio independent/dependent boundary in the MT, it is clear that the SBE, RBC
and RAL can be manipulated to offer a defined set of services to the other entities and layers in the system.
That is the messages exchanged between these radio dependent functions and other terminal functions
can be standardised and radio independent. Likewise with the MEF and HC radio independent messages
capable of carrying information in a standardised way to the LMT. TCCU and HD can be defined. A radio
independent/dependent split in the MT with a radio independent/dependent boundary is shown in figure
5.13.
92
RBCSBE
RAL
RPL
LC
MEF HCRadio Dependent
Radio Independent
SNL SBC
SHT
SHRUHUPU
TCCU
RCHD
HOCA
SNLC
UCCA
MAL
SAL
CMC
AHMMSF
AHT
LMT RHT
Figure 5.13: Radio Independence/Dependence in the MT Architecture
93
5.6.1 Data Storage in the MT
The FEs in the MT can be classified according to whether they have data storage capabilities or not. If an
FE only keeps the data required for a given procedure and if that data is not preserved in the FE outside
the procedure, then the FE is a behavioural FE. That is the FE is only concerned with executing a given
function or procedure and with the data required to perform that procedure.
If an FE contains data that is used in more than one procedure execution, i.e. the data is persistent, or
that be accessed by more than one FE then that FE is a data storage FE. In the MT data storage is limited to
a small number of FEs, the MSF, RC, TCCU, HUPU and HC. Of these, all but the RC store data to be used
by other FEs. The data stored in the RC can easily be separated from the behavioural aspects of the RC and
stored separately. Then it is possible to merge all the data storage FEs into a single MT DataBase (MTDB)
as shown in figure 5.14 below.
AHTRHT
LMT
SHT
HID
AU
MTDB
RC
Figure 5.14: Use of an MTDB in the MT
A more object oriented approach to FE behaviour can be adopted, where the FEs are considered to be
objects and so have both behavioural and data aspects. This has major impacts on the relationships between
the FEs.
For example the MSF is no longer needed, as all data is now stored in the Mobility Control FEs. The
relationship between these FEs is more complex as more information sharing is required. For example in-
formation related to user registrations would be maintained by an RHT and there will be different instances
of the RHT; one for each user registered on the terminal. Only one instance of the LMT is required. As
the LMT interacts with the RHT for domain update, some mechanism must exist so that the LMT knows
how many RHT instances there are. The relationships between the Mobility Control FEs for this scenario
is shown in figure 5.15. The next chapter proposes one mechanism which can be used to share instance
information between FEs in the system.
Only one AHT is required for the MT to gain access to a new domain [Del95c]. Likewise only one SHT
94
RHT
SHT
AU
MEF
LMT
AHT
n
Figure 5.15: Associations between Mobility Control Objects
is required to manage sessions in the MT. There are multiple instances of the AU, each holding authentica-
tion information for one user.
5.6.2 Summary
Table 5.1 below summarises the characteristics of the FEs in the MT. FEs that have both bearer system
control and transport control function are listed with the system control grouping i.e. bearer control. For
example the RBC FE is listed as a bearer control FE even though it also controls the RAL. If an FE does
not keep data outside of an active procedure, i.e. that FE has behavioural aspects only, then it is listed as
having no data storage functionality.
5.7 Conclusion
This chapter refined the terminal control architecture, using the terminal functions identified in chapter
4 and the UMTS network architecture shown in section 3.3.1. Applying the Monet methodology in an
iterative manner yielded a granular functional architecture, within which the function and relationships of
each individual Functional Entity have been described.
A control/transport split was applied to the architecture. This isolates the relatively dumb functions in
the transport plane from the more complex control functions. This has two advantages. Firstly it allows for
separate standardisation of transport and control in the system. In fact it is only necessary to standarise con-
trol, allowing for competition in the transport plane in the devlopment of more efficent, faster and smaller
algorithms. Secondly the impact of supporting different radio access technologies in the MT is lessened for
the transport plane. Rather than containing complex algorithms, such as HDLC, for the setup and manipu-
lation of radio channels, the transport plane contains a set of generic data manipulation algorithms. Bearer
and channel setup can be negotiated by the control plane. All that is necessary is to setup the transport plane
for a specific radio access technology is the appropriate parameters to configure the algorithms.
A radio independent/radio dependent divison is present in the MT. This clearly identifies those FEs
95
which must be modified to cater for different radio access technologies. As expected, radio dependent FEs
are closest to the radio interface in the MT and are concerned with the manipulation of radio bearers and
radio channels.
A radio dependent/radio independent boundary has been identified in the MT to separate the radio
dependent and radio independent parts. This boundary, which consists of a radio independent interface is
used to offer a set of bearer management primitives to the radio independent FEs. The services offered at
the radio dependent/independent interface are generic and do not reflect the possile range of services offered
by the underlying system.
This chapter also examined, from an architectural point of view, how data is stored in the MT. A very
functional approach has been taken to the MT architecture. Each FE is either a behavioural FE or a data
storage FE. While this means that there is quite a bit of interaction between the FEs to access and update
stored data, the relationships between the behavioural FEs themselves are less complex. The functional
approcah was compared with a more object oriented approcah, where ecah FE combined data storage and
behavioural aspects. This made the interactions between the FEs more complex as there are a lot more 1-n
interactions in the object oriented model.
In any case interaction between FEs using the functional model remains non-complex. There are sce-
narios where a single FE instance communicates with multuple instances of another FE , e.g. RC-RBC.
The RC must be able to distinguish between each instance of the RBC and some mechanism must exist so
that messages can be sent from the RC to the correct RBC instance. Also the FEs in the control plane can
be seen as corresponding to applications in the ISO model. A network layer has been developed for the MT
in the form of the SNL, but no presenrtation or session layer functions have been identified or specified for
the MT.
Effectively, this chapter along with chapter 4 have specified the functional requirements of the MT.
Some design apects of the MT including the non functional requirements of the MT are presented in the
next chapter.
96
FE RI/RD Network System DataPeer Control Storage
MobilityControlLMT RI LUH Yes Uses MSFSHT RI SHN Yes Uses MSFRHT RI RH Yes Uses MSFAHT RI AHV Yes Uses MSFAU RI AN Yes Uses MSF
MSF RI None Yes MobilityControl Data
CallControlUCCA RI UCC Yes None
RC RI None Yes ATM - UMTSBearer Mappings
HandoverControlTCCU RI None Yes Nearby BTSsHUPU RI None Yes User Related
Handover DataSHRU RI None Yes None
HC RD None Yes Quality DataSHRU RI None Yes None
HD RI HDN Yes NoneHOCA RI HOC Yes NoneBearerControl
RBC RD RBC Yes NoneSBE RD SBE Yes None
TransportControl
SBC RI None No NoneCMC RI None No NoneSNLC RI None No None
LC RD None No NoneUCCASBCRBC
Table 5.1: Summary of FE characteristics
97
98
Chapter 6
MT Design Aspects
Using the functional architecture for the terminal developed in the previous chapter, this chapter examines
some of the design aspects used in developing the mobile terminal.
The terminal design can be seen as consisting of functional and non-functional requirements. When de-
signing the mobile terminal a methodology which can easily differentiate between both sets of requirements
while at the same time support their easy integration into the overall terminal design is desirable.
An Object Modelling Technique(OMT) [RBP+91] variant, the SDL Object Modelling Technique (SOMT)
[Ek95], is chosen over other real time design strategies as the methodology most suited to develop the mo-
bile terminal design.
This chapter maps the functional entities from chapter 5 to OMT objects and uses the ITU Specification
and Description Language (SDL) to describe object behaviour. SOMT can also be used to support the
aggregation of the functional entity functional requirements and non-functional requirements into a single
object.
6.1 MT Design Strategy
The adopted design strategy focuses on two major aspects of FE design. Firstly, the FEs themselves have
to be described in a manner which clearly details their behavioural and functional aspects. Secondly, issues
related to FE instantiation and deployment, which do not effect the overall behaviour of the MT system, but
which impact on the MT implementation must be accommodated.
The previous chapters have described the functionality of the MT. These represent the functional re-
quirements of the system. The functional requirements of the system refer to the high level operation and
functions of the system as perceived by the user [Som92]. Functional requirements concentrate on the tasks
the system has to perform, rather than on implementation issues. Examples of functional requirements in
the MT control plane are call handling, control of transport, handover initiation etc.
99
The non functional requirements of a system set out the constraints under which the system must op-
erate and the standards which must be met by the delivered system [Som92]. In the MT non functional
requirements are concerned with interfacing to transport, instantiation of FEs, transaction management for
FEs and system configuration aspects.
The design methodology chosen must be able to integrate both the functional and non-functional re-
quirements of the system into a single description. Initially a methodology is chosen that allows the greatest
flexibility in the design of the MT functional requirements. Next the MTs non-functional requirements are
presented and integrated into the overall design.
6.2 OMT as a design methodology
OMT is an object oriented analysis and design methodology developed by [RBP+91] which combines three
independent views in modelling a system.
• Object Model: represents the static structural aspects of a system and its associated data structure.
• Dynamic Model: represents the temporal behaviour of a system and its control aspects.
• Functional Model: represents the functional aspects of the system.
OMT also consists of the following activities or stages.
• Analysis: The objective of the analysis stage is to understand the problem through identifying the
requirements.
• System Design: This stage is concerned with precisely defining the architecture for the system.
• Object Design: The functionality of the individual objects in the system is defined in detail at this
stage.
During the above stages, the object model, dynamic model and functional model for the system are
progressively refined. OMT incorporates the different models to separate a system into a set of orthogonal
components, each of which can be individually examined and understood. In this manner each aspect of
the system, can be analysed using existing techniques such as Data Flow Diagrams [WM85] to describe the
Functional Model, or the DARTS methodology for real time systems which deals with both functional and
dynamic system models [Gom84].
It can be difficult to combine the functional and dynamic models of a system to identify the required
processes and entities. OMT solves this problem by utilising the object model to provide a higher level
architectural view of the system, into which the dynamic model and functional models can be mapped. The
object model is the main framework around which the design is constructed with the actions and processes
of the dynamic and functional models being mapped into operations attached to classes in the object model
[RBP+91].
100
6.2.1 Adoption of the Methodology
For the MT, the system architecture developed in the previous chapters provides a detailed granular view of
the entities in the system. From this it is trivial to derive a first level object model. Each FE maps to a single
object in the system. An object view of the mobility control FEs is shown in fig 6.1. The UMTS Network
is represented as a single object. The RHT, SHT, LMT, AHT and AU, each have peers in the network.
AU
SHT
Network
AHT
RHT
LMTMSF
Figure 6.1: Object Model for Mobility Control FEs in the MT
Having derived an object model for the MT, dynamic and functional models must also be derived and
then integrated into the overall design. Dynamic behaviour can be modelled using state machines [Pre94]
which manage the flow of control in a system. Functional behaviour can be described using textual or
diagrammatic methods. A state machine for the Location Management FE is given in the next subsection.
Functional descriptions for the main procedures in the MT are given in chapter 4.
101
State Machine for the LMT FE
This section describes dynamic behaviour of the LMT FE. The behaviour of the FE is described using a
state machine. The state machine for the LMT FE is shown in figure 6.2
IDLE
Wait_LU
Wait_Access
Wait_ReReg
97
6
5
32
1
4
8
Figure 6.2: State Machine for the LMT
The major events are:
1. The LMT, in the idle state, receives the latest location measurements from the MEF. The LMT com-
pares the location area identifier and the domain identifier received from the MEF with those stored
in the MSF. If the location area and the domain area are the same, then the LMT remains in the idle
state.
2. If the received location area identifier is different to that stored in the MSF then a location update is
needed. The LMT sends a LocationUpdateReq message to the network to inform the network of the
new location of the MT. The LMT enters the Wait-LU state.
3. A LocationUpdateResp is received from the network indicating that the location update procedure
has been successful. The location information in the MSF is updated. If a new TMTI for the MT is
included in the LocationUpdateResp message then the MT’s TMTI is updated. The LMT returns to
the idle state.
4. A LocationUpdateResp is received from the network indicating that the location update procedure
has been unsuccessful. The MT returns to the idle state.
5. If the Domain Identifier received from the MEF is different to that stored in the MEF then a domain
update procedure is necessary. The LMT sends a DomainUpdateReq message to the AHT to begin
the access part of the domain update. The LMT enters the Wait Access state.
6. A DomainUpdateResp is received from the AHT indicating that the access has been successful. The
LMT sends a ReRegReq to the RHT to begin the reregistration phase of the domain update procedure.
The LMT enters the WaitReReg state.
7. A DomainUpdateResp is received from the AHT indicating that the access has been unsuccessful.
The LMT returns to the idle state.
102
8. A ReRegResp is received from the RHT indicating that the reregistration has been successful. The
location information in the MSF is updated. If a new TMTI for the MT is included in the AccessResp
message then the MT’s TMTI is updated. The LMT returns to the idle state.
9. A ReRegResp is received from the RHT indicating that the reregistration has been unsuccessful. The
LMT returns to the idle state.
In general combining the design based functional and dynamic models with the object model remains
non-trivial and will be influenced by the implementation language to be adopted. For the design phase of
the system the ITU standardised Specification and Description Language (SDL) [IT92a] is chosen. SDL
describes a system behaviour using interacting Extended Finite State Machines; state machines which also
support data operations [Sar93]. This provides a simple mechanism for integrating the data manipulation
specified in the functional model with the dynamic model of an object. An example SDL State Transition
for the LMT is shown in figure 6.3.
103
Process Type LMTProcType LMT_ACTIVE(8)
LMT_ACTIVE
LOC_MEAS(LAIn, DIn)
DIn =DI
LAIn= LAI
LocationUpdateReq(TMTI, LAIn)VIA NWK_Gate
LMT_Wait_LU
DomainUpdateReq(DIn)VIA AHT_Gate
LMT_Wait_Access
LocationUpdateResp(TMTIn, Status)
Status
Update_TMTI(TMTIn)
Update_LAI(LAIn)
DomainUpdateResp(TMTIn, Status)
Status
ReRegReq(TMTIn, DI, DIn)VIA RHT_Gate
LMT_Wait_ReReg
ReRegResp(Status)
Status
Update_DI(DIn)
Update_LAI(LAIn)
Update_TMTI(TMTIn)
(TRUE)
(FALSE)
(FALSE)
(TRUE)
(TRUE)(FALSE)
(TRUE)
(TRUE) (FALSE)
(FALSE)
Figure 6.3: Part of the LMT SDL State Diagram
104
6.2.2 SDL Object Modelling Technique
An OMT variant had been defined for the use of SDL as part of the OMT methodology. The SDL Object
Modelling Technique (SOMT) proposes the use of OMT for analysis and SDL for design [Ek95]. The latest
version of SDL contains many object oriented features, such as support for object types and inheritance
[RSO+94]. These concepts have been incorporated into SOMT. At the design stage each class in the system
is represented as a process type, or a block type in SDL. Objects are represented as process instances
and interaction between classes is described using signals. The dynamic model is described using the
extended finite state machines which constitute SDL Processes. The functional behaviour of the system is
described using task boxes in the SDL process. Part of the LMT state machine containing a behavioural and
a functional description of the location update and domain update procedures has been presented in figure
6.3. Figure 6.4 below describes the process types and instances for mobility control objects presented in
figure 6.1
105
Block Type LMTBlockType Process_Interaction_Page(2)
LMT(1,1):LMTProcTyp
LMTProcTyp AHTProcTyp
RHTProcTyp SHTProcTyp
MSFProcTyp
AHT(1,1):AHTProcTyp
RHT(1,1):RHTProcTyp
SHT(1,1):SHTProcTyp
LMT_ENV
(ENV2LMT_List)
RHT_LMT
(LMT2RHT_List)
(RHT2LMT_List)
LMT_AHT
(LMT2AHT_List)
(AHT2LMT_List)
(NWK2LMT_List) (LMT2NWK_List)
AHT_NWK
(NWK2AHT_List) (AHT2NWK_List)
RHT_ENV
(ENV2RHT_List)(RHT2ENV_List)
NWK
(NWK2RHT_List) (RHT2NWK_List)
LMT_NWK
SHT_NWK
(NWK2SHT_List) (SHT2NWK_List)
RHT_SHT
(SHT2RHT_List)
(RHT2SHT_List)
Figure 6.4: SDL description of Mobility Control Objects
106
6.3 Non Functional Requirements in the MT
The non functional requirements of the MT refer to those procedures that are necessary for the implemen-
tation of the MT and the overall integration of the MT and its constituent objects into a network, but which
do not have any impact on the overall behaviour of the MT and its constituent objects. These are related to
the placement and deployment of FEs in the system, the management of communication between FEs and
the management of interfaces between different modules making up the MT, e.g. between the control plane
described using SDL and the transport plane implemented using C. The non functional requirements have
been identified for the MT but can be abstracted to any system node. Non functional requirements can be
divided into groups as follows [BGPR98] 1.
Relationship with System Management
System management is responsible for the configuration of nodes in the system. The are two aspects to be
considered in the configuration of a node.
• Deployment. For an FE to be present in a node, it’s function must first be deployed by system
management. Not all FEs will be present in all nodes at the same time, e.g. only one of the SBC or
CMC will be present in an MT. Deploying a FE in a node does not mean that FE is active in the node.
• Instantiation. Once an FE has been deployed in a node it must be instantiated for that node. When
an FE has been instantiated it becomes active in the node. This means that the FE is running and can
communicate with other FEs in the node.
The deployment of FEs must be carried out by system management. The instantiation of nodes may be
carried out by system management or may be performed dynamically as required. If dynamic instantiation
of FEs is used then some entity must exist in the node to instantiate FEs.
Interfacing to Transport Functions
In the MT the Control Plane is described using SDL. This SDL description will run as a single UNIX
process on a UNIX workstation. The Transport Plane will be written as a number of C programs also
running as UNIX processes on the same workstation. Messages on the control/transport interface, used in
the MT to setup and monitor transport functions will therefore be exchanged between the UNIX processes
running on a single workstation. This will involve the manipulations of sockets, or another IPC mechanism
and the formatting of data to be exchanged between the UNIX processes; for example encoding a message
into a string of bytes, so that it can be sent across a socket interface.
1The actual target implementation is the ACTS Rainbow demonstrator basee on SUN workstations
107
Relationship with External Transport Mechanisms
Transporting of data between nodes in the system requires that a number of procedures be performed to
ensure the reliable delivery of a message. These procedures are often specific to the underlying transport
mechanism. Messages to be transported between nodes in the system may need to be encoded or encrypted.
It can also be necessary to setup and maintain a communications session between the communicating FEs.
This may require some extensions to the existing FEs, for example to cater for the allocation of Dialogue
IDs in TCAP [TCA93], or Instance Identifiers in Q2931[IT95].
Managing of Node Internal FE Relationships
Node internal FE relationships must also be managed. A known destination must exist for messages sent
internally in a node. This may require instantiation of an FE, if one has not already been setup by system
management. Also FEs involved in a given procedure must be associated together so that messages can
be routed correctly to them. Finally, some mechanism is needed for the actual routing of messages and
delivery of messages to the correct FE instance.
6.4 The FE Manager
6.4.1 Rationale for an FE Manager
Traditionally during the design phase, the functional and non-functional requirements of the system are
merged to form a single integrated design. In effect this means that the object models, state machines and
functional models developed for the system must be extended to cater for the non functional requirements.
For example, to cater for the use of TCAP in the system the LMT state machine presented in figure 6.2,
must be extended to handle the TCAP interface and the allocation and usage of dialogues resulting in a
number of extra states and transitions as described in the following subsection.
Extending the LMT State Machine for TCAP
Figure 6.5 below shows the LMT state machine extended to handle a TCAP interface in the MT. TCAP
is only used on the node external interfaces for the LMT, that is on the interface between the LMT and
the network used for the location update procedure. Before a message is sent to the network, a TCAP
Dialogue must be setup between the MT and the network. Once the TCAP dialogue is established, then
the LocationUpdateReq message can be sent into the network. The location update procedure is a sim-
ple request-response procedure and when a LocationUpdateResp is received from the network the TCAP
dialogue is closed.
Support of a TCAP interface requires the addition of two extra states to the LMT state machine. The
steps involved in the location update procedure have been modified as follows
108
IDLE
Wait_TCAP_Begin
Wait_Access
Wait_ReReg
119
8
7
52
1
6
10
Wait_LU
34
Wait_TCAP_End
Figure 6.5: Extended LMT State Machine for TCAP interface
1. The LMT, in the idle state, receives the latest location measurements from the MEF. The LMT com-
pares the location area identifier and the domain identifier received from the MEF with those stored
in the MSF.
2. If the received location area identifier is different to that stored in the MEF then a location update is
needed. A TCAP dialogue must be opened between the LMT and the network. A TCAPBeginReq is
sent to TCAP in the MT. The LMT enters the Wait TCAP Begin state.
3. A TCAPBeginResp is received from TCAP in the MT allocating a dialogue ID for use by the LMT.
The LocationUpdateReq message is encapsulated in a TCAP data message, including the LMT’s
dialogue ID. The message is sent to the network and the LMT enters the Wait LU state.
4. A TCAP data message containing the correct dialogue ID is received by the LMT. A LocationUp-
dateResp message is encapsulated in the message. If the LocationUpdateResp indicates that the
update procedure has been successful. The location information in the MSF is updated. If a new
TMTI for the MT is included in the LocationUpdateResp message then the MT’s TMTI is updated.
The LMT enters the Wait TCAP End state.
5. A TCAPEndInd is received from TCAP in the MT indicating that network has closed the dialogue.
The LMT enters the idle state
6. A LocationUpdateResp is received from the network indicating that the location update procedure
has been unsuccessful. The MT returns to the idle state.
7. If the Domain Identifier received from the MEF is different to that stored in the MEF then a domain
update procedure is necessary. The LMT sends a DomainUpdateReq message to the AHT to begin
the access part of the domain update. The LMT enters the Wait Access state.
8. A DomainUpdateResp is received from the AHT indicating that the access has been successful. The
LMT sends a ReRegReq to the RHT to begin the reregistration phase of the domain update procedure.
109
The LMT enters the WaitReReg state.
9. A DomainUpdateResp is received from the AHT indicating that the access has been unsuccessful.
The LMT returns to the idle state.
10. A ReRegResp is received from the RHT indicating that the reregistration has been successful. The
location information in the MSF is updated. If a new TMTI for the MT is included in the AccessResp
message then the MT’s TMTI is updated. The LMT returns to the idle state.
11. A ReRegResp is received from the RHT indicating that the reregistration has been unsuccessful. The
LMT returns to the idle state.
It is much more desirable to be able to separate the functional and non functional requirements of the
system such that maximum flexibility and reuse of the functional requirements is maintained. This also
allows the functional requirements to evolve more easily; independent of the non functional requirements.
An FE manager is proposed to fulfil the system’s non functional requirements and to enforce the sepa-
ration of functional and non functional requirements in the system. The positioning of the FE manager is
shown below in figure 6.6 [BGPR98].
SM:1
SM:2
SM:3
FE BSM:1
SM:2
SM:3
FE A
External Transport
FEManager
FEManager
Interface toTransport
System Management
NODE 1
Figure 6.6: Placement of an FE in the system [BGPR98]
The FE is now viewed as being up of two elements, the FE state machine and the FE manager. The
FE state machines fulfils the functional requirements of the system and correspond to the FEs and objects
discussed so far in this thesis. The FE manager fulfils the non functional requirements of the system and
performs the following functions [BGPR98].
• Interacting with the system management for the deployment of an FE;
• Interfacing to SNL for transport of Signalling Messages;
• Interfacing to Transport functions in the node;
110
• Encoding/decoding of messages;
• Creation/destruction of FE state machines;
• Routing messages to individual FE state machines;
• Management of relationships between FE state machines internally in the node;
6.4.2 Design Model including the FE Manager
The object model described earlier in figure 6.1 can now be considered as describing only the FE state ma-
chines and some extensions to the model must be made to accommodate the FE manager and its relationship
with the FE state machines and other FEs in the system.
The FE managers for each FE need to be tailored for the specific requirements and interfaces of that FE.
For this reason each FE will have a separate FE manager class, each of which inherits a common set of data
and functions from a base class. An OMT diagram representing the inheritance tree for the mobility control
FE managers is presented in 6.7.
FE_Manager
AHT_Man RHT_ManAU_ManMSF_ManSHT_ ManLMT_Man
Figure 6.7: Inheritance Tree for Mobility Control FE Managers
Figure 6.8 below details the object relationship between the FE managers and FE state machines for the
mobility control Group. The inter FE associations described in section 6.2.1 and shown in figure 6.1 are now
seen as inter FE manager relationships. The FE managers also have an association with signalling transport,
which transports messages from the MT into the network. FE state machines only have associations with a
single FE manager.
This model is unsatisfactory. The object relationships in the system as a whole are greater than the
relationships between the FE managers as shown in figure 6.8. That is the model in figure 6.8 above does not
express the totality of the inter FE relationships in the MT. It merely shows that messages may be exchanged
between FE managers and between FE State machines and FE managers. The relationship between FE
state machines is now totally dependent on the types of FE manager used and the relationships which they
111
AHT_Man
RHT_Man
AHT_SM
RHT_SM
LMT_SM
1+
1+
AU_SM
MSF_SM
AU_Man
1+
1+
MSF_Man
SHT_ ManSHT_SM
LMT_Man
Signalling Transport
Figure 6.8: Object Model for FE State Machines and FE managers for Mobility Control
support. In other words the abstraction from communication and interface handling requirements, which
the FE manager was introduced to support is not apparent in the model. It is desirable that a level of
abstraction be used which allows the system design to be documented in terms of FE state machines and
their relationships, but still allows for the inclusion of the FE managers in the model.
A higher level model is required, in which the specification view of the system can be carried to the
design phase. In this high level view each FE is represented as a single object. The object is then composed
of two separate objects, the FE state machine object and the FE manager object. In SOMT and OMT terms,
the FE object is an aggregate of the FE state machine and FE manager objects, as shown in figure 6.9.
6.4.3 SDL Realisation of the aggregated model
Support for the high level object view on SDL is provided by the Block construct. An SDL block provides
a means of encapsulating processes. It is commonly used to group processes into groups based on such
criteria as physical location or related functionality. For the purposes of the MT System the SDL Block
provides a mechanism to represent the system as a set of interacting high level objects each of which is
composed of a number of separate objects represented as SDL Processes. SDL Block level diagrams for
the system are shown in figure 6.10 and the process view, showing the FE state machine and an example FE
manager processes is given in figure 6.11 for the LMT.
112
FE
FE_SMFE_Man
1+
Figure 6.9: FE Object as an aggregate of FE State Machine and FE Manager Objects
113
System Location_Management Block_Interaction(7)
LMT:LMTBlockType
RHT:RHTBlockType
SHT:SHTBlockType
AHT:AHTBlockType
MSF:MSFBlockType
LMTBlockType AHTBlockType
RHTBlockType SHTBlockType MSFBlockType
LMT_ENV
(ENV2LMT_List)
LMT2ENV
LMT_NWK
(LMT2NWK_List)(NWK2LMT_List)
LMT2NWK
LMT_RHT
(LMT2RHT_list)
(RHT2LMT_list)
LMT2RHT
RHT2LMTRHT_NWK
(RHT2NWK_List)(NWK2RHT_List)
RHT2NWKRHT_ENV
(RHT2ENV_List) (ENV2RHT_List)
RHT2ENV
RHT_SHT(RHT2SHT_List)
(SHT2RHT_List)
RHT2SHT
SHT2RHT SHT_NWK
(SHT2NWK_List)(NWK2SHT_List)
SHT2NWK
LMT_AHT(LMT2AHT_List)
(AHT2LMT_List)
LMT2AHT
AHT2LMT AHT_NWK
(AHT2NWK_list)(NWK2AHT_List)AHT2NWK
Figure 6.10: SDL Block Level view of Mobility Control FEs
114
Block Type LMTBlockType Process_Interaction_Page(3)
LMT_Man (1,1 ):LMT_ManProcType
LMT(0,):LMTProcType
LMTProcType LMT_ManProcType
RHT (LMT2RHT_List)(RHT2LMT_List)
AHT (LMT2AHT_List)(AHT2LMT_List)
LUH(Man2LMT_List)
(LMT2Man_List)
LM2TCAP
(App2TCMan_L)
(TCMan2App_L)
TCAP
MEF2LMT
(MEFCntrlIn)RHT_Gate
AHT_Gate
MEF_Gate
LMT_Gate
Man_Gate
Figure 6.11: FE State Machine and FE Manager as SDL processes
115
6.5 Conclusions
This chapter has discussed some of the design aspects of the MT system The OMT variant SOMT is chosen
as the most suitable methodology for the design of the system. The combination of the object model,
dynamic model and functional model provided by the methodology through the combined use of OMT and
SDL provides an easy and flexible mechanism for the design of the system functional requirements.
Non functional requirements for the system to support interaction with system management, transport
functionality’s and inter-FE relationships are described. A strict separation in the design of functional and
non functional requirements of the system has been proposed. This separation abstracts the functional
requirements of the system away from the non functional requirements. This increases the flexibility and
portability of the system design by making it easier to update the system’s functional and non functional
requirements independently of each other. In this manner the set of environments in which the system can
be placed increases greatly as issues such as the use of IP or SS7 for signalling transport no longer impact
on the overall behaviour of the system.
It is still useful however to be able to identify the specification level FEs and relationships at the design
stage. For this reason a high level FE, which is an aggregate of the FE state machine and FE manager is
introduced. The relationships between high level FEs are the same as those identified during specification.
The introduction of this high level view is well supported in SDL by the block construct. Each FE Block then
SDL contains a number of SDL processes representing the FE manager and FE state machines. Aggregation
is thus supported in SDL by the simple mechanism of encapsulating processes within blocks.
Introducing an FE manager in the design stage of the MT results in a very flexible MT implementation.
The FE manager provides a toolbox of functions necessary for implementation. The functions in the FE
manager can be easily adapted or replaced thus abstracting the FE away from communications and system
management requirements. This allows for the continued, independent evolution of the MT functional
requirements with traceability from analysis to design.
116
Chapter 7
The MT in other architectures
7.1 Introduction
This chapter compares and contrasts the MT architecture developed in the previous chapters, with terminal
architectures in existing and emerging systems. The architecture of the MT is also analyzed for its ability
to cater with new and novel practices in mobile telecommunications technologies.
Initially the MT is compared with the MTs of the second generation systems. As the MT architecture
has been developed with Radio Independence as a goal, then it should be possible to map the architectures
of the GSM and DECT MTs into the UMTS MT.
The Telecommunications Information Network Architecture Consortium (TINA-C) have developed an
advanced networking architecture to cater for the needs and developments of telecommunications into the
next century. Ideally TINA will incorporate UMTS or some evolved version of UMTS. The TINA-C have
analysed the requirements placed by mobility upon the TINA architecture. One possible adoption of Mo-
bility in TINA and the resulting Mobile Terminal Architecture are described here and compared with the
developed UMTS MT architecture.
Finally the impact of emerging technologies on the MT are discussed. Software Radio is a mechanism
which allows for the download and/or dynamic configuration of the Radio Lower Layers of the terminal. It
can be used to dynamically reconfigure the operation and functions of the MT and so allow it to be deployed
in a wide variety of radio systems.
7.2 Representing the GSM MT in UMTS
This section breaks down the GSM MT architecture into it’s constituent functions and compares the result-
ing FEs with those developed in chapter 5. The architecture of the GSM MT is shown below in figure 7.1.
Each of the layers in the MT performs a number of functions, including call control, mobility management.
bearer setup and measurement reporting as described in section 2.3.1.
117
Mobility Management
Radio Resource Management
Transport
Connection Management
Figure 7.1: GSM MT Architecture
7.2.1 GSM MT Functionality
As described in chapter 4, the terminal control functionality can be grouped into a number of related control
functions relating to call control, mobility control, handover control, bearer control and transport control.
• Call Control functionality is encapsulated in the Communication Management Layer, which incorpo-
rates GSM Call Control, and supplementary services management.
• Mobility Control functionality is contained in the Mobility Management layer. This layer provides
functionality necessary for location update and location registration in GSM and also for security and
authentication.
• Transport Control functionality is handled by the Radio Resource Management layer which is re-
sponsible for the maintenance of stable connections between the MT and the network. The Transport
Layers also contain transport control functionality for the setup and activation of radio bearers.
• Bearer Control The transport layers contains bearer control and are responsible for the setup and
release of individual traffic and signalling radio bearers.
• Handover Control functionality is contained in the radio resource management layer.
Figure 7.2 below shows a mapping between the layered architecture of the GSM MT and the terminal
control functions as identified above.
MM
RR
Trans
CM
MobilityControl
TransportControl
BearerControl
HandoverControl
CallControl
Figure 7.2: GSM MT Control Plane Groupings
118
Although the GSM MT contains the same overall functionality as the UMTS MT, in some areas the role
of the MT is very much reduced. Some of the differences in the overall behaviour of the GSM MT and the
behaviour of the UMTS MT specified in chapter 4 include:
• Mobility Control GSM offers a limited set of applications and services to the user and all services
are available to all users. For this reason there is no need to explicitly register for services in the
network. In fact it is not possible to receive a call for a given application unless it is known in
advance what type of call is expected [MP92]. In other words, the same terminal cannot receive a
fax or voice or data call unless it has been previously configured to receive the call. As GSM evolves
and more complicated data services are available in GPRS and EDGE networks new terminal types
will be produced. It remains to be seen if these will support both voice and data access, although not
simultaneously, and be able to differentiate between them without user intervention.
• Handover Control The GSM terminal is not involved in handover control to any great extent, Its
only role is to deliver measurement information received form the lower layers to the network, which
then decides if a handover is necessary. This contrasts with the role of handover control in the UMTS
MT, which is able to decide when a handover is necessary, before passing control to the network for
handover execution.
• Bearer Control In GSM the Network is responsible for the allocation of resources for traffic chan-
nels on the air interface. Radio bearers are assigned to the MT during the call setup and handover
procedures. The MT does not need to engage in a radio bearer establishment procedure for traffic
channels, but only to activate the bearers when allocated by the network.
• Transport Control In GSM handover of bearers and the associated transport control is limited to the
lower radio layers, almost to the physical layer. As it is not possible to have more than one bearer
present in the MT at a time there is no requirement for an explicit transport control mechanism to
manage and co-ordinate the transport of user data on more than one bearer simultaneously or the
switching of data from one active bearer to another. Coupled with this, handover in GSM is not
synchronous in the MT. The original bearer is de-activated and released before activation of the new
radio bearer to the new BTS. So no switching and bridging mechanisms are necessary. There is only
ever one bearer present and so there is only ever one possible transport path in the MT.
7.2.2 Functional Architecture
Figure 7.3 presents a functional architecture for the GSM MT based on the functional entities identified in
chapter 5 for the UMTS MT and the behavioural differences between GSM and UMTS outlined above.
Many of the FEs present in the GSM MT architecture have a direct correspondence with their UMTS
counterparts, e.g. the call control FE in GSM fulfils the same role as that of the UMTS CC. Other FEs are
119
Physical Layer
User PlaneLAPDm
MEF
HD
LMT
SBE
UCCA
RBC
LC
HOCA
PE
Figure 7.3: GSM MT Functional Architecture
not needed or fulfil different roles in the system. The next sections detail the main differences in the UMTS
and GSM MT functional architectures
Mobility Control FEs
There are no RHT or AHT entities in the GSM MT. These entities are, in UMTS, tightly bound to the
concepts of user registration and user re-registration in the network. As described above these procedures
are not needed in GSM where only a limited number of services are provided. Also the MEF is not required,
there is no real need for a data storage entity in the MT as all location information can be stored in the LMT.
Authentication information can be read from the SIM.
Handover Control FEs
Many of the handover entities identified in UMTS, especially those which contain data only, are not needed
in GSM. In the handover initiation procedure the GSM MT serves only a measurement reporting role in
the MT. As such, the HD as shown in figure 7.3 is not even necessary and is shown here for consistency
purposes only. In chapter 4 and chapter 5 an external interface to the network, is used during handover
initiation. This interface is part of the handover control functionality in the MT and is used by the HD FE.
The MEF is identified as lower layer functionality and has no external interface in the MT. Rather than
add an extra interface to the MT for the forwarding of measurement information to the network, the most
appropriate existing interface and its associated FE, the HD, is used for this purpose.
Handover initiation and execution is completely confined to the network. The MT has only a support
role and does not know in advance that a handover is to take place. This means that there is no way to
120
configure the transport plane in advance of the handover or for the MT to know when to expect resources and
handover execution messages from the network. In other words there is no relationship between handover
initiation and handover execution in the MT. Hence there is no need for a relationship between the HD and
the HOCA. In contrast, UMTS handover in the MT is causal, handover initiation occurs before handover
execution and because the MT is involved in the initiation phase it can be prepared for the execution phase.
Transport control and Bearer control FEs
In GSM there is no split between control and transport in the control plane architecture. The functional
architecture in figure 7.3 has imposed such a split as outlined in section 5.4. This results in the inclusion of
some FEs identified for UMTS but not immediately obvious in the GSM architecture.
• Signalling Bearer Entity(SBE) this entity is responsible for the setup and control of connections at
the link layer (HDLC) in the MT.
• Link Control (LC) The LC is responsible for the setup and management of radio bearers in the system
under the control of the RBC.
• Radio Bearer Control (RBC) The RBC in GSM fulfils the majority of the bearer and transport roles
allocated to the RR layer. It manages the MT-BTS User Plane Connections and interacts with the LC
for the setup and release of radio bearers. During Handover the RBC switches radio bearers in the
MT. When a Handover Command message is received in the MT by the HOCA, the HOCA instructs
the RBC to switch bearers. The RBC instructs the LC to shut down the old radio bearer. After this
the RBC initiates the setup and activation of the new bearer in the MT. Once this is complete the user
plane is switched to the new bearer. There is no explicit procedure required to switch the user plane
to the new bearer. This is because the same Service Access Point (SAP) can be used for the old and
the new radio bearers as shown in figure 7.4.
121
HOCA PHYLCRBC
Handover Command
HandoverReq[New_Bearer]
[New_Bearer]
CloseReq
[Old_Bearer]
DeActivateReq[Old_Bearer]
DeActivateResp
CloseResp
OpenReq
[New_Bearer]
ActivateReq
[New_Bearer]
ActivateResp
OpeneResp
HandoverResp
Figure 7.4: Bearer Switching in the MT during GSM handover
Other Control FEs
There is no need for a separate RC in the GSM MT. This is due to the relative simplicity of the transport
plane and the lack of any significant handover entities in the MT which greatly simplifies the interaction
between call control and handover in the MT. Call Control in the system is still abstracted away from any
handovers in the system through the RBC which presents a single point of access to call control. As there is
no requirement for simultaneous traffic channels in the MT only one instance of the RBC is needed to setup
and manage traffic channels. This contrasts with the UMTS MT where there are multiple instances of the
RBC managing multiple traffic channels in the MT and the RC acts as co-ordinating entity for the multiple
RBCs involved in the call and presents a single access point to call control. There is no Signalling Network
Layer in GSM, and so no SNLC is needed in the GSM MT. Instead the signalling entities use the SBE for
the opening and closing of signalling channels. Signalling messages are then sent directly through the link
layer. Because there is no SNL, paging is not confined to the lower layers. Instead a Paging Entity (PE) in
the MT receives all incoming pages and responds, opening a link layer level connection with the network.
122
7.2.3 Conclusion
The GSM MT has a limited role in the GSM Network and plays no significant role in many of the more
complex network procedures such as handover and bearer setup. These procedures are network driven and
the MT only needs to respond to the stimulus and information provided by the network. The remaining MT
procedures including those which are MT internal are very much reduced in complexity when compared
to their UMTS counterparts. In terms of radio independence/dependence, the GSM MT is mostly Radio
Dependent. This is not surpassing as it was designed to work with a single radio system only. There are
radio independent functions present in the MT for call control and mobility control. Handover control
also in GSM would be considered radio independent if the criteria were extended to include measurement
reporting to the network; which could easily be supported if the data were to be transported in a generic
manner.
7.3 Representing the DECT PP in UMTS
As with GSM, the control architecture for the DECT Portable Part (PP) is layered as shown in figure 7.5
below. However unlike GSM, DECT is more rigorously based on the ISO OSI layered model as detailed in
section 2.4.1.
Network Layer
MAC Layer
Physical Layer
DLC-LayerLLME
Figure 7.5: DECT PP Architecture
7.3.1 DECT PP Functionality
The DECT PP contains all the major control plane functions identified in chapter 4.
• Call Control is contained in the network layer. The network layer in DECT is divided into a number
of separate functions including Call control and messaging services.
• Mobility Control is also incorporated into the network layer. The DECT network Layer contains an
MM entity responsible for location updating and authentication and security in the system.
• Handover Control in DECT is a function of the lower layers and is contained in the LLME.
123
• Bearer Control functionality is contained in the LLME and the lower layers; the DLC and the MAC.
• Transport Control functionality is also contained in the lower layers and the LLME.
Figure 7.6 below presents a mapping between the UMTS Control Plane functions and the DECT layered
architecture as identified above.
MAC LayerM
Physical :Layer
DLC Layer
LLME
TransportManagement
BearerControl
&TransportControl
HandoverControl
CallControl
MobilityControl
Figure 7.6: DECT PP Control Plane Functionality
However there are some differences in functionality and behaviour between the DECT PP Control Plane
and that identified for UMTS in chapter 4.
• Mobility control. While DECT has a wide range of application areas and is capable of offering a
wide range of services to the user there is no concept of user registration in the system. A Portable
Part is setup to receive a certain service or it is not. This is, in part, due to the fact that DECT
is intended as an access technology and it is up to the network to determine the range and type of
services a user should have access to.
• Handover control. DECT employs a forward handover mechanism in tandem with a PP based
distributed control algorithm (DCA) for determining when a handover is to occur. This means that
the DECT PP is in charge of the handover, it determines when a handover has to take place and which
FP to handover to. As well as this the PPs are responsible for the allocation of resources in the system.
This is in contrast to the mechanisms described in chapter 4 for UMTS where it is assumed that the
network is responsible for allocating resources during handover.
• Bearer control. There is no separation between signalling and user data over the air in DECT. Each
radio bearer is partitioned and carries both user and signalling data. It is not possible to reserve each
section of the bearer separately or to request a signalling bearer and ”append on” a user data bearer
later.
• Transport control. As with GSM, it is not possible to have more than one bearer 1 active at a time.
In fact it is not possible to be synchronised to more than one FP at any one time. In effect this means
1In DECT a bearer is equivalent to a single air interface timeslot. This differs from the use of the term bearer elsewhere. A UMTSradio bearer is a logical entity made up of a number of radio channels.
124
that during handover one bearer must be dropped before a new one is established. This simplifies the
transport control in the PP.
7.3.2 Functional Architecture
Figure 7.7 below presents a functional architecture for the DECT PP using the FEs identified in chapter 5
and the control plane behaviour described above.
HOCA
MAC/Physical
User PlaneDLC
MEF
HD
LMT
RBC
UCCA
SBE
LC
PE
Figure 7.7: DECT PP Functional Architecture
Many of the FEs present in the PP architecture have a direct correspondence with their UMTS coun-
terparts. Some FEs are not needed or fulfil different roles in the system. The next sections detail the main
differences in the UMTS and DECT PP functional architectures
Mobility Control FEs
There are no RHT or AHT entities in the DECT PP. These entities are, in UMTS, tightly bound to the
concepts of user registration and user re-registration in the network. As described above these procedures
are not needed in DECT where the core network can be expected to regulate access to user services.
Handover Control FEs
Handover in DECT is based on the quality of the active bearers 2. As in UMTS measurement values are
passed by the MEF to the HD, which decides if a handover is necessary. If the HD decides a handover is to
take place it passes control to the HOC in the PP. The HOCA then instructs the RBC to shutdown the bearer
2Again the term bearer here indicates a DECT bearer rather than a UMTS bearer
125
and setup a new bearer to the new FP. This is in contrast to UMTS where handover control is in the network
and a handover control agent (HOCA), under the control of the network, is used in the MT to initiate the
switching of bearers. In terms of the network-terminal control relationship it can be said, for DECT, that
the network has delgated all the handover control functionality to the PP.
Bearer Control FEs
The relationship between the bearer control FEs in DECT reflects the lack of signalling and user data
separation in the system. There is a single point of control for bearer setup in the RBC and this interacts
with the LC and the SBE for the setup and closing of radio bearers. The procedure for the setup of a radio
bearer is shown in figure 7.8 below. When a bearer is to be setup, the RBC requests the LC to setup a bearer
to the FP. When the Bearer is established the RBC then instructs the SBE to activate the signalling part of
the bearer and perform a link-level setup procedure. Later in the call the RBC activates the user data part of
the bearer.
RBC LCSBE
BearerSetupReq
BearerSetupResp
OpenReq
[Bearer]
OpenResp
BearerSetupProcedure
DLCSetupProcedure
Figure 7.8: Setup of a DECT bearer by the RBC
Transport Control FEs
As only one bearer can be present at a time, the RBC can handle the switching of the user plane during
handover. As with GSM switching described in section 7.2.2 the RBC shuts down the active bearer before
setting up a new bearer to the new FP. As there are never two bearers active at a time, the same SAP can be
presented to the upper layers at all times.
126
Other Control FEs
As with GSM, there is no requirement for an RC FE in the DECT architecture. There is no Signalling
Network Layer in DECT, and so no SNLC is needed in the DECT PP. Instead the signalling entities use the
RBC for the opening and closing of signalling channels. Signalling messages are then sent directly through
the link layer. Paging is a network layer function in DECT a Paging Entity (PE) in the Network Layer
receives all incoming pages and responds, opening a link layer level connection with the network.
There is a very simple control/transport split in the DECT architecture. Many of the control functions
related to the manipulation of transport are located in the LLME. These include handover control, transport
control and bearer control.
7.3.3 Conclusions
The DECT PP plays a significant role in the DECT system. In some areas, particularly in handover and
bearer control, the DECT PP is the most important element in the system with full control over the proce-
dures and their execution. This is in sharp contrast to UMTS where the network manages these procedures
and the MT plays a secondary role. In spite of this, the majority of DECT FEs in the PP can be classified
as being Radio Independent. The role and behaviour of the HD and HOCA FEs is very similar to that of
the HD and HOCA in the UMTS MT but instead of acting as the networks agent in the MT the HOCA in
the DECT PP is the central point for handover control. The lower layer bearer control and transport control
FEs are radio dependent, as expected.
7.4 TINA
The Telecommunications Information Networking Architecture (TINA) has been developed by the TINA
Consortium (TINA-C) [TIN95]. It aims to provide a software architecture flexible enough to be applied
to a wide range of technologies and architectures and modular enough to enable the reuse of software
components. TINA is heavily based on object oriented methods and paradigms but is specialised to the
needs of an open telecommunications architecture [Gra97].
7.4.1 TINA Architecture
As shown in figure 7.9 below the TINA Architecture is composed of Service Logic, the Distributed Pro-
cessing Environment (DPE), the kernel Transport Network (kTN) and the Transport Network (TN).
Service Logic
The TINA Service Logic consists of the software applications that runs on a TINA system. There are two
main application types, Service Applications which provides the logic of the telecommunications service
127
Service Logic
Transport Network
Kernel Transport Network
DPE
ConnectionManagement
ServiceApplications
ComputingNode
ComputingNode
ComputingNode
Figure 7.9: TINA Architecture [TIN96b]
and the Connection Management Applications which enable the establishment of user bearer connections in
the Transport Network. Together these form the most important applications in the provision of multimedia
services. The Service applications contain the service logic for contacting the participants in a multimedia
conference, while the Connection Management Applications enable the establishment of bearer connections
between them [TIN96b].
Distributed Processing Environment (DPE)
The DPE is a layer of software that supports the distributed execution of the TINA applications. It hides
distribution aspects from the application programmer so that, for instance, the application programmer does
not have to worry about the location where a piece of software is running [TIN94].
Kernel Transport Network (kTN)
The kTN is the network supporting the transfer of messages between the DPE nodes. It can be compared to
a signalling network. Its implementation is not standardised within TINA. It may be, for example, and IP
network integrated with the Transport Network. While access to the kTN is controlled by TINA, the kTN
performs autonomous routing of messages independent of the rest of TINA [TIN95].
Transport Network(TN)
The TN provides the telecommunications transport capabilities. It supports the bearer connections required
for the transport of user data. The setup of connections in the TN is performed by the TINA Connection
management [TIN96b].
7.4.2 Mobility Support in TINA
This section examines the options for the provision of mobility support in TINA. A number of objectives
have been identified for the support of mobility services in TINA [TIN96a]:
128
• It should be possible for terminal mobility support to be transparent to the service designer. That is it
should be possible to design services such that they are valid for both mobile and fixed networks.
• At the same time it should be possible for the service designer to know about the mobility of the
terminal and to know the terminal’s current location and so design mobile specific services.
• TINA should support terminal mobility in an efficient manner
• TINA control over terminal mobility is desirable on order to allow for integrated management
• It is desirable to re-use existing functions/systems/protocols for mobility support. It will be useful to
reuse, for instance, existing mobile networks. On the other hand it should be possible to implement
mobility support by means of TINA only.
• the solution should be applicable to any radio technology, although TINA may place requirements on
how those technologies may evolve
Any mechanism used for the support of mobility in TINA must fulfil some or all of these objectives.
The next sections present a number of different mechanisms for the support of mobility in TINA based on
[TIN96a]; using UMTS as the underlying transport network and providing mobility as part of the TINA
Service Logic. These solutions are assessed on how they fulfil the above criteria. Following this, a compar-
ison is made between the architectures used when terminal mobility is provided using TINA service logic
as proposed in [Gra97] and the UMTS MT control architecture.
TINA using UMTS as the underlying transport network
In this solution, TINA utilises UMTS as the underlying transport network for kTN and TN services as
shown in figure 7.10 below. Functions related to the setup and management of bearers needed to support
terminal mobility are hidden in the kTN and not visible to the TINA service logic.
TINA Node A TINA Node A
ServiceLogic
ServiceLogic
KTN(UMTS)
Figure 7.10: Using UMTS as the underlying Network in TINA [TIN96a]
This is a natural approach to the provision of mobile services in TINA and had minimal impact on the
TINA Service Logic and the DPE. One of the current assumptions in TINA is that the objects in the Service
129
Logic rely on the DPE to locate other objects, while the DPE relies on the kTN to locate the equipment on
which objects are located [TIN95]. Thus TINA objects and the DPE rely on knowing the logical address
of the objects they interact with, while the kTN translates these into physical address identifying physical
nodes in the network. In other words UMTS is used to provide end-to-end links between computing nodes
in the DPE, regardless of the mobility characteristics of those nodes [TIN96a].
The benefits of this approach are as follows:
• Ease of service design. TINA objects are completely abstracted from mobility aspect. This means
that the same service logic can be used in fixed and mobile networks as the service programmer does
not need to worry about supporting mobility.
• Supports Mobility of any DPE Node. This approach can be used to support the mobility of any
DPE node. DPE Nodes need only to know each others logical addresses, as UMTS will translate
these into physical addresses.
• Re-Use of existing systems. This solution reuses the mobility control procedures of UMTS, in fact
the mobility control procedures are internal to UMTS and not seen by TINA. This also allows for the
support of other mobility control technologies, if required, or the upgrade of the UMTS procedures
without impacting on the service logic.
• Separation of business roles. This approach naturally supports the separation of TINA service
provision from the role of the terminal mobility provider.
The drawbacks to this approach are:
• Lack of support for Mobile Specific Services. Sometimes mobility awareness is required. For
example some services may be location dependent and it can be necessary to check access rights of a
user at a certain location.
• Efficiency. This solution is not very efficient as a mapping must be made between the logical and
physical addresses for each interaction between the terminal and the network. Also as radio resources
are managed internally in the kTN and TN, the UMTS mobility control and TINA service logic proce-
dures are strictly separated. So the kTN may not be aware of the specific radio resource requirements
of the service applications.
• No TINA Control of mobility. Terminal Mobility is completely transparent to TINA in this ap-
proach. This is a disadvantage form the point of view of integrated management.
This is a simple way to integrate TINA into existing and future networks and provide TINA services
without placing any direct requirements on those networks. However it is relatively inefficient and may
result in duplicate procedures in both parts of the systems, e.g. performing TINA service control procedures
130
to avail of services in the network and later performing a service check in UMTS to get the required bearer
to the terminal. A more efficient approach, integrating mobility into the TINA service logic is discussed in
the following section.
Mobility support in the Service Architecture
The TINA service logic can be extended to support mobility [TIN96a]. In this case the service logic
is aware of the mobility of the terminal. Functions required to support terminal mobility: call control,
mobility control, handover control, call control and bearer control are all supported by the service logic.
This is essentially the same as the UMTS approach although, as described in the next section, the resulting
terminal architecture is quite different to that of UMTS. The advantages supporting mobility in the service
logic are
• Support for Mobile Specific services. The service designer can easily design mobile specific ser-
vices as full knowledge of the terminal location is available. For example roaming restrictions can be
built into a service design.
• Efficiency. This is an efficient mechanism for the support of mobility. Address information is readily
available to the Service Logic and so no address translation is needed in the kTN which, with the
TN, is only concerned with transport. Furthermore more efficient use of radio resources is possible,
because the service knows when it is active and when to explicitly request radio resources.
• Full TINA control. Mobility is fully integrated into TINA and there is full TINA control over
terminal mobility.
• Simple kTN. As mentioned above, the kTN is solely concerned with transport and need only be
capable of routing messages between fixed end points.
Some of the drawbacks of this approach are:
• More difficult Service Design. The service designer now has to take mobility into account if the
service is to be applicable in both fixed and mobile networks.
• Separation of business roles. It is not straightforward to separate the role of mobility provide and
the role of service provider in this solution.
• No support for general host mobility. This approach cannot be used to support mobility of any arbi-
trary DPE node. Only mobility of terminals is possible. Also, some objects that need to communicate
with peer objects on the terminal need to be aware of the mobility of the terminal.
• No reuse of existing implementations. No re-use of existing mobility control implementations can
be made. Mobility control procedures must be implemented anew in a TINA fashion even if they
131
are based on existing procedures in UMTS, DECT or GSM. Furthermore any evolution of mobility
control may result in an update of each individual procedure that involves mobility.
• Interface References. Another drawback is that the interface reference of an object on the terminal
changes if the terminal changes location. Hence all the objects that are in communication with the
Terminal would need to be notified of this.
This is a more elegant approach to the support of mobility in TINA. However introducing mobility to
the service logic does introduce a number of drawbacks as outlined above. Many of these drawbacks have
already been identified and solved for UMTS. The next section describes the functionality of the TINA MT
and shows how mobility solutions form UMTS can be applied in the TINA architecture.
7.4.3 The TINA Mobile Terminal
As with the UMTS MT, the service logic of the TINA MT must support mobility control, call control,
handover control, bearer control and transport control functions. In figure 7.11 these are shown mapped to
the service logic of a TINA MT.
TCSM
LNC
EML-CP
MobilityControl
CallControl
HandoverControl
BearerConbtrol
TransportControl
Figure 7.11: control Functions in the TINA MT
Mobility Control
As with UMTS Mobility control Procedures such as User Registration and Location Update are used to track
the location of users and terminals in the network and to ensure that the network knows which services the
user is entitled to at a given location. In TINA Mobility control procedures in the MT are controlled by
dedicated agents in the MT, such as the Registration (RA) and the Location Update Agent (LUA)
Call Control
The setting up of calls, in the MT, is the responsibility of the Terminal Communication Session Manager
(TCSM). The TCSM co-ordinates the setting up of connections used in a call. The actual setup and control
132
of connections is performed by the Layer Network Co-ordinator (LNC). The setup of bearers involved in
the call is the responsibility of the Entity Management Layer Connection Perfromer (EML-CP).
Handover Control
The Layer Network Co-ordinator is responsible for the setup and control of connections used in a TINA
call. It co-ordinates the setup of bearers in the EML-CP and manipulates the connection during handover.
The LNC also encapsulates the handover control procedures required in a call.
Bearer Control
The Entity Management Layer Connection Performer (EML-CP) is responsible for the setup and control of
bearers in TINA. Bearer control procedures, in the EML-CP are used in both handover and call establish-
ment procedures. Bearer control procedures should be unaware of whether the bearer connection set up is
to do with handover or call set up.
Transport Control
Transport control in TINA is the responsibility of the LNC and the EML-CP. The LNC contains the func-
tionality needed to manipulate the transport plane during handover, such as switching and bridging proce-
dures. The EML-CP is responsible for the activation and de-activation of bearers, under the control of the
LNC.
7.5 TINA MT Functional Architecture
The TINA MT functional architecture consists of computational objects rather than functional entities. This
is due to the object-oriented nature of the system. Computational Objects contain data as well as procedures
to manipulate that data as opposed to FEs which are procedural based. Mapping UMTS FEs onto the TINA
network architecture is not straight forward for two reasons [Gra97].
Firstly, the UMTS MT architecture has been designed based on IN and B-ISDN concepts and archi-
tectures. Secondly, entities in TINA are objects, whereas FEs by their name are functions; UMTS entities
are either too granular for example in the case where data should be encapsulated as part of an object or
are not granular enough. The following are possible modifications to UMTS FEs so they fit into a TINA
architecture.
• HOI: HandOver Initiation, this entity is a subset of to HD and encapsulates the HC FE. It performs
the quality measurement function described in section 4.2.3.
• HDU: Handover Decision User. This entity can resident in the MT or in the Network. It acts on
behalf of the user during handover. It contains part of the functionality of the HD and encapsulates
133
the SHRU and HUPU.
• MEFA: MEF on the Active link. This entity measures the quality of the current radio link or links
and is linked to Handover Initiation (HOI). It is a subset of the MEF in that it only measures active
links.
• MEFP: MEF on the Passive links. This entity measures the quality of inactive links such as neigh-
bouring BTS to which an MT should handover. This entity is related to the TINA Handover Decision
User. This entity is a subset of the MEF in that it only measures passive links. The TCCU , which
maintains a list of surrounding cells, is encapsulated within this entity.
• MEFL; MEF for Location Information. This entity monitors the system broadcast channels for in-
formation on the location area and domain in which the terminal is present. Location information is
sent to the LUA.
The remaining UMTS FE can be mapped directly without any major modifications. The Functional
Architecture for the TINA MT is shown in figure 7.12 below.
AHT
RALUA
SHT
UCCA
RBC
SBC
LC
HOCA
kTNC
SBE
RAL (TN)
MAL (TN)kTN
MEFA
RC
HDU
CMC
AU
SAL (TN)
RPL (TN)
DPE
HOI
MEFP
MEFL
Figure 7.12: TINA MT Functional Architecture
As mentioned above many of the UMTS FEs can be re-used directly in TINA. However there are some
significant differences between the TINA and UMTS terminal architectures.
134
Mobility Control FEs
There is no MEF in the TINA MT. Each of the mobility control entities is an object containing data and
procedures to manipulate that data. This increases the interaction between the objects, as there is no central
information resource, e.g. the RA must interrogate the LUA for the location of the MT or for the TMTI
during user registration.
Handover Control FEs
As described above many of the handover FEs have been merged to form the handover computational
objects.
• HandOver Initiation(HOI): Its function is to determine the relative quality of the active links in the
MT. If the quality of a link begins to deteriorate it triggers the HDU.
• HD User(HDU): This entity resides in the MT and acts on behalf of the user during handover. It
maintains a list of nearby BTS and their relative strengths, as well as the set of user preferences
related to handover such as operator preferences and access rights. It decides which BTS is most
desirable to handover to, and communicates with the network to request that a handover takes place.
Other Control FEs
There is a natural control/transport split in the TINA architecture. TINA was designed with the possibility
of using many different types of transport and networks for the transport of user and signalling data over
the kTN and the TN. The use of the same transport plane as described for UMTS in chapter 4 has been
assumed and so the same control entities are present to control the transport functions.
The only difference is for the transport of signalling. Transport of signalling messages is handled by
the kTN and so it makes sense to use a generic control function rather than one specialised for UMTS.
Hence. there is no SNLC in the TINA MT, instead this has been replaced by the Kernel Transport Network
Controller (kTNC).
One of the drawbacks identified for the support of mobility in the TINA service logic was that it would
be difficult to maintain signalling relationships if the location of the MT is changing and its interface ref-
erences would need to be constantly updated. Another drawback was that the service logic would need to
explicitly deal with the movement and mobility of the terminal. The SNL for UMTS provides a mechanism
whereby the TINA service logic and be abstracted away from the mobility of the MT, including the need to
update terminal addresses and interface references as the MT roams in the network.
In TINA some of the SNL services, such as location transparency, are provided by the DPE. However
the DPE provides only a means by which two TINA objects can locate each other and setup a unique
communication relationship. Transport of messages between the objects is still performed by the kTN. If
the SNL were not present then TINA would still need to deal with the mobility of the MT and the DPE at
135
the kTN level. It could be said that the DPE provides location transparency to the TINA objects while the
SNL provides location transparency to the DPE nodes.
7.5.1 Conclusions
TINA has a lot of characteristics which support the easy integration of mobility into the TINA architecture.
TINA is capable of supporting different networks for the transport of data in the TN and the kTN. As such
it has a natural radio independent/radio dependent split. In fact it is more applicable to say that there is a
core set of functionality used to provide TINA services and a second set used to manage and interface to
the underlying transport networks. This allows for the easy introduction of mobility into TINA. One option
is to introduce UMTS as the underlying transport network. In this case no modifications are needed to the
TINA system other than those required to interface to UMTS.
A second approach is to integrate mobility support into the TINA architecture. In this case the core
TINA service logic can remain intact with new objects and procedures introduced to cater for mobility.
This approach is very similar to the overall UMTS approach. In fact many UMTS FEs can be re-used
directly in TINA.
7.6 Emerging Technologies
This section assesses the impact an emerging technology, software radio, on the MT architecture. It shows
how the MT is adaptive and flexible enough to accommodate new technologies and paradigms in mobile
telecommunications systems with minimal impact on the MT control architecture.
7.6.1 Software Radio
As communications technology continues its rapid transition from analog to digital, more functions of con-
temporary radio systems are implemented in software - leading toward the software radio. A software radio
is a radio whose channel modulation waveforms are defined in software [Mit95]. That is, waveforms are
generated as sampled digital signals, converted from digital to analog via a wideband DAC and then pos-
sibly upconverted from IF to RF. The receiver, similarly, employs a wideband Analog to Digital Converter
(ADC) that captures all of the channels of the software radio node. The receiver then extracts, downconverts
and demodulates the channel waveform using software on a general purpose processor. An architecture for
software radio is shown in figure 7.13 [KBW97].
Software radios employ a combination of techniques that include multi-band antennas and RF conver-
sion; wideband ADC and Digital to Analog conversion (DAC); and the implementation of IF, baseband and
bitstream processing functions in general purpose programmable processors. The resulting software radio
extends the evolution of programmable hardware, increasing flexibility via increased programmability. And
136
A/DConverter
D/AConverter
IdealCirculator
DSP
Tx
Rx
Figure 7.13: Software Radio Architecture [KBW97]
in part it represents an ideal that may never be fully implemented but that nevertheless simplifies and illu-
minates tradeoffs in radio architectures that seek to balance standards compatibility, technology insertion
and the compelling economics of today’s highly competitive marketplaces [Mit95].
Software Radio in the UMTS MT
The next generation of mobile systems will need to deliver a wide rage of mobile services and operate
with a wide range of air interface standards [Tay97]. So far this thesis has concentrated on developing and
presenting a flexible control architecture for the UMTS MT capable of supporting the requirements and
features of any radio system. To enable this, the MT architecture has been divided into radio independent
and radio dependent parts.
In the main, the flexibility of the system has been developed through the development and specification
of generic, radio independent features and protocols. Furthermore, the identification of radio indepen-
dent/radio dependent interface in the terminal means that the generic radio independent part of the MT
can be used with any air interface technology; so long as that technology respects the Radio indepen-
dent/dependent interface and offers a standard set of features across it.
It has so far been implicitly assumed that different MT’s are required for different radio access technolo-
gies, albeit utilising a common radio independent part and respecting a standard radio independent/radio
dependent interface in the terminal. While this is efficient in terms of the implementation of higher layer
radio independent features and protocols of which only one set is required; it is inefficient in terms of
the lower layer, radio dependent features which need to be implemented separately for each radio access
technology. Software Radio can be used to facilitate the development of a single, configurable UMTS MT
which can be used to support any radio access technology [EC97].
7.6.2 A UMTS MT Software Radio Architecture
Utilising Software Radio in the UMTS places the following requirement on the MT
• Separation between software radio capable and non-capable parts [FEHD+98]
137
• Use of a flexible functional architecture capable of supporting different radio technologies with a
single set of FEs. [EC97].
• The adoption of sound engineering principles to support the design of reusable and dynamically
configurable software [Dre97].
The MT control architecture developed in this thesis fulfils all the above requirements. The use of a
radio independent/radio dependent interface in the MT provides a natural division between the software
radio capable parts and the rest of the MT. The functional Architecture for the MT presented in chapter 5
contains a set of generic radio dependent FEs which have been shown to be applicable across different radio
technologies, albeit with different behaviour in each system. That is, this thesis has shown that the same
types of radio dependent functionality is required in all systems, even if it implemented differently across
them. Finally the adoption of an object oriented methodology, SOMT, with the identification of separate
functional and non-functional behaviours in the MT architecture has enabled the design of the flexible
and modular MT architecture presented in chapter 6. Such a modular MT design facilitates the dynamic
configuration of the radio dependent FEs to support different functionality and interfaces for different radio
access technologies. Figure 7.14 shows how a software radio architecture can be superimposed on the
MT control architecture without placing any further requirements on the radio independent/radio dependent
division in the MT [FDB98]
RadioIndependentFunctions
RadioDependentFunctions
Radio PhysicalLayer
RI/RD Interface
SoftwareProgrammable
Part
Figure 7.14: Software Radio Architecture in the UMTS MT [FDB98]
Enabling Software Radio in the MT
To enable software radio in the MT some mechanism is needed to control the dynamic configuration of
the radio dependent FEs for the required functional architecture. Also a some means must be found for
downloading software radio related information to the MT. For the latter function two mechanisms have
been proposed [HF98].
The first mechanism entails the downloading of a full description of the radio interface to the MT.
This can then be used to setup the hardware in the MT and to configure the Radio Dependent FEs for the
138
particular radio access technology. This is considered unworkable. The amount of information needed to
describe a radio interface and associated radio dependent technologies is very large and it is implausible to
consider dynamically downloading this to the MT on a semi-regular basis [HF98].
The second mechanism is the use of an embedded toolbox in the MT capable of supporting any number
of radio interfaces. When the terminal enters a network it scans for the particular radio access technology
being used and dynamically switches the hardware and lower layer functions to cater for that access tech-
nology. The advantages of this system are that no information need be downloaded to the MT. Also the
use of efficient coding and descriptions for different access technologies will minimise the amount of data
storage in the MT needed for the access technology descriptions [HF98].
The main disadvantage to the second mechanism is that it is not easy to cater for new radio access
techniques, other than those described in the MT. One solution would be to write the radio access technology
descriptions on removable component such as ROM chips or SIM Cards. When new radio interfaces are
deployed the SIM card or ROM chip can be upgraded with the new interface description. However this
is likely to be unwieldy and it does not allow for the fast upgrade of all MTs to the new radio access
technology.
A more flexible method is proposed here which lies between the two mechanisms described above.
In this mechanism, a generic set of functional entities and algorithms is described in the MT. For each
radio access technology, a set of parameters can be downloaded from the network to configure these FEs
and algorithms for the particular access technology. This combines the best features of the two earlier
mechanisms. The information downloaded from the network and used to configure the MT is minimized.
At the same time the information contained in the MT for different radio technologies is also minimized.
The UMTS MT architecture developed in this thesis is ideally suited to this third enabling mechanism
for software radio. The use of a control/transport split in the MT architecture in section 5.4 means that
the transport plane of the MT consists only of ”dumb” transport algorithms which must be configured
by the transport control FEs. Furthermore, it should be possible to maximise the common aspects of the
radio dependent FEs so that they may be configured for different access technologies using a simple set of
parameters.
The current MT architecture can therefore be extended to cater for software radio; if it is assumed that
the radio dependent control FEs can be described in a more common fashion than used so far in this thesis.
The transport plane is already described using configurable algorithms and so is suited for use with software
radio. Finally a Software Radio Control Entity (SRCE) must be included in the MT to receive software radio
related data and parameters from the network and to configure the radio dependent parts of the MT for the
radio access technology to be utilised. The software radio capable part of the MT architecture presented in
7.14 is expanded in 7.15 to show the relationship between the SRCE and the radio dependent parts of the
MT architecture. The SRCE configures the radio independent control entities for the particular radio access
technology to be used. The transport plane is configured by the transport control FEs.
139
RBCSBE
RAL
RPL
LC
MEF HC
Radio Independent / Radio Dependent Interface
SRCE
Figure 7.15: Radio Dependent part of the MT Software Radio Architecture
7.7 Conclusion
This chapter has analysed the UMTS MT and compared it with existing and evolving telecommunications
and technologies. Each system has different application areas and some, such as GSM and DECT have
been designed to explicitly cater to a limited set of requirements. However the main terminal functions
as outlined in chapter 4 can be identified in the MT for each of the systems described. These can then be
modelled using the UMTS Functional architecture developed in this thesis. This chapter also described
some of the similarities between the TINA and UMTS terminal architectures and applied the UMTS MT
architecture to TINA. Furthermore the impact of two new technologies in the mobile telecommunications
were investigated and applied to the UMTS MT.
There are fundamental differences in the architecture and design of GSM, DECT and UMTS terminals.
The layered approach adopted in GSM and DECT contrasts with the Control/Transport split developed for
the UMTS MT. However the main groups of functionality of the MT remain essentially unchanged and it
is possible to impose a control/transport split on the second generation systems. In fact DECT already has
a simple control/transport split with many of the MT bearers and transport control functions located in the
LLME. The adoption of an FE based architecture for these systems allows for the clear identification of
specific MT functions and their role in the system.
The 2nd generation MTs can be viewed as consisting of radio independent and radio dependent aspects.
Because they were built to cater for specific systems the ratio of radio dependent to radio independent
FEs is much higher than for the UMTS MT developed in chapter 5. For both the DECT and GSM, it
should be possible to reuse the lower layers and the radio interface with a different set of radio independent
higher layer FEs as long as the limitations of the underlying radio interfaces, such as the use of an integrated
signalling and data bearer in DECT are respected. Some entities such as the CC can be replaced or upgraded
with minimal impact, whereas others such as the HD or RBC cannot be replaced without affecting the
overall behaviour of the terminal.
Both TINA and UMTS foresee the use of multiple networks for transport purposes. In fact it is possible
to operate a TINA network utilising UMTS as the core transport network. However it is more elegant and
140
more efficient to integrate mobility into TINA to provide more efficient mobile services. If this is the case
then many similarities can be made between the UMTS MT and the TINA MT and many of the UMTS FEs
can be used to support mobility in TINA
TINA has already adopted a control/transport split in its service architecture which simplifies the use
of many different network types in the kTN and TN. Also the use of a radio dependent/radio independent
split is natural to the TINA architecture and so TINA, like UMTS, can be used to provide mobility utilising
many different existing and novel radio systems.
The UMTS is flexible and adaptive and is able to accomodate new technologies in mobile telecom-
munications such as Software Radio. Software Radio allows the physical and lower layers of the MT to
be dynamically reconfigured for any air interface. Using Software radio in the MT meants that the radio
dependent parts of the terminal can be as flexible as the radio independent parts. This chapter has shown
how Software Radio can be introduced into the UMTS terminal architecture with minimum impact on the
radio dependent aspects of the terminal.
141
142
Chapter 8
Conclusions
8.1 Overall Conclusions
Mobile systems are complex. To cater for the needs of multiple radio access technologies and to provide a
wide range of services and features to users in a number of diverse environments; a flexible and adaptive
strategy must be taken towards control in the system. This thesis developed a flexible control architecture
for the UMTS MT. The UMTS MT incorporates B-ISDN and IN concepts to support a wide range of
data services and system features. The adoption of a Radio Independence/radio dependent division and a
control/transport split have been used to design an architectural template for the UMTS MT. This template
can be applied to any radio access technology. It contains a radio independent part which is unchanged
across all technologies and a radio dependent part which is different for each technology. The flexibility of
the architecture was further enhanced through the adoption of an object oriented design philosophy. The
following conclusions have been drawn from the development of the MT architecture.
8.1.1 Flexibility in Mobile Systems
In general, existing second generation mobile systems, such as GSM and DECT do not provide the flex-
ibility necessary to support advanced system features and data services. GSM itself will play a strategic
role in the evolution of third generation systems. Additional features for service creation and the provision
of higher data rates for multimedia and Internet services are being added to the GSM system through the
development and deployment of CAMEL, HSCSD, GPRS and EDGE. The resulting evolved GSM sys-
tem will form the basis for development of the third generation system for Europe, the Universal Mobile
Telecommunications System.
Three components have been identified to develop an open flexible UMTS network, B-ISDN, IN and
Radio Independence. B-ISDN, through the use of ATM and the AALs provides a flexible, extendible
platform for the development of advanced multimedia and Internet data services. At present, the B-ISDN
143
UNI is not suitable for adoption in UMTS. A number of extensions for the UNI have been identified: support
for call and bearer separation, support of redundant call branches in a call during handover, and extensions
to the addressing capabilities of the UNI to support entities other than the terminal and Local Exchange in
the access network.
The adoption of IN into UMTS will allow the rapid development and deployment of UMTS services.
However, the current IN standards are not capable of providing full mobility support as required in UMTS.
In any case the adoption of IN in UMTS makes sense from a both service development and architectural
point of view and much work has been done to integrate UMTS and IN concepts including the development
of an IN DFP for UMTS.
The third component for flexibility in UMTS is not a technology, but a concept. The adoption of
a Radio Independent/Radio Dependent split in the UMTS Network architecture manifests itself in two
ways. The first is the separation of the Core and Access Networks in UMTS and the development of a
standardised interface between them, the Iu interface. The adoption of such a split and a standardised
interface facilitates the adoption of multiple core and access network technologies for UMTS. The core
networks are radio independent and are abstracted away from mobility and radio aspects by the Iu interface.
The UMTS access network will be concerned with the support of different radio systems and technologies.
Within the access network, a radio independent/dependent split can also be applied. Many of the features
supported by the Access Network, such as call control, mobility management and handover are necessary
across all radio technologies. These radio independent features can be supported by the access network
in a single, standardised manner through the adoption of generic network entities and functions in the
network architecture. Radio dependent functions are provided by specialised functions in the network
architecture. These radio dependent functions are concerned with the manipulation of radio bearers and the
radio interface and can be confined to the edge of the Access Network.
In summary, a UMTS network architecture will contain both the B-ISDN and IN components. It will
be split into a core network and an access network separated by the Iu interface. The access network
will exhibit radio independent and radio dependent aspects. The Radio Independent aspect will be located
towards the core of the network. The radio dependent aspects will be located towards the edge of the
network.
8.1.2 Derivation of the MT Architecture
The main focus of the thesis was the development of a flexible architecture for the UMTS mobile terminal.
The UMTS MT consists of a control plane and a transport plane. It is involved in every major system
procedure. The first step in the development of the MT architecture was the identification of the main
control groupings in the MT. The mobility control group manages personal mobility in the MT. The call
control group is responsible for the setup and management of calls, connections and bearers in the system.
The handover control group in the MT is involved with the UMTS handover initiation and handover control
144
procedures. It interacts with the call control group in the MT for the manipulation of connections and
bearers during handover. The bearer control group is concerned with the setup of radio bearers and channels
between the MT and the network. The transport control group is responsible for the management of the
transport plane in the terminal.
The call control group contains functionality for the co-ordination of handover, bearer and transport
control in the MT. This functionality can be invoked either by the handover control group or by the call
control group itself. It is used to manage the setup of bearers and the manipulation of the transport plane
during call and handover procedures. In effect the bearer control group and transport control group offer a
set of services to be utilised by the call control group and handover control group. The call control group is
based on B-ISDN functionality. The handover control group can be considered as an IN entity in the MT.
The MT coordination function in the call control group can be seen as a bridge between the B-ISDN and IN
DFP models for UMTS. Modifications to the IN DFP are proposed in chapter 4 to reflect this bridge between
call control and handover in the IN DFP. The MT co-ordination function may be better positioned outside
of the call control group and as part of the bearer control group. However as it is essentially a mapping
between a call and its constituent connections and bearers it is obviously a radio independent function. The
functionality contained in bearer control is radio dependent and so the radio independent MT co-ordination
function is better maintained as part of the radio independent call control group.
Some differences between mobile systems are not radio dependent but reflect different system concepts
and considerations. The most obvious of these is handover. There are many different types of handover
which can be used in a mobile system. In itself handover is not radio dependent, although the information
which triggers it may be. Functionality is needed in UMTS and the MT to cater for different handover types,
such as hard handover and soft handover in a radio independent fashion. The MT co-ordination function
in call control can be configured to manipulate bearers and connections according to the system handover
type.
The transport plane in the MT contains functions for the manipulation of data streams in the MT. Trans-
port Functions, are grouped into layers, according to the services provided. Each layer can then be easily
classified as containing radio independent or radio dependent functionality. The Service Adaptation Layer
(SAL) provides the transport functions required for the support of different services, e.g. source coding
for speech or ARQ for non delay sensitive services. The Mobility Adaptation Layer (MAL) abstracts the
higher layers from any mobile specific features of the lower layers by providing a set of mobility transparent
services such as switching and bridging during handover. The Radio Adaptation Layer(RAL) is radio de-
pendent and provides access to the set of radio bearers provided by the underlying radio layers. The Radio
Lower layers (RLL) provide access to the physical radio channels at the air interface.
The MT transport plane also contains functionality for the transport of signalling data between the
MT and the Network. The UMTS Signalling Network Layer provides location transparent routing for the
transport of signalling messages between the MT and the Network. The SNL thus abstracts the control
145
plane away from any transport related impacts on signalling caused by the mobility of the terminal. The
SNL provides a connectionless transport service to the control functions as this is more efficient in a mobile
system. The use of the SNL greatly simplifies the control/transport relationships in the MT. Control plane
functions do not need to be concerned with the opening of network layer signalling links to the network nor
with the maintenance of those links during handover.
8.1.3 Specification and Design of the MT Architecture
The Race Monet Methodology was used to derive a functional architecture for the MT control plane using
the control plane groups and the UMTS network architecture. Each of the control plane groupings can be
broken down into a set of interacting Functional Entities, which perform individual functions in the MT.
The relationships between the FEs was described using directed associations.
A control/transport split was applied to the functional entities. This was used to separate the FEs accord-
ing to whether they were involved in system wide procedures, such as handover or call control, or whether
they were involved in the manipulation of the MT transport plane. Those FEs involved in transport con-
trol procedures need to be reconfigured to support different system features such as soft or hard handover.
There are radio independent and radio dependent transport control FEs in the MT. Using a control/transport
division as well as a radio independent/radio dependent division in the MT identifies those transport control
functions which are radio independent but which must be configured to support different handover types.
These radio independent transport FEs are concerned with the manipulation of the MAL. Separate FEs exist
for hard handover and soft handover, the SBC and SMC respectively, and only one of these is present in
the MT at a time. The RC, which is part of the call control functions and acts is the co-ordinating function
between call, handover, bearer and transport control in the MT also needs to be configured according to the
system handover type.
A radio independent/dependent boundary was identified in the UMTS MT. At this boundary, the radio
dependent FEs provide a radio independent interface to the radio independent FEs for the manipulation of
user and signalling bearers in the MT. The advantage of such an interface is that it allows the same radio
independent FEs to be used in any MT, with any radio access technology. The adoption of such a radio
independent interface limits the number and types of services to be provided. It is not possible to define a
boundary so broad that it encompasses every feature of every radio access technology. Initially a basic set
of services for voice and data based on evolved GSM can be defined. A set of enhanced core services to
provide different types of data services such as real time data or unconstrained delay data services at higher
data rates can also be defined.
Using the functional architecture and the MT FEs, design options for the MT were investigated using
the ITU’s Specification and Description Language and the SDL Object Modelling Technique. The MT FEs
lend themselves to being designed using SOMT. SDL can be used to represent the object model using SDL
Block Diagrams. The Functional Model and Dynamic Models required to describe the behaviour of the MT
146
FEs and the FE functions can be described using the extended finite state machines supported in SDL as
SDL processes.
The model for the MT architecture was expanded to encompass the non functional requirements of
the MT. The non functional requirements of the MT are concerned with the configuration of the MT by
system management and the mechanics of interfacing to the transport plane in the MT. An FE manager
was developed to handle the MT’s non functional requirements. This abstracts the FEs identified in the
functional architecture away from transport and configuration concerns in the MT. For example it allows
for the use of either TCAP or ACSE ROSE to set up relationships between FEs in the MT and the network.
The FE does not need to be concerned with the setup of TCAP or ROSE associations; as the FE manager
will support the state machine needed and will encapsulate FE messages into the correct protocol. So the
same FE can be used over either TCAP or ACSE ROSE and each can evolve independent of the other.
A SOMT model for the system representing both functional and non functional requirements was de-
veloped. The biggest problem with the initial model was that each FE and FE Manager was represented
separately and this led to a proliferation of objects. This blurred the FE relationships, which were rep-
resented by relationships between FE managers. An improved abstract model of an FE consisting of an
aggregate of an FE Manager and an FE State Machine, representing the FEs functional requirements was
developed. This allowed a SOMT model, which at the highest level looks like the MT functional architec-
ture, to be developed.
8.1.4 Application of the MT architecture
The MT control architecture has been applied to the GSM. DECT and TINA systems. The architecture
was applied to the 2nd generation systems, DECT and GSM to test the radio independent/ radio dependent
division in the MT. Both systems have more limited architectures than UMTS and so less functionality
was necessary to provide the radio independent FEs in mobility control, handover control and transport
control in these systems. The same radio independent UMTS FEs can be utilised in both GSM and DECT
architectures. In fact there is no reason why the entire set of radio independent UMTS FEs cannot be used
in both the DECT PP and the GSM MT. This would greatly extend the range of services available over the
DECT and GSM air interfaces.
TINA aims to provide an architecture for the development and deployment of future services. The
TINA architecture is designed to run over different and diverse networks and contains functionality to setup
and manage TINA sessions regardless of the underlying transport system. There are two approaches to
mobility in TINA. The first is to deploy TINA over a mobile system, such as UMTS. In this scenario TINA
is unaware of mobility and only sees UMTS as a transport mechanism.
The second approach involves the integration of mobility into TINA. In this approach there are many
similarities between the UMTS and TINA terminal architectures. TINA already supports the separation of
call and bearers, it contains a control/transport split to facilitate the use of different transport technologies.
147
TINA even has a very basic radio independent/dependent division separating a core set of functionality
required to provide TINA services from the functionality required for the setup and manipulation of the
transport network. This division of functionality provides for a very natural mapping of the UMTS archi-
tecture into TINA.
TINA is based very heavily on object oriented techniques, particularly ODP. The developed UMTS MT
architecture is function oriented and some modifications need to be made to the UMTS FEs to fit them into
a TINA architecture. TINA, which has been developed using more advanced technologies and techniques
than UMTS is more properly considered as an evolutionary step for UMTS rather than as a competitive
system.
Applying the MT architecture to the GSM MT and DECT PP highlighted the flexibility of the radio
independent/radio dependent and control/transport divisions in the UMTS MT. However both second gen-
eration systems do not require the full functionality of the UMTS MT architecture
The MT architecture is flexible enough to accommodate new and innovative technologies in mobile
telecommunications. The radio independent/radio dependent split lends itself to the application of Software
Radio techniques in the MT. Software Radio provides for the dynamic reconfiguration of the radio lower
layers in the MT to access different radio interfaces. One of the requirements for Software radio is that a
clear interface exist between the non Software Radio parts of the MT and the reconfigureable parts. The
Radio independent/radio dependent boundary in the MT can be used as such an interface, separating the
Software Radio configurable radio dependent parts of the MT from the static radio independent ones.
8.2 Further Work
At the time of writing UMTS is currently under discussion for standardisation. However due to the size
and complexity of the UMTS system, there exists very significant potential for further research and investi-
gation. Furthermore, UMTS is likely to be standardised and rolled it in phases and so the opportunity will
exist to extend the capabilities and services of the system as UMTS matures. Some of the more interesting
research areas in UMTS are discussed in the next sections.
8.2.1 Standardisation
As UMTS approaches maturity, standards related to the operation of the network, the terminal and the
air interface will be produced. Many of the ideas developed in this thesis can be applied to the resulting
system. Further refinement and simulation is needed to fully validate the radio independent/dependent and
control/transport splits developed in this thesis. For example the OPNET tool could be used to assess the
performance of the architecture. These results could then be used to feed the standardisation effort and to
encourage the creation a flexible, adaptive architecture for the UMTS terminal.
148
8.2.2 TINA
In chapter 7 it was shown how the UMTS architecture can applied to the TINA mobile terminal. TINA
itself is a new architecture and as such has much scope for further research. A full analysis of the TINA
mobile terminal requires that the MT be respecified and redesigned using the TINA Framework and Service
Architecture. This involves the development of a more object oriented MT using methodologies such as
ODP and UML. Also of interest here is the support of mobility in CORBA and development of a DPE
capable of supporting mobile applications.
8.2.3 Use of Mobile Agents
The use of Mobile Agents for the downloading of new services and applications represents a fundamental
shift in the development of telecommunications. There are many potential areas for the use of mobile agents
in the UMTS terminal. Mobile agents may be downloaded from the MT to the network to act on behalf
of the terminal in procedures such as location update or session setup. From a user point of view, mobile
agents can be used to ensure that a core set of services are automatically and transparently downloaded to
the terminal the user is working on, supporting a Virtual Home Environment for the user which remains
constant regardless of the particular terminal or terminal type being used. Another possible use of Mobile
Agents is in Software Radio. A Software Radio Agent describing the radio interface present in the network
could be downloaded to the MT, updating of the Software Radio parts of the terminal.
8.2.4 Software MT
The development of Software Radio will require the use of a common language for the definition and
description of the radio interface that can be understood by any software radio enabled terminal. Extending
this concept to the non-Software Radio of the MT will result in a generic definition and description language
for protocols and FEs in the MT. This would allow the entire protocol suite and functionality required in
the MT to be downloaded as the MT roams into different third generation networks. The concept of Radio
Independence would no longer be needed in a system using such a Terminal Description Language.
8.2.5 Internet MT
The service paradigm used in this thesis is primarily taken from B-ISDN. The growth of the Internet in
recent years has established Internet services as the dominant service type. While the current UMTS ar-
chitecture can be used to support Internet services the development of an architecture specifically oriented
towards Internet services and applications remains a topic for investigation. An Internet specific architec-
ture could be developed to explore the use of TCP and IP in the terminal architecture and any extensions
required to cope with mobility. Furthermore the use of resource reservations, such as RSVP, and the support
they offer for handover in the MT could be considered.
149
8.2.6 Security
This project has not investigated security in UMTS to any great depth. Security, particularly authentication
nd encryption remain major areas of study in telecommunications and in mobile telecommunications in
particular. The development of secure authentication and encryption model for UMTS may have profound
consequences on the architecture developed in this thesis.
150
Bibliography
[Abe95] T .W. Abernathy. Intelligent Networks, standards and services. BT Technology Journal, vol
13, no 2, April 1995.
[AGT93] J. Apfelbeck, K. Georgokitsos, and K. A. Turban. UMTS Mobility Management. IEEE
Electronics and Communication Engineering Journal, June 1993.
[BCDH96] E. Berruto, G. Colombo, K. David, and R. Hillebrand. RAINBOW: a Radio Independent Net-
work Platform for UMTS. Proceedings of the ACTS Mobile Telecommunications Summit,
Granada, November 1996.
[BCM+97] E. Berruto, G. Colombo, P. Monogioudis, A. Napolitano, and K. Sabatakakis. Architectural
Aspects for Evolution of Mobile Communications towards UMTS. IEEE Journal on Selected
Areas in Communications, vol 15, no 8 edition, October 1997.
[BGPR98] M. Barry, L. Gray, B. Perrin, and G. Reyniers. Control Plane Management in the Rainbow
System. Proceedings of the ACTS Mobile Telecommunications Summit, Rhodes, 1998.
[BSSE95] E. Berruto, W. Schott, and B. Sjkvist-Eriksson. Radio Protocols for the CODIT UMTS
System. Proceedings of the RACE Mobile Telecommunications Summit, Aalborg, November
1995.
[CS96] P. Cappiello and L. Santabarbara. IN Based Solution for Cordless Terminal Mobility. Alcatel
Telecommunications Review, 1st Quarter 1996.
[Del92] CEC Deliverable. R2066/CSELT/MF2/DS/P/016/b1 “Description of Radio Link Driven and
Network Driven Handover”. December 1992.
[Del93a] CEC Deliverable. R2066/VTT/GA4/DS/P/059/b1 “Required architectural and functional
support in the network and network elements”. December 1993.
[Del93b] CEC Deliverable. R2066/FACE/GA3/DS/P/029/b1 “UMTS Functional Model - Draft”.
February 1993.
151
[Del94a] CEC Deliverable. R2066/CSELT/MF2/DS/P/090/b1 “Definition of Handover Protocols”.
December 1994.
[Del94b] CEC Deliverable. R2066/VTT/GA4/DS/P/065/b1 “Evaluation of supporting protocol
stacks”. June 1994.
[Del94c] CEC Deliverable. R2066/FACE/GA3/DS/P/033/b1 “UMTS Network Architecture - Draft”.
September 1994.
[Del95a] CEC Deliverable. R2020/CSE/RP/DS/P/048/b1 “Final Report on Radio Protocols”. August
1995.
[Del95b] CEC Deliverable. AC015/BELL/CIT/DS/P/002/b1 “Rainbow Demonstrator Architecture and
Services”. December 1995.
[Del95c] CEC Deliverable. R2066/BT/PM/DS/P/099/b2 “Baseline Document of Functional Models”.
December 1995.
[Del95d] CEC Deliverable. R2066/RMR/UNA2/DS/p/107/b1 “Recommendations of UMTS Integration
Scenarios in the B-ISDN Backbone”. December 1995.
[Del95e] CEC Deliverable. R2084/AMCF/PM2/DS/R/044/b1 “ATDMA Systen Definition Issue 3”.
March 1995.
[Del96a] CEC Deliverable. The Exodus Project “An Overview of the Programme and Project“. 1996.
[Del96b] CEC Deliverable. AC015/BELL/CIT/DS/L/011/b1 “Baseline Document on high level control
specifications for the RAINBOW demonstrator”. December 1996.
[Del96c] CEC Deliverable. AC015/CSELT/RAP1/DS/R/008/b1 “RAS Architectures: definiton, alloca-
tion and specification of MT/BTS functional entities”. October 1996.
[Del96d] CEC Deliverable. AC015/UL/RAP1/DS/R/009/b1 “Specification of the non emulated UMTS
MT/BTS protocols and related migration issues”. October 1996.
[Del96e] CEC Deliverable. AC015/SEL/RMC1/DS/I/006/b1 “Specification of the Mobility Application
Interfaces in the Demonstrator Platform”. September 1996.
[Dre97] A. Drewer. Software Engineering Considerations for Software Radio. Proceedings of the
ACTS Mobile Telecommunications Summit, Aalborg, October 1997.
[DS98] J. DeVriendt and Paul Simmons. Report on system concept studies in RAINBOW. Proceed-
ings of the ACTS Mobile Summit, Rhodes, June 1998.
152
[EBG96] A. Elberse, M. Barry, and G.Fleming. DECT Data Services. Proceedings of DECT in Fixed
and Mobile Networks, Paris, France, July 1996.
[EC97] H. Erben and P. Crichton. Software Radio Architecture for UMTS. Proceedings of the ACTS
Mobile Telecommunications Summit, Aalborg, October 1997.
[Ek95] A. Ek. The SOMT Method. Telelogic, 1995. Preliminary Product Information.
[ETS93] ETSI. ETR 312 Framework of network Architecture, interworking and integration for
the Universal Mobile Telecommunications System (UMTS). European Telecommunications
Standards Institute, September 1993.
[ETS95a] ETSI. ETR 300 176 1-9 “Radio Equipment and Services (RES), Digital Enhanced Cordless
Telecommunications (DECT), Common Interface Parts 1-9“. European Telecommunications
Standards Institute, 1995.
[ETS95b] ETSI. ETSI TC-RES 300 175-3 “Digital European Cordless Telecommunications (DECT)
Part 3: Medium Access Control Layer”’. European Telecommunications Standards Institute,
1995.
[ETS96] ETSI. ETR-312 “Scenarios and Considerations for the introduction of the Universal Mobile
Telecommunicatios (UMTS)“. European Telecommunications Standards Institute, July 1996.
[ETS98] ETSI. ETR 101 111 “General Requirements of UTRA“. European Telecommunications
Standards Institute, January 1998.
[FDB98] G. Fleming, P. Diaz, and E. Berruto. A Radio Independent Network - The Enabler for Soft-
ware Radio. Proceedings of the ACTS Mobile Summit, Rhodes, June 1998.
[FEHD+98] G. Fleming, A. El-Hoyidi, J. DeVriendt, G. Nikolaidis, F. Piolini, and M. Maraki. A Flexible
Network Architecture for UMTS. IEEE Personal Communicatons Magazine, vol 5, no 2
edition, March 1998.
[FH98] P. Ferguson and G. Huston. Quality of Service in the Internet: Fact, Fiction, or Compromise?
Proceedings of INET’98, Geneva, Switzerland, July 1998.
[Fle94] Gary Fleming. Application layer signalling protocols for umts. Master’s thesis, University
of Limerick, 1994.
[FNA+97] G. Fleming, G. Nikolaidis, N. Alonistioti, L. von Allmen, A. El-Hoiydi, B. Perrin, and
M. Maraki. Architecture and Design of the Rainbow Mobile Terminals, Base Stations and
Mobility Servers. Proceedings of the ACTS Mobile Summit, Aalborg, October 1997.
153
[For93] ATM Forum. ATM User Network Interface Specification Version 3.0. Prentice Hall, Septem-
ber 1993.
[For94] ATM Forum. ATM User Network Interface Specification Version 3.1. Prentice Hall, Septem-
ber 1994.
[For96] ATM Forum. ATM User Network Interface Specification Version 4.0. Prentice Hall, July
1996.
[Gom84] H. Gomma. A Software Design Method for Real Time Systems. CACM, Vol27, no.9, Septem-
ber 1984.
[Gra97] William Gray. Support for mobility within intellignet networks. Master’s thesis, University
of Limerick, 1997.
[Gri97] Ivan J Griffin. An application framework for access to b-isdn services. Master’s thesis,
University of Limerick, 1997.
[HF98] H. Harada and M. Fujise. Multimode Software Radio System by Parameter Controlled and
Telecommunication Toolbox Embedded Digital Signal Processing Chipset. Proceedings of
the ACTS Mobile Summit, Rhodes, June 1998.
[Hil95] S.G. Hild. A Brief History of Mobile Telephony. University of Cambridge Technical Report,
January 1995.
[IT88] ITU-T. Recommendation I.321 “Vocabulary of Terms for ISDNs”. International Telecom-
munication Union, Geneva Switzerland, September 1988.
[IT91a] ITU-T. Recommendation I.321 “B-ISDN Protocol Reference Model and its Applications”.
International Telecommunication Union, Geneva Switzerland, April 1991.
[IT91b] ITU-T. Recommendation I.324 “ISDN Network Archietecture”. Internation Telecommuni-
cation Union, Geneva, Switzerland, October 1991.
[IT92a] ITU-T. Recommendation Z.100 “SDL Formal Definition”. International Telecommunica-
tions Union, Geneva, Switzerland, June 1992.
[IT92b] ITU-T. Recommendation Q.1201 “Principles of Intelligent Network Architecture”. Interna-
tional Telecommunications Union, October 1992.
[IT92c] ITU-T. Recommendation Q.1202 “Intelligent Network Service Plane Architecture”. Inter-
national Telecommunications Union, October 1992.
[IT92d] ITU-T. Recommendation Q.1203 “Intelligent Network Global Functionsl Plane Architec-
ture”. International Telecommunications Union, October 1992.
154
[IT93a] ITU-T. Recommendation I.363 “B-ISDN ATM Adaptation Layer (AAL) Specification”. In-
ternation Telecommunication Union, Geneva, Switzerland, March 1993.
[IT93b] ITU-T. Recommendation Q.1204 “Intelligent Network Distributed Functional Plane Archi-
tecture”. International Telecommunications Union, March 1993.
[IT93c] ITU-T. Recommendation Q.1205 “Intelligent Network Physical Plane Architecture”. Inter-
national Telecommunications Union, March 1993.
[IT93d] ITU-T. Recommendation I.320 “ISDN Protocol Reference Model”. Internation Telecommu-
nication Union, Geneva, Switzerland, November 1993.
[IT94] ITU-T. Recommendation Q.2110 “B-ISDN Signalling ATM Adaptation Layer (SAAL)
overview description”. Internation Telecommunication Union, Geneva, Switzerland, July
1994.
[IT95] ITU-T. Recommendation Q.2931 “B-ISDN application protocols for access signalling”.
Iternational Telecommunications Union, Geneva, Switzerland, February 1995.
[IT96] ITU-T. Q.FNA “Network Functional model for FPLMTS”. International Telecommunica-
tions Union, June 1996.
[IT97a] ITU-T. ITU News “IMT2000-the next challenge; an interview with M Callendar”. Interna-
tion Telecommunication Union, Geneva, Switzerland, January 1997.
[IT97b] ITU-T. Recommendation Q.65 “The unified functional methodology for the characterization
of services and network capabilities”. International Telecommunications Union, Geneva,
Switzerland, June 1997.
[KBW97] P. Kenington, D. Bennet, and R. Wilkinson. RF Transceiver Architectures for Software De-
sign. Proceedings of the ACTS Mobile Telecommunications Summit, Aalborg, October
1997.
[KMS94] J. Korinthios, H. Mitts, and E. Sykas. Scenarios for the Integration of the Universal Mo-
bile Telecommunications System (UMTS) into Broadband ISDN. Proceedings of the 44th
Vehicular Technology Conference, Stockholm, June 1994.
[Kra98] J. Kramer. UMTS Forum Doc TG.21“3G Service Requirements and Concepts”. April 1998.
[KS94] J. Korinthos and E. Sykas. Scenarios for UMTS Protocol integration into B-ISDN: Signalling
Protocol view. Proceedings of the RACE Mobile Workshop, Amsterdam, May 1994.
[Kya95] Othmar Kyas. ATM Networks. Thompson Publishing, London, England, 1995. ISBN 0-442-
0200-2.
155
[LdLGdV96] N.H. Loukas, M. de Lignie, K. Georgokitsos, and J. de Vriendt. Design and Demonstration
of Call/Connection Control Signalling in UMTS Access Network. Proceedings of the ACTS
Mobile Telecommunications Summit, Granada, November 1996.
[LdVMP97] N.H. Loukas, J. de Vriendt, M. Maraki, and M. Peters. Call/Connection Control Signalling
in UMTS Acces Network. Proceedings of the ICT, Melbourne, April 1997.
[LWF+97] N.H. Loukas, A. Weber, G. Fleming, M. Peters, P. Morrisey, S. Faccin, M. Maraki, and
T. Norp. Call and Handover Control Protocols for UMTS. Proceedings of the ACTS Mobile
Telecommunications Summit, Aalborg, October 1997.
[Mad97] Daniel J Madden. An investigation of the signalling network layer for umts. Master’s thesis,
University of Limerick, 1997.
[McN98] D. McNamara. An interworking unit between dect and umts. Master’s thesis, University of
Limerick, 1998.
[MH96] H. Mitts and H. Hansen. A simple and efficent Routing Protocl for the UMTS Access Network.
Mobile Network and Nomadic Applications, 1996.
[Mit95] J. Mitola. The Software Radio Architecture. IEEE Communications Magazine, May 1995.
[MLKN96] H. Mitts, G. Luijtien, J. Korinthios, and J. Nelson. Connectionless Signalling Network Layer
for UMTS. IEEE Personal Communicatons Magazine, June 1996.
[Mor95] Conor Morris. Am sdl based intelligent network service development environment. Master’s
thesis, University of Limerick, 1995.
[MP92] M Mouley and M Pautet. The GSM System for Mobile Communications. Published by the
authors, 1992.
[NA696] ETSI NA6. NA-61301 “IN/UMTS Framework Documnet v8.2.0“. European Telecommuni-
cations Standards Institute, January 1996.
[NBFM96] J. Nelson, M. Barry, G. Fleming, and D. Madden. UMTS Signalling Network Layer and
its verification using SDL. Proceedings of the ACTS Mobile Telecommunications Summit,
Granada, November 1996.
[Nor94] Toon Norp. Protocol Stacks for an Integrated UMTS user access network. Proceedings of
the Race Mobile Workshop, Amsterdam, May 1994.
[PCK98] R. Peterson, A.M. Corless, and A. Kelleher. Third Generation Cellular Systems - A Man-
agement Challenge, volume 2 of Communicate, Broadcom’s Technical Journal. Broadcom
Eireann Research Limited, Dublin, Ireland, July 1998.
156
[Pre94] R.S. Pressman. Software Engineering A Practioners Approach. McGraw Hill, european
edition edition, 1994.
[RBP+91] J. Rumbagh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object Oriented Modelling
and Design. Prentice Hall, 1991.
[Ric94] D. Richards. Application of IN concepts and B-ISDN signalling concepts to UMTS. Proceed-
ings of the RACE Mobole Workshop, Amsterdam, May 1994.
[RSO+94] R. Reed, J. Smith, A. Olsen, O. Faergemand, and B. Moller-Pedersen. Systems Engineering
using SDL-92. North-Holland, 1994.
[Sar93] B. Sarikaya. Principles of Protocol Engineering and Conformance Testing. Ellis Horwood,
1993.
[SFB+97] A. Saidi, G. Fleming, M. Barry, A. El-Hoyidi, B.Perrin, G. Nikolaidis, L. Modeas, and
F.Piolini. Rainbow Demonstrator Transport Chain. Proceedings of the ACTS Mobile
Telecommunications Summit, Aalborg, October 1997.
[Som92] I. Somerville. Software Engineering. Addison-Wesley, third edition edition, 1992.
[SSR89] R. Saracco, J. Smith, and R. Reed. Telecommunications Systems Engineering using SDL.
Elsevier Science Publishers B.V., 1989.
[Swa97] R. Swain. Evolving the UMTS Vision. ACTS Mobility, Personal and Wireless Communcia-
tions Domain, 1997.
[Tas94] CLAUDE Taskgroup. R2066/PM1/PTT-NL/396 ”Report of the CLAUDE Taskgroup”. De-
cember 1994.
[Tay97] C. Taylor. Using Software Radio in 3rd Generation Communication Systems. Proceedings
of the ACTS Mobile Telecommunications Summit, Aalborg, October 1997.
[TCA93] Recommendation Q.771-Q.775 “TCAP Specifications”. Iternational Telecommunications
Union, Geneva, Switzerland, February 1993.
[TIN94] Engineering Modelling Conecepts (DPE Architectue) “Document No. TB NS.005 2 0 94”.
Telecommunications Information Networking Architecture Consortium, December 1994.
[TIN95] Overall concepts and principles of TINA “Document No. TP MDC.018 1.6 94”. Telecom-
munications Information Networking Architecture Consortium, January 1995.
[TIN96a] Terminal Mobility “Document No. TR JH 003 2.0 96”. Telecommunications Information
Networking Architecture Consortium, December 1996.
157
[TIN96b] TINA Service Architecture. Telecommunications Information Networking Architecture Con-
sortium, March 1996.
[T.N98] T.Nilsson. Toward Third Generation Wireless Communication, volume 2 of Ericsson Review
- The Telecommunications Technology Journal. Ericsson, June 1998.
[Tur93] K. Turner. Using Formal Description Techniques, An introduction to ESTELLE, LOTOS and
SDL. Wiley, 1993.
[USM95] A. Urie, M. Streeton, and C. Moutot. An Advanced TDMA Mobile Access System for UMTS.
IEEE Personal Communicatons Magazine, vol 2, no 1 edition, February 1995.
[VSB+97] J. De Vriendt, A. Saidi, E. Berruto, T. Norp, and M. Peters. Generic UMTS Architecture and
demonstrator. August 1997.
[WM85] P.T. Ward and S.J. Mellor. Structured Development for Real Time Systems. Yourdon Press,
1985.
[ZBGN97] D. Zeller, M. Barry, A. Gammelgaard, and J. Nelson. Rainbow Demonstrator Transport
Chain. Protocols to implement the UMTS Signalling Network Layer for COBUCO and
RAINBOW, Aalborg, October 1997.
158
Appendix A
Intelligent Networks
The key principle of Intelligent Networks is the separation of the software that controls basic switching
functionality, such as setting up switch parts, from the software that controls call progression. This allows
more advanced features to be rapidly introduced [Abe95].
IN Conceptual model
The IN Conceptual Model (INCM) is a framework for the design and description of the IN architecture
[Gra97]. The INCM [IT92b] is composed of four planes, each plane representing a different abstract view
of the capabilities provided by an IN and are as follows: the Service Plane (SP), the Global Functional
Plane (GFP) the Distributed Functional Plane (DFP) and the Physical Plane (PP).
SF 1
SF 2
FE Y
FEA C1 FEA
FEA FEA
FEAFEA
FE Z
SIB-BCP
NetworkSIB A
PE 1 PE 2
FE X
FE Y
SP
GFP
DFP
PP
FE Z
SF 1
SF 2
SF 1
Service 1
Service 2
FEA
INAP
SIB BSIB C
Figure A.1: IN Conceptual Model
159
Service Plane(SP) Service Plane : In this plane each service is separately described from the end user
viewpoint by a set of generic blocks called service features [IT92c]. These service features are not specific
to any one service and thus can be re-used in the different services. Thus service features are identified by
determining the overlap between services, perceived by the user. The service plane represents an exclusively
user oriented view of the service, and does not contain any information on the possible implementations of
the service in the network.
Global Functional Plane(GFP) This plane still models the network as a single entity, but the service
and service features identified in the previous plane are decomposed into the broad network functions re-
quired to support them [IT92d]. As these functions are not dependent on any individual services or service
features they are referred to as Service Independent Building blocks (SIBs). .A service feature is described
in the GFP as a chain of SIBs. The logic linking the SIBs together is known as the Global Service Logic
(GSL). The essential SIB in the GFP is the Basic Call Process (BCP) which is used to launch IN services.
Distributed Functional Plane (DFP) The Distributed Functional Plane (DFP) [IT93b] describes the
functional architecture of an IN-structured network in terms of units of network functionality, referred to as
”functional entities” and the information that flows between functional entities, referred to as ”relationships”
[Mor95]. This plane expands the modelling results of the previous plane to take a distributed view of the
network into account. This expansion is based on the Stage 2 methodology described in recommendation
[IT97b]. Each SIB identified in the Global Functional Plane should map onto at least one Functional Entity
(FE) in the Distributed Functional Plane. Each SIB in the GFP is realised by a number of Functional Entity
Actions (FEAs) which are performed by FEs. If these FEAs are not all contained in a single FE, information
flows are needed between FEs
SRFSCF
SDF
SCF
SDFSMF
SMAF
SCEF
SSF
CCAF CCF CCAFCCF
IN
Non-IN
ServiceManagement
CCF
SSF
Figure A.2: Distributed Functional Plane
The Functional Entities (FE)s in the DFP and the relationships between them are shown in Figure 2.2.
The CCF and CCAF represent entities in the underlying network (non-IN). IN entities are represented by
160
the SCF, SDF, SSF and SRF . The SMF, SMAF and SCEF represent the IN service management entities.
• Call Control Agent Function (CCAF) Provides user access to the network and represents the at-
tachment of the user’s terminal equipment to the network.
• Call Control Function (CCF) Represents the underlying network (POTS , ISDN , B-ISDN) and
contains call and connection handling for basic switching and bridging as well as triggers or hooks
for invocation of IN service logic.
• Service Switching Function (SSF) Enables interaction between the SCF and the CCF; and modifies
call/connection processing as required by IN service logic.
• Specialised Resource Function (SRF) Provides specialised resources required for the execution of
IN services. It may also contain logic to send, receive and translate user information.
• Service Control Function (SCF) Contains the logic and processing capability for handling IN ser-
vices. It may interact with other SCFs if necessary to perform a service.
• Service Data Function (SDF) Contains the customer and network data for real-time access by the
SCF in the execution of an IN service. It may interact with other SDFs if necessary to perform a
service.
• Service Management Function (SMF) Provides for the service management, service provision and
service deployment control. It also provides an interface for network and service providers.
• Service Management Agent Function(SMAF) Provides an interface to the SMF from which service
providers and subscribers can administer their service.
• Service Creation Environment Function(SCEF) Allows IN services to be defined, developed,
tested and imputed to the SMF.
There is a bearer control and call control relationship between the CCAF, CCF and SRF. Bearer con-
trol refers to allocation and de-allocation of the bearer resources on which user data is sent between the
nodes. Call control is used to control the manipulation of bearer resources. This includes the establishment,
modification and release of bearer associated with a call.
The SCF contains the logic for executing a service, whereas the SSF, SDF and SRF contain the resources
which the SCF uses in executing a service. There is a service control relationship between the SCF and SSF,
SRF and SDF. Service control refers to the relationship between the different IN entities used to invoke or
perform a particular service.
There is a management relationship between the SMF and the SCEF, SMAF, SSF, SCF, SDF and SRF.
This enables a centralised management function to manage the different FEs.
Physical Plane (PP)
161
The physical distribution of the FEs in the DFP is realised in the Physical Plane (PP). The model
identifies the different physical entities and protocols that may exist in real IN-structured networks [IT92b].
Where two FEs are located in two different PEs a protocol is needed for communication between them. FEs
are the lowest level of distribution i.e. an FE may not be split between two or more PEs. For IN the protocol
used for communication between IN entities is the Intelligent Network Application Protocol (INAP). A
typical IN physical plane is illustrated in and contains the following entities [IT93c]
• Service Control Point (SCP) The SCP contains the Service Logic Programs (SLPs) necessary to
provide IN services, and may optionally contain customer data. It contains the SCF and optionally
the SDF.
• Service Switching Point (SSP) In addition to providing the user access to the network (if the SSP
is a local exchange) and performing any necessary switching functionality, the SSP allows access to
the set of IN capabilities [IT93c]. The SSP contains the SSF and CCF. The SSP may also contain the
SRF, SDF, SCF and CCAF if a local exchange.
• Service Data Point (SDP) The SDP contains the data used by the SLPs to provide individualised
services. Functionally the SDP contains the SDF.
• Service Node (SN) The SN can control IN services and engage in flexible information interactions
with users. It contains the SSF, CCF, SCF, SRF, and SDF.
• Intelligent Peripheral (IP) Provides special resources for customisation of services, and supports
flexible information interaction between a user and the network. Contains the SRF and may optionally
contain an SSF and CCF.
• Service Management Point (SMP) The SMP performs service management control, service provi-
sion control and service deployment control. The SMP has access to all other Physical Entities in the
Physical Plane.
162
SSF
CCF
Core
SRF
SCFSDF
CCAF
Optional
SSP
SCF
Core
SDF
Optional
SCP
SDF
Core
SDP
SRF
Core
SSF
Optional
IP
CCF
SSF
CCF
Core
SRF
SCF
SDF
SN
SMAF
Core
SMF
Optional
SMP
SCEF
Figure A.3: Physical Plane
163
164
Appendix B
Specification and Design Language
(SDL)
The Mobile Terminal has been described using the ITU standardised Specification and Description Lan-
guage (SDL) [IT92a]. SDL describes a system as a set of extended finite state machines, which run inde-
pendently of each other in an asynchronous manner [Tur93]. Communication between state machines is via
discrete signals [SSR89]. SDL consists of four components:
• A structural view consisting of a system, block, process and procedure hierarchy.
• The associated data, which consists of predefined data types and mechanisms to define Abstract Data
Types(ADTs)
• Communication via signals with optional signal parameters.
• Behaviour represented by processes.
The latest version of SDL, SDL’92 is object based, and supports object oriented features such as inher-
itance and data abstraction. This provides a greater degree of flexibility in the specification and description
of systems. Each element in the SDL structural view can now be modelled using types, each having a
different set of characteristics [RSO+94]
• System Type To describe a distributed system a SDL system diagram is used. A system can inherit
another system type, but there is only one instance of a system type in an SDL system diagram.
All behaviour in the distributed system occurs within an SDL system diagram and a system type is
composed of block types and a system instance is composed of block instances.
• Block Type A block is a means of encapsulating processes. A block is used for specification of
physically separate entities. Blocks can also be used to group processes according to functionality.
165
• Process Type A process type is a template for a process instance. Unlike system and block instances,
a process instance in SDL is a dynamic entity and can be viewed similar to a process or thread in
UNIX. A process instance has the ability to spawn a process instance of the same or a different
type. The behaviour of an SDL system instance as a whole is described using process instances.
Each process has an activity structure and the activity of the system is the activity structure of the
processes in the system [Gra97].
• Procedure A procedure is a parameterised type and is executed within a process. A procedure in
SDL has synchronous operation similar to a function in ”C”. A procedure can be defined globally
and used locally (global procedures). When a procedure is called in SDL the state machine the
particular process in which it is executing, halts until the procedure returns. A sequence of actions
within a process can therefore be described using procedures. Procedures normally execute within
the calling process. SDL also supports Remote Procedure Calls (RPC), where a process can call a
procedure residing in another process, the procedure executes in a different process than the one from
which it was called.
• Communication There is no global data in SDL, all data is contained within processes. Information
is therefore accessed and modified within the process. Information is shared in the system through the
use of signals, which are transferred between process using signal routes and between blocks using
channels.
166
Appendix C
SDL Description of the MT
167
C-1
Block Type Mobile_Terminal Version(7)
/* Title : SDL system for the 3rd Generation MT
Authors : Gary Fleming,Amre El Hioydi,Liam Gray,Michael Barry,Laurent Von Alment,Flavio Piolini
Version 3.0
Date : 30/03/1998*/
168
C-2
Block Type Mobile_Terminal Definitions_Page(7)
SYNTYPE BufferDepthType = INTEGER ENDSYNTYPE;SYNTYPE BufferSizeType = INTEGER ENDSYNTYPE;
/* The BearerRecord type is used to maintain all the information on the current bearer. It is intended mainly to assist debugging */
NewType TCH_RecordType Struct RELL_SAPid RELLSAPidTypeC; TCH_Type TCH_Type; TCH_Active BOOLEAN; TCH_id TCHIdTypeC;EndNewType TCH_RecordType;
NewType BearerRecordType StructNewService UServiceTypeC;BearerReference UBearerReferenceTypeC;Multibearer BOOLEAN; /* Indicates if this is a multibearer */MB_TCH_Type ChannelDescriptorTypeC; /* Indicates the TCH type */RAL_SAPidRALSAPidTypeC; /* The RAL SAP to be used for the bearer */BufferDepthBufferDepthTypeC; /* The Depth (in terms of RAL frames) of the Buffer in the RAL */BufferSizeBufferSizeTypeC; /* The overal size of the buffer in the RAL */TCH_Record_1 TCH_RecordType; /* A record describing the TCH, or first TCH in multibearer */TCH_Record_2 TCH_RecordType; /* A record describing the second TCH in a multibearer */EndNewType BearerRecordType;
/* This page defines any remote procedures used in the MT */
REMOTE PROCEDURE Store_TMTI; FPAR IN TMTITypeC;
REMOTE PROCEDURE Store_IMUI; FPAR IN IMUITypeC;
REMOTE PROCEDURE Store_LAI; FPAR IN LAITypeC;
REMOTE PROCEDURE Store_DI; FPAR IN DomainIdentifierTypeC;
REMOTE PROCEDURE Store_SI; FPAR IN IMUITypeC, IN SITypeC;
REMOTE PROCEDURE Store_Home_Domain; FPAR IN IMUITypeC, IN DomainIdentifierTypeC;
REMOTE PROCEDURE Get_TMTI; FPAR IN/OUT TMTITypeC;
REMOTE PROCEDURE Get_IMUI; FPAR IN/OUT IMUITypeC;
REMOTE PROCEDURE Get_DI; FPAR IN/OUT DomainIdentifierTypeC;
REMOTE PROCEDURE Get_LAI; FPAR IN/OUT LAITypeC;
REMOTE PROCEDURE Get_SI; FPAR IN IMUITypeC, IN/OUT SITypeC;
REMOTE PROCEDURE Get_Home_Domain; FPAR IN IMUITypeC, IN/OUT DomainIdentifierTypeC;
Remote Procedure FDLInit; Fpar in/out Integer, in/out Integer, in/out FreeDialogIdListType, in/out IDTypeC;
169
C-3
Block Type Mobile_Terminal MT_Signals_Page_1(7)
/* Messages Exchanged between the RC and the RBC */
SIGNAL RBC_Setup_Req(UBearerReferenceTypeC,UServiceTypeC, BTSidTypeC, ChannelDescriptorTypeC);SIGNAL RBC_Setup_Resp(StatusTypeC, RALSAPidTypeC);
SIGNAL RBC_Release_Req(RALSAPidTypeC);SIGNAL RBC_Release_Resp(StatusTypeC);
SIGNAL RBC_Failure_Inf(RALSAPidTypeC);
SIGNAL Add_Req(RALSAPidTypeC,BtsidTypeC, RadioResInfoTypeC, TimingInfoTypeC);SIGNAL Add_Resp(StatusTypeC);
SIGNAL Drop_Req(RALSAPidTypeC,BtsidTypeC,TimingInfoTypeC);SIGNAL Drop_Resp(StatusTypeC);
/* Messages Exchanged between the SBC and the RBC */
SIGNAL Activate_req(RALSAPidTypeC);SIGNAL Activate_resp(StatusTypeC);
SIGNAL Deactivate_req(RALSAPidTypeC);SIGNAL Deactivate_resp(StatusTypeC);
/* Messages exchanged between the UCCA and the TCCU */
SIGNAL Select_BTS_req;SIGNAL Select_BTS_resp(BTSidTypeC, StatusTypeC);
/* Messages exchanged between the LC and RELL */
SIGNAL Channel_setup_req(ChnTypeC,BTSidTypeC);SIGNAL Channel_setup_cnf(ChnTypeC);
SIGNAL Channel_close_req(ChnTypeC);SIGNAL Channel_close_cnf(ChnTypeC);
SIGNAL Channel_drop_req(ChnTypeC,BTSidTypeC);SIGNAL Channel_drop_cnf(ChnTypeC);
SIGNAL Channel_Add_req(ChnTypeC,BTSidTypeC);SIGNAL Channel_Add_cnf(ChnTypeC);
SIGNAL Event_report_ind(ChnTypeC, UINT16, BYTE) ;
SIGNAL RACH_data_req(BTSidTypeC,MTidTypeC);SIGNAL AGCH_data_ind(BYTE, UINT16, BTSidTypeC);SIGNAL PCH_data_ind(BYTE,BTSidTypeC, MTidTypeC);
SIGNAL TCH_Link_Failure(RELLSAPidTypeC);
SIGNAL Chn_Associate_req(RELLSAPidTypeC, RELLSAPidTypeC);SIGNAL Chn_DisAssociate_req(RELLSAPidTypeC);
SIGNAL Chn_Associate_cnf(RELLSAPidTypeC);SIGNAL Chn_DisAssociate_cnf(RELLSAPidTypeC) ;
/* Signals exchanged between the UCCA and the SAL */
SIGNAL Sal_Setup_Req(UCallReferenceTypeC, salSapIdTypeC, malSapIdTypeC, UServiceTypeC, CellRateTypeC, UCodingTypeC);SIGNAL Sal_Setup_Resp(UCallReferenceTypeC, StatusTypeC);SIGNAL Sal_Release_Req(UCallReferenceTypeC, salSapIdTypeC);SIGNAL Sal_Release_Resp(UCallReferenceTypeC, StatusTypeC);
170
C-4
Block Type Mobile_Terminal MT_Signal_List_Page_1(7)
SIGNALLIST RC_to_RBC =RBC_Setup_Req,RBC_Release_Req,Add_Req,Drop_Req;
SIGNALLIST RBC_to_RC =RBC_Setup_Resp,RBC_Release_Resp, RBC_Failure_Inf,Add_Resp,Drop_Resp;
SIGNALLIST SBC_to_RBC =Activate_req,Deactivate_req;
SIGNALLIST RBC_to_SBC =Activate_resp,Deactivate_resp;
SIGNALLIST UCCA_to_TCCU = Select_BTS_req;
SIGNALLIST TCCU_to_UCCA =Select_BTS_resp;
SIGNALLIST LC_to_RELL = Channel_setup_req, Channel_close_req, Channel_add_req, Channel_drop_req, Chn_Associate_req, Chn_Disassociate_req, RACH_data_req;
SIGNALLIST RELL_to_LC = Channel_setup_cnf, Channel_close_cnf, Channel_add_cnf, Channel_drop_cnf, Chn_Associate_cnf, Chn_Disassociate_cnf, TCH_Link_Failure, Event_report_ind, AGCH_data_ind, PCH_data_ind;
SIGNALLIST SBE_to_TCCU = Select_BTS_Req;SIGNALLIST TCCU_to_SBE = Select_BTS_Resp;
SIGNALLIST SAL_to_UCCA = Sal_Setup_Resp, Sal_Release_Resp ;
SIGNALLIST UCCA_to_SAL = Sal_Setup_Req, Sal_Release_Req ;
/* Signal Lists between the MT and the UMS */
/* 1- Signal Lists between the UCCA and the UCC */
SIGNALLIST UCCA_to_UCC = U_Setup,U_Conn,U_Conn_Ack,U_Release,U_Call_Proc,U_Alert,U_Release_Complete;
SIGNALLIST UCC_to_UCCA = U_Setup,U_Conn,U_Conn_Ack,U_Release,U_Call_Proc,U_Alert,U_Release_Complete;
171
C-5
Block Type Mobile_Terminal Encode_Function(7)
/*#CODE#HEADING#include <rpc/rpc.h>extern bool_t xdr_UmtsMessage();
#BODYSDL_Octet_String encode (msg)UmtsMessage msg;{ static unsigned char * buffer ; SDL_Octet_String out ; XDR xdr ; caddr_t addr ; int n ;
n = xdr_sizeof(xdr_UmtsMessage,&msg);
if(buffer) free (buffer) ; buffer = (unsigned char *) malloc(n*sizeof(unsigned char)) ; out.Bits = buffer ; out.Length = n; out.IsAssigned = (xbool) 1 ; addr =(caddr_t) buffer ; xdrmem_create(&xdr,addr,n,XDR_ENCODE); if(!xdr_UmtsMessage(&xdr,&msg)) { fprintf(stderr,"xdr_message encode failed\n"); } xdr_destroy(&xdr); return(out);}
172
C-6
Block Type Mobile_Terminal MT_FE_Types_Page_1(7)
Call_Control_Group
Bearer_Control_Group
Mobility_Management_Group
Transport_Group
HandOver_Group
User
(AppCntrlOut),(UCCACntrlOut)
(AppCntrlIn),(UCCACntrlIn)
Peer_UMS
(UCCA_to_UCC)(UCC_to_UCCA)
Tr
(MBFCntrlOut),(SARFCntrlOut),(RALSigOut),(RELLCntrlOut),(SNLCntrlOut),(SNLSigOut),(SALCntrlOut),(MALCntrlOut)
(MBFCntrlIn),(SARFCntrlIn),(RALSigIn),(RELLCntrlIn),(SNLCntrlIn),(SNLSigUCCAIn),(SNLSigSCIn),(SNLSigIn),(MEFCntrlIn),(LocCntrlIn),(TCCUCntrlIn),(SALCntrlIn),(MALCntrlIn)
Dummy_User
(RHT2User_List),(UCCA_to_User)
(User2RHT_List),(User_to_UCCA)
Peer_BTS
(MT_RBC_to_BTS_RBC),(MT_RTE_to_BTS_RTE),(SBE_to_SBE)
(BTS_RBC_to_MT_RBC),(BTS_RTE_to_MT_RTE),(SBE_to_SBE)
Peer_HO
(HID2HIDn_L),(HOCA2HOC_L)
(HIDn2HID_L),(HOC2HOCA_L)
Peer_MM
(RHT2RH_List),(AHM2AHN_List),(LMT2LUH_List),(AHT2AHV_List)
(RH2RHT_List),(AHN2AHM_List),(LUH2LMT_List),(AHV2AHT_List)
173
C-7
Block Type Mobile_Terminal
HO_FEs : Handover_Group
CC_FEs : Call_Control_Group
BC_FEs : Bearer_Control_Group
Tr_Entities : Transport_Group
Peer_UMSTr
MEF2HO
(LocCntrlIn),(TCCUCntrlIn)
MEF
(HIDn2HID_L)Peer_HID
UCCA2TCCU
Select_BTS_resp
Select_BTS_reqUCCA
HO_Group
UCCA2UCC
(UCCA_to_UCC)
(UCC_to_UCCA)
Peer_UMS
UCCA2DummyApp
(UCCA_to_User)
(User_to_UCCA)
Dummy_UserDummy_User
RC2HO
(RC2HOCA_L),(RC2HID_L)
(HOCA2RC_L),(HID2RC_L)
HO_Group
RC
CC2Tr
(SNLSigOut),(SALCntrlOut),(MALCntrlOut)
(SNLSigUCCAIn),(SALCntrlIn),(MALCntrlIn)
Tr_GroupTr
UCCA2App
(UCCACntrlOut)
(UCCACntrlIn)
User
User
CC2BC
(SBC_to_RBC),(RC_to_RBC)
(RBC_to_SBC),(RBC_to_RC)
BC_Group
CC_Group
BC2HO
(RBC_to_SC),Select_BTS_req
(SC_to_RBC),Select_BTS_resp
HO_Group
BC_Group
BC2Transport
(RBC_to_RAL),(SBE_to_RAL),(LC_to_RELL),(SBE_to_SNL)
(RAL_to_RBC),(RAL_to_SBE),(RELL_to_LC),(SNL_to_SBE)
Dummy_Tr_Group
BC_Group
(SNLSigIn)
To_Env
DummyMEF2HO
(MEF2HID_L),(MEF2SC_L),(MEF_to_TCCU)
HO_Group
Dummy_MEF
MM_Group
MM_Group
RTE2RTE
(MT_RTE_to_BTS_RTE)
(BTS_RTE_to_MT_RTE)
Peer_BTS
Peer_BTS
MT2BTS
(MT_RBC_to_BTS_RBC),(SBE_to_SBE)
(BTS_RBC_to_MT_RBC),(SBE_to_SBE)
Peer_BTS
Peer_BTS
UCCA2DummyTr
(UCCA_to_SAL),(SBC_to_MAL)
(SAL_to_UCCA),(MAL_to_SBC)
Dummy_Tr_Group
CC_Group
HOCA2Peer
(HOC2HOCA_L)
Peer_HOC
HO2TCAP
(App2TCMan_L)
(TCMan2App_L)
TCAP
HO_Group
(SNLSigSCIn)
SNL
Tr
BC2TR
(MBFCntrlIn),(SARFCntrlIn),(RALSigIn),(RELLCntrlIn),(SNLCntrlIn) (MBFCntrlOut),
(SARFCntrlOut),(RALSigOut),(RELLCntrlOut),(SNLCntrlOut)
Tr_Group
174
C-8
MT_FE_Instance_Page_1(7)
MM_FEs : Mobility_Management_Group
HID2Peer
(HID2HIDn_L)(HIDn2HID_L)
Peer_HO
TCAP2Env
(SNLSigOut)
(SNLSigIn)
Tr
DummyMEF2MM
(MEF2LMT_List)
DummyMEF
MM2Peer
(RHT2RH_List),(AHM2AHN_List),(LMT2LUH_List),(AHT2AHV_List)
(RH2RHT_List),(AHN2AHM_List),(LUH2LMT_List),(AHV2AHT_List)
Peer_MM
Peer_MM
MM2TR
(App2TCMan_L)
(TCMan2App_L)TCAP
MM2User(AppCntrlOut)
(AppCntrlIn)
User
User
DumbUser2RHT(RHT2User_List)
(User2RHT_List)
Dummy_User
Dummy_User
HOCA2Peer
(HOCA2HOC_L)(HOC2HOCA_L)
Peer_HO
HO2SNL
(SNLSigOut)
Tr
TrMEF2MM
(MEFCntrlIn)
MEF
175
176
Appendix D
SDL Description of the MT Mobility
Management Group
177
D-1
Block Type Mobile_Terminal MT_Introduction(7)
/* Title : SDL Framework for Specification, Testing and Impementation of the Mobility Chain in the MT
authors : Michael Barry ( University of Limerick )
Date : 06 August 1997
Version : 2.0
Status :
Ver 1.0 : This Block contains the following SDLs LMT: Location Manager Terminal aHT: access Handler Terminal RHT: Registration Handler Terminal MEF: Measurement and Evaluation Function MSF: Mobile Storage Function
Version 1.1 Incorporated comments from RMC1 Changed StatusType to FlagType Changed ReReg*** to UserReReg*** in MT added initial user and services to MSF in MT
Version 2.0 Added Authentication Handler in the Mobile (AHM)
|--------------------|---------------|-----------|----------------| | Document Version | author | Date | Comments | |--------------------|---------------|-----------|----------------| | Issue 1.0 | M Barry | 22-5-97 | First Draft | |--------------------|---------------|-----------|----------------| | Issue 1.1 | M Barry | 06-06-97 | Second Draft | |--------------------|---------------|-----------|----------------| | Issue 2.0 | M Barry | 06-08-97 | New Version | |--------------------|---------------|-----------|----------------|*/
178
D-2
Block Type Mobile_Terminal Type_Definitions(7)
/* This page defines the typs used in the Mobile Terminal */
179
D-3
Block Type Mobile_Terminal Signal_Definitions(7)
/* This page defines all the MT level signals */
/* MEF-LMT Signals */
SIGNaL Loc_Meas_Ind (LAIType, DIType);
/* LMT-aHT Signals */
SIGNaL DomainUpdateReq (LAIType, DIType, DIType), DomainUpdateResp (TMTIType, FlagType);
/* LMT-RHT Signals */
SIGNaL UserReRegReq (TMTIType, TMTIType, DIType, DIType), UserReRegResp (FlagType);
180
D-4
Block Type Mobile_Terminal Signalllist_Definitions(7)
/* This page defines all the signallists used in the MT */
/* RHT-User Lists*/
SIGNaLLIST User2RHT_List = UserRegReq, UserDeRegReq;SIGNaLLIST RHT2User_List = UserRegResp, UserDeRegResp;
/* ENV-MEF Lists */
SIGNaLLIST ENV2MEF_List = Measurement_rep_ind;
/* LMT-LUH Lists */
SIGNaLLIST LMT2LUH_List = LocationUpdateReq;SIGNaLLIST LUH2LMT_List = LocationUpdateResp;
/* aHT-aHV Lists */
SIGNaLLIST aHT2aHV_List = accessReq;SIGNaLLIST aHV2aHT_List = accessResp;
/* RHT-RH Lists */
SIGNaLLIST RHT2RH_List = RegistrationReq, DeRegistrationReq, ReRegistrationReq;SIGNaLLIST RH2RHT_List = RegistrationResp, DeRegistrationResp, ReRegistrationResp;
/* AHM-AHN Lists */
SIGNALLIST AHM2AHN_List = UserAuthenticationResp, TerminalAuthenticationResp;SIGNALLIST AHN2AHM_List = UserAuthenticationReq, TerminalAuthenticationReq;
/* LMT-aHT Lists */
SIGNaLLIST LMT2aHT_List = DomainUpdateReq;SIGNaLLIST aHT2LMT_List = DomainUpdateResp;
/* LMT-RHT Lists */
SIGNaLLIST LMT2RHT_List = UserReRegReq;SIGNaLLIST RHT2LMT_List = UserReRegResp;
/* MEF-LMT Signallist */
SIGNaLLIST MEF2LMT_List = Loc_Meas_Ind;
181
D-5
Block Type Mobile_Terminal Procedure_Definitions(7)
/* This page defines any remote procedures used in the MT */
REMOTE PROCEDURE Store_TMTI; FPAR IN TMTIType;
REMOTE PROCEDURE Store_IMUI; FPAR IN IMUIType;
REMOTE PROCEDURE Store_LAI; FPAR IN LAIType;
REMOTE PROCEDURE Store_DI; FPAR IN DIType;
REMOTE PROCEDURE Store_SI; FPAR IN IMUIType, IN SIType;
REMOTE PROCEDURE Store_Home_Domain; FPAR IN IMUIType, IN DIType;
REMOTE PROCEDURE Get_TMTI; FPAR IN/OUT TMTIType;
REMOTE PROCEDURE Get_IMUI; FPAR IN/OUT IMUIType;
REMOTE PROCEDURE Get_DI; FPAR IN/OUT DIType;
REMOTE PROCEDURE Get_SI; FPAR IN IMUIType, IN/OUT SIType;
REMOTE PROCEDURE Get_Home_Domain; FPAR IN IMUIType, IN/OUT DIType;
182
D-6
Block Type Mobile_Terminal Block_Definitions(7)
/* This page defines the Block Types to be used in the MT */
LMTBlockType AHTBlockType
RHTBlockType MSFBlockType
MEFBlockType AHMBlockType
MT2ENV_Gate
(ENV2MT_List)
MT2MSCP_Gate(MT2MSCP_List)
(MSCP2MT_List)
MT2User_Gate(MT2User_List)
(User2MT_List)
183
D-7
Block Type Mobile_Terminal Block_Interaction(7)
/* This is the MT-level Block Interaction Page */
MEF:MEFBLockType
LMT:LMTBlockType
MSF:MSFBlockType
RHT:RHTBlockType
AHT:AHTBlockType
AHM:AHMBlockType
MT2User_Gate
MT2MSCP_Gate
MT2MSCP_Gate
MT2MSCP_Gate
MT2ENV_Gate MEF_ENV
(ENV2MEF_List)
MEF2ENV_Gate
MEF_LMT (MEF2LMT_List)
MEF2LMT_Gate
LMT2MEF_Gate
LMT_LUH (LMT2LUH_List)
(LUH2LMT_List)LMT2LUH_Gate
MT2MSCP_Gate
RHT_User(RHT2User_List)
(User2RHT_List)RHT2User_Gate
RHT_RH (RHT2RH_List)
(RH2RHT_List)RHT2RH_Gate
RHT_LMT
(RHT2LMT_List)
(LMT2RHT_List)
RHT2LMT_Gate
LMT2RHT_Gate
aHT_aHV (aHT2aHV_List)
(aHV2aHT_List)
aHT2aHV_Gate
LMT_aHT(aHT2LMT_List)
(LMT2aHT_List)
aHT2LMT_Gate
LMT2aHT_Gate
AHM_AHN (AHM2AHN_List)
(AHN2AHM_List)
AHM2AHN_Gate
184
D-8
Block Type LMTBlockType Introduction(3)
/*
Title : SDLs for the LMT
author: Michael Barry (University of Limerick)
Date: 26 / 05 / 97
Version: 3.1
Comment : Previous Versions of the process were released to RaP1 and RMC1 in L_066_XX and L_078_XX
The usage and duration of timers has yet to be finalised History.
Version 3.1 Incorporated comments from RMC1 Changed StatusType to FlagType Changed ReReg*** to UserReReg*** in MT added initial user and services to MSF in MT
|--------------------|---------------|-----------|----------------| | Document Version | author | Date | Comments | |--------------------|---------------|-----------|----------------| | Issue 3.0 | M Barry | 27-5-97 | Draft | |--------------------|---------------|-----------|----------------| | Issue 3.1 | M Barry | 09-06-97 | Draft | |--------------------|---------------|-----------|----------------| */
185
D-9
Block Type LMTBlockType LMTBlock_def(3)
/* This page describes theGates and Process Types needed in the LMT Block*/
LMTProcType
LMT2RHT_Gate
(LMT2RHT_List)
(RHT2LMT_List)
LMT2AHT_Gate
(LMT2AHT_List)
(AHT2LMT_List)
LMT2LUH_Gate
(LMT2LUH_List)
(LUH2LMT_List)
LMT2MEF_Gate
(MEF2LMT_List)
186
D-10
Block Type LMTBlockType Process_Interaction_Page(3)
LMT(1,1):LMTProcType
LMT2MEF_Gate MEF
(MEF2LMT_List)
MEF_Gate
RHT
(LMT2RHT_List)(RHT2LMT_List)
RHT_Gate
LMT2RHT_Gate
AHT
(LMT2AHT_List)(AHT2LMT_List)
AHT_Gate
LMT2AHT_GateLMT2LUH_Gate LUH
(LUH2LMT_List)(LMT2LUH_List)
LUH_Gate
187
D-11
Process Type LMTProcType LMT_Proc(7)
IMPORTED PROCEDURE Store_TMTI; FPAR TMTIType;
IMPORTED PROCEDURE Store_DI; FPAR DIType;
IMPORTED PROCEDURE Store_LAI; FPAR LAIType;
IMPORTED PROCEDURE Get_IMUI; FPAR IN/OUT IMUIType;
DCL TMTI TMTIType, TMTIn TMTIType;
DCL LAI LAIType, LAIn LAIType;
DCL DI DIType, DIn DIType;
DCL IMUI IMUIType;
DCL Status FlagType;
RHT_Gate
(LMT2RHT_List)
(RHT2LMT_List)
AHT_Gate
(LMT2AHT_List)
(AHT2LMT_List)
LUH_Gate
(LMT2LUH_List)
(LUH2LMT_List)
MEF_Gate
(MEF2LMT_List)
188
D-12
Process Type LMTProcType LMT_Startup(7)
Setup the LAI, DI, TMTI with some desfult values
TMTI :=TMTI_1
DI :=DI_1
LAI :=LAI_1
LMT_IDLE
189
D-13
Process Type LMTProcType LMT_IDLE_1(7)
LMT_IDLE
Loc_Meas_Ind(LAIn, DIn)
DIn =DI
LAIn= LAI
LMT_IDLELocationUpdateReq(TMTI, LAIn)VIa LUH_Gate
LMT_Wait_LU
DomainUpdateReq(LAI, DI, DIn)VIa AHT_Gate
LMT_Wait_Access
(TRUE)
(TRUE)(FaLSE)
(FaLSE)
190
D-14
Process Type LMTProcType LMT_Wait_LU(7)
LMT_Wait_LU
LocationUpdateResp(TMTIn, Status)
Status
Update_TMTI(TMTIn)
Update_LAI(LAIn)
LMT_IDLE
LMT_IDLE
(TRUE)(FaLSE)
191
D-15
Process Type LMTProcType LMT_Wait_Access(7)
LMT_Wait_Access
DomainUpdateResp(TMTIn, Status)
Status
Get_IMUI(IMUI)
IMUI =NULL_IMUI
Update_DI(DIn)
Update_LAI(LAIn)
Update_TMTI(TMTIn)
LMT_IDLE
UserReRegReq(TMTI, TMTIn, DI, DIn)VIa RHT_Gate
LMT_Wait_UserReReg
LMT_IDLE
(TRUE)
(TRUE)
(FaLSE)
(FaLSE)
192
D-16
Process Type LMTProcType LMT_Wait_ReReg(7)
LMT_Wait_UserReReg
UserReRegResp(Status)
Status
Update_DI(DIn)
Update_LAI(LAIn)
Update_TMTI(TMTIn)
LMT_IDLE
LMT_IDLE
(TRUE)(FaLSE)
193
D-17
Process Type LMTProcType LMT_Procedures(7)
Update_DI Update_LAI
Update_TMTI
194
D-18
; FPAR IN nDI DIType;
Procedure Update_DI Update_DI(1)
DI :=nDI
Store_DI(DI)
195
D-19
; FPAR IN nLAI LAIType;
Procedure Update_LAI Update_LAI(1)
LAI :=nLAI
Store_LAI(LAI)
196
D-20
; FPAR IN nTMTI TMTIType;
Procedure Update_TMTI Update_TMTI(1)
TMTI :=nTMTI
Store_TMTI(TMTI)
197
D-21
Block Type AHTBlockType Introduction(3)
/*
Title : SDLs for the AHT
author: Michael Barry (University of Limerick)
Date: 26 / 05 / 97
Version: 3.1
Comment : Previous Versions of the process were released to RaP1 and RMC1 in L_066_XX and L_078_XX
The usage and duration of timers has yet to be finalised History.
Version 3.1 Incorporated comments from RMC1 Changed StatusType to FlagType Changed ReReg*** to UserReReg*** in MT added initial user and services to MSF in MT
|--------------------|---------------|-----------|----------------| | Document Version | author | Date | Comments | |--------------------|---------------|-----------|----------------| | Issue 3.0 | M Barry | 22-5-97 | Draft | |--------------------|---------------|-----------|----------------| | Issue 3.1 | M Barry | 06-06-97 | Draft | |--------------------|---------------|-----------|----------------|
*/
198
D-22
Block Type AHTBlockType AHTBlock_def(3)
/* This page describes theGates and Process Typoes needed in the AHT Block*/
AHTProcType
AHT2aHV_Gate
(AHT2aHV_List)
(aHV2AHT_List)
AHT2LMT_Gate
(AHT2LMT_List)
(LMT2AHT_List)
199
D-23
Block Type AHTBlockType Process_Interaction_Page(3)
AHT(1,1):AHTProcType
AHT2aHV_Gate
aHV
(aHV2AHT_List)
(AHT2aHV_List)
aHV_Gate
LMT (AHT2LMT_List)
(LMT2AHT_List)LMT_Gate
AHT2LMT_Gate
200
D-24
Process Type AHTProcType AHT_Proc(4)
DCL DIo DIType, DIn DIType, DIh DIType;
DCL IMUI IMUIType;
DCL TMTI TMTIType, TMTIn TMTIType;
DCL LAI LAIType;
DCL Status FlagType;
IMPORTED PROCEDURE Get_TMTI; FPAR IN/OUT TMTIType;
IMPORTED PROCEDURE Get_IMUI; FPAR IN/OUT IMUIType;
IMPORTED PROCEDURE Get_Home_Domain; FPAR IN IMUIType, IN/OUT DIType;
aHV_Gate
(AHT2aHV_List)
(aHV2AHT_List)
LMT_Gate
(AHT2LMT_List)
(LMT2AHT_List)
201
D-25
Process Type AHTProcType AHT_Startup(4)
IDLE
202
D-26
Process Type AHTProcType AHT_IDLE(4)
IDLE
DomainUpdateReq(LAI, DIo, DIn)
Get_TMTI(TMTI)
AccessReq(TMTI, LAI, DIo)VIa aHV_Gate
Wait_AccessResp
203
D-27
Process Type AHTProcType WaitAccessResp(4)
Wait_AccessResp
AccessResp(TMTIn, status)
DomainUpdateResp(TMTIn, Status)VIa LMT_Gate
IDLE
204
D-28
Block Type RHTBlockType Introduction(3)
/*
Title : SDLs for the RHT
Author: Michael Barry (University of Limerick)
Date: 26 / 05 / 97
Version: 3.1
Comment : Previous Versions of the process were released to RAP1 and RMC1 in L_066_XX and L_078_XX
The usage and duration of timers has yet to be finalised History.
Version 3.1 Incorporated comments from RMC1 Changed StatusType to FlagType Changed ReReg*** to UserReReg*** in MT added initial user and services to MSF in MT
|--------------------|---------------|-----------|----------------| | Document Version | author | Date | Comments | |--------------------|---------------|-----------|----------------| | Issue 3.0 | M Barry | 22-5-97 | Draft | |--------------------|---------------|-----------|----------------| | Issue 3.1 | M Barry | 06-06-97 | Draft | |--------------------|---------------|-----------|----------------| */
205
D-29
Block Type RHTBlockType RHTBlock_def(3)
/* This page describes theGates and Process Typoes needed in the RHT Block*/
RHTProcType
RHT2LMT_Gate
(RHT2LMT_List)
(LMT2RHT_List)
RHT2RH_Gate
(RHT2RH_List)
(RH2RHT_List)
RHT2User_Gate
(RHT2User_List)
(User2RHT_List)
206
D-30
Block Type RHTBlockType Process_Interaction_Page(3)
RHT(1,1):RHTProcType
RHT2User_Gate
User
(User2RHT_List)
(RHT2User_List)User_Gate
LMT (RHT2LMT_List)
(LMT2RHT_List)
LMT_Gate
RHT2LMT_Gate
RHT2RH_Gate RH
(RH2RHT_List)(RHT2RH_List)
RH_Gate
207
D-31
Process Type RHTProcType RHT_Proc(9)IMPORTED PROCEDURE Get_TMTI; FPAR IN/OUT TMTIType;
IMPORTED PROCEDURE Get_IMUI; FPAR IN/OUT IMUIType;
IMPORTED PROCEDURE Get_Home_Domain; FPAR IN IMUIType, IN/OUT DIType;
DCL IMUI IMUIType;
DCL TMTI TMTIType, TMTIo TMTIType, TMTIn TMTIType;
DCL SI SIType;
DCL DI DIType, DIh DIType, DIo DIType, DIn DIType;
DCL TrafficDescriptor TrafficDescriptorType;
DCL Status FlagType;
IMPORTED PROCEDURE Get_TMTI; FPAR IN/OUT TMTIType;
IMPORTED PROCEDURE Get_DI; FPAR IN/OUT DIType;
IMPORTED PROCEDURE Store_IMUI; FPAR IN IMUIType;
IMPORTED PROCEDURE Store_Home_Domain; FPAR IN IMUIType, IN DIType;
IMPORTED PROCEDURE Get_Home_Domain; FPAR IN IMUIType, IN/OUT DIType;
IMPORTED PROCEDURE Store_SI; FPAR IN IMUIType, IN SIType;
IMPORTED PROCEDURE Get_SI; FPAR IN IMUIType, IN/OUT SIType;
IMPORTED PROCEDURE Get_IMUI; FPAR IN/OUT IMUIType;
LMT_Gate
(RHT2LMT_List)
(LMT2RHT_List)
RH_Gate
(RHT2RH_List)
(RH2RHT_List)
User_Gate
(RHT2User_List)
(User2RHT_List)
208
D-32
Process Type RHTProcType RHT_Startup(9)
Initialise some variables
IMUI :=IMUI_1
IDLE
209
D-33
Process Type RHTProcType RHT_IDLE_1(9)
IDLE
UserRegReq(IMUI, SI, TrafficDescriptor, DIh)
Check_User_Status(IMUI, Status)
Status
Check_Terminal_Capabilities(SI, Status)
Status
Get_TMTI(TMTI)
RegistrationReq(TMTI, IMUI, SI, TrafficDescriptor, DIh)VIA RH_Gate
Wait_RegistrationResp
UserRegResp(Status)VIA USER_Gate
IDLE
(TRUE)
(TRUE)
(FALSE)
(FALSE)
210
D-34
Process Type RHTProcType RHT_IDLE_2(9)
IDLE
UserDeRegReq(IMUI, SI, TrafficDescriptor, DIh)
Check_User_Status(IMUI, Status)
Status
Get_TMTI(TMTI)
DeRegistrationReq(IMUI, SI, TrafficDescriptor, TMTI, DIh)VIA RH_Gate
Wait_DeRegistrationResp
UserRegResp(Status)VIA USER_Gate
IDLE
(TRUE)
(FALSE)
211
D-35
Process Type RHTProcType RHT_IDLE_3(9)
IDLE
UserReRegReq(TMTIo, TMTIn, DIo, DIn)
Get_IMUI(IMUI)
IMUI =NULL_IMUI
Get_Home_Domain(IMUI, DIh)
ReRegistrationReq(IMUI, TMTIo, TMTIn, DIo, DIh)VIA RH_Gate
Wait_ReRegistrationResp
UserReRegResp(TRUE)
IDLE
If there are no usersregistered then thereis no need for the reregistrationReturn TRUE so the the LMT can update the MSF
(FALSE)
(TRUE)
212
D-36
Process Type RHTProcType RHT_Wait_RegistrationResp(9)
Wait_RegistrationResp
RegistrationResp(Status)
Status
Store_IMUI(IMUI)
Store_SI(IMUI, SI)
Store_Home_Domain(IMUI, DIh)
UserRegResp(Status)VIA User_Gate
IDLE
UserRegResp(Status)VIA User_Gate
IDLE
(TRUE)
(FALSE)
213
D-37
Process Type RHTProcType RHT_Wait_DeregistrationResp(9)
For now assume a User Registers/DeRegisters for all servicesAlso only one user per terminal, so when a user deregisters forall services set the IMUI in the MSF to NULL_IMUI
Wait_DeRegistrationResp
DeRegistrationResp(Status)
Status
Store_SI(IMUI, NULL_SI)
Store_IMUI(NULL_IMUI)
Store_Home_Domain(IMUI, Null_DI)
UserDeRegResp(Status)VIA User_Gate
IDLE
UserDeRegResp(Status)VIA User_Gate
IDLE
(TRUE)(FALSE)
214
D-38
Process Type RHTProcType RHT_Wait_ReRegistrationResp(9)
Wait_ReRegistrationResp
ReRegistrationResp(Status)
UserReRegResp(Status)VIA LMT_Gate
IDLE
215
D-39
Process Type RHTProcType RHT_Procedures(9)
Check_Terminal_Capabilities
Check_User_Status
216
D-40
; FPAR IN SI SIType, IN/OUT Status FlagType;
Procedure Check_Terminal_Capabilities Check_Terminal_Capabilities(1)
Status :=TRUE
217
D-41
; FPAR IN IMUI IMUIType, IN/OUT Status FlagType;
Procedure Check_User_Status Check_User_Status(1)
DCL IMUIo IMUIType;
This procedure checks the status of the user attempting a registration procedureIf the user requesting the procedure is not the current user then the procedure fails
Get_IMUI(IMUIo)
IMUIo =NULL_IMUI
Status :=TRUE
IMUIo =IMUI
Status :=TRUE
Status :=FALSE
(TRUE)
(FALSE)
(TRUE)(FALSE)
218
D-42
Block Type MSFBlockType Introducton(4)
/*
Title : SDLs for the MSF
Author: Michael Barry (University of Limerick)
Date: 26 / 05 / 97
Version: 2.1
Comment : Previous Versions of the process were released to RAP1 and RMC1 in L_066_XX and L_078_XX
This process only maintains data required for the Mobility Management entities in the MT ASSUMPTIONS Only One User per terminal
At the moment this Process assumes that the User registers for all available services, or for none. Extra functionality is needed to support user registration for a range of services
History. Version 2.1 Incorporated comments from RMC1 Changed StatusType to FlagType Changed ReReg*** to UserReReg*** in MT added initial user and services to MSF in MT
|--------------------|---------------|-----------|----------------| | Document Version | author | Date | Comments | |--------------------|---------------|-----------|----------------| | Issue 2.0 | M Barry | 22-5-97 | Draft | |--------------------|---------------|-----------|----------------| | Issue 2.1 | M Barry | 06-06-97 | Draft | |--------------------|---------------|-----------|----------------|
*/
219
D-43
Block Type MSFBlockType Signal_Definitions(4)
SIGNAL Get_MSF_DI, Get_MSF_TMTI, Get_MSF_IMUI, Get_MSF_DIh, Get_MSF_SI,
Put_MSF_DI (DIType), Put_MSF_TMTI (TMTIType), Put_MSF_IMUI (IMUIType), Put_MSF_DIh (DIType), Put_MSF_SI (SIType), Put_MSF_LAI (LAIType), MSF_DI (DIType), MSF_TMTI (TMTIType), MSF_IMUI (IMUIType), MSF_DIh (DIType), MSF_SI (SIType);
SIGNALLIST Store2IF_List = MSF_DI, MSF_TMTI, MSF_IMUI, MSF_DIh, MSF_SI;
SIGNALLIST IF2Store_List = Get_MSF_DI, Get_MSF_TMTI, Get_MSF_IMUI, Get_MSF_DIh, Get_MSF_SI, Put_MSF_DI, Put_MSF_TMTI, Put_MSF_IMUI, Put_MSF_DIh, Put_MSF_SI, Put_MSF_LAI;
220
D-44
Block Type MSFBlockType MSFBlockDef(4)
StorageProcType
IFProcType
221
D-45
Block Type MSFBlockType Process_Interaction(4)
IFProc(1,1):IFProcType
StorageProc(1,1):StorageProcType
Store_IF
(Store2IF_List)
(IF2Store_List)
IF_Gate
Storage_Gate
222
D-46
Process Type StorageProcType Storage(3)
DCL TMTI TMTIType, LAI LAIType, DI DIType, DIh DIType, IMUI IMUIType, SI SIType;
LAI :=LAI_1
DI :=DI_1
TMTI :=TMTI_1
SI :=SI_1
IMUI :=IMUI_1
DIh :=DI_1
IDLE
Initialisation of User and TerminalData in the MSF
IF_Gate(Store2IF_List)
(IF2Store_List)
223
D-47
Process Type StorageProcType Storage_1(3)
IDLE
Get_MSF_DI
MSF_DI(DI)
IDLE
Get_MSF_TMTI
MSF_TMTI(TMTI)
IDLE
Get_MSF_IMUI
MSF_IMUI(IMUI)
IDLE
Get_MSF_DIh
MSF_DIh(DIh)
IDLE
Get_MSF_SI
MSF_SI(SI)
IDLE
224
D-48
Process Type StorageProcType Storage_2(3)
IDLE
Put_MSF_DIh(DIh)
IDLE
Put_MSF_DI(DI)
IDLE
Put_MSF_TMTI(TMTI)
IDLE
Put_MSF_LAI(LAI)
IDLE
Put_MSF_IMUI(IMUI)
IDLE
Put_MSF_SI(SI)
IDLE
225
D-49
Process Type IFProcType IF_Proc(2)
IDLE
*
IDLEIDLE
Storage_GATE
(IF2Store_List)
(Store2IF_List)
226
D-50
Process Type IFProcType Procedures(2)
EXPORTED Get_TMTI
EXPORTED Store_LAI
EXPORTED Get_DI
EXPORTED Store_DI
EXPORTED Get_IMUI
EXPORTED Store_TMTI
EXPORTEDGet_SI
EXPORTED Store_IMUI
EXPORTEDStore_SI EXPORTED
Get_Home_Domain
EXPORTEDStore_Home_Domain
227
D-51
; FPAR IN/OUT TMTI TMTIType;
Procedure Get_TMTI Get_TMTI(1)
Get_MSF_TMTI
Wait_TMTI
MSF_TMTI(TMTI)
228
D-52
; FPAR IN LAI LAIType;
Procedure Store_LAI Store_LAI(1)
Put_MSF_LAI(LAI)
229
D-53
; FPAR IN/OUT DI DIType;
Procedure Get_DI Get_DI(1)
Get_MSF_DI
Wait_DI
MSF_DI(DI)
230
D-54
; FPAR IN DI DIType;
Procedure Store_DI Store_DI(1)
Put_MSF_DI(DI)
231
D-55
; FPAR IN/OUT IMUI IMUIType;
Procedure Get_IMUI Get_IMUI(1)
Get_MSF_IMUI
Wait_IMUI
MSF_IMUI(IMUI)
232
D-56
; FPAR IN TMTI TMTIType;
Procedure Store_TMTI Store_TMTI(1)
Put_MSF_TMTI(TMTI)
233
D-57
; FPAR IN IMUI IMUIType, IN/OUT SI SIType;
Procedure Get_SI Get_SI(1)
Get_MSF_SI
Wait_MSF_SI
MSF_SI(SI)
234
D-58
; FPAR IN IMUI IMUIType;
Procedure Store_IMUI Store_IMUI(1)
Put_MSF_IMUI(IMUI)
235
D-59
; FPAR IN IMUI IMUIType, IN SI SIType;
Procedure Store_SI Store_SI(1)
Put_MSF_SI(SI)
236
D-60
; FPAR IN IMUI IMUIType, IN/OUT DIh DIType;
Procedure Get_Home_Domain Get_Home_Domain(1)
Get_MSF_DIh
Wait_MSF_DIh
MSF_DIh(DIh)
237
D-61
; FPAR IN IMUI IMUIType, IN DIh DIType;
Procedure Store_Home_Domain Store_Home_Domain(1)
Put_MSF_DIh(DIh)
238
D-62
Block Type MEFBlockType AHTBlock_def(2)
/* This process is a stub of the MEF */
MEFProcType
MEF2LMT_Gate
(MEF2LMT_List)
MEF2ENV_Gate
(ENV2MEF_List)
239
D-63
Block Type MEFBlockType Process_Interaction_Page(2)
MEF(1,1):MEFProcType
MEF2LMT_Gate
MEF2ENV_GateENVIRON
(ENV2MEF_List)
ENV_Gate
LMT
(MEF2LMT_List)
LMT_Gate
240
D-64
Process Type MEFProcType Untitled1(1)
DCL DI DIType, LAI LAIType;
IDLE
Measurement_rep_ind(DI, LAI)
Loc_Meas_Ind(LAI, DI)VIA MEF2LMT_Gate
IDLE
LMT_Gate
(MEF2LMT_List)
ENV_Gate
(ENV2MEF_List)
241
D-65
Block Type AHMBlockType AHMBlockType(3)
/*
Title : SDLs for the AHM
author: Michael Barry (University of Limerick)
Date: 06 / 08 / 97
Version: 1.0
|--------------------|---------------|-----------|----------------| | Issue 1.0 | M Barry | 06-08-97 | Draft | |--------------------|---------------|-----------|----------------|
*/
242
D-66
Block Type AHMBlockType AHMBlockDef(3)
AHMProcType
AHM2aHN_Gate
(AHM2aHN_List)
(aHN2AHM_List)
243
D-67
Block Type AHMBlockType Process_Interaction_Page(3)
AHM(1,1):AHMProcType
AHM2AHN_Gate
AHN (AHM2AHN_List)
(AHN2AHM_List)
AHN_Gate
244
D-68
Process Type AHMProcType AHMProcType(4)
DCL IMUI IMUIType;
DCL Question QuestionType;
DCL Answer AnswerType;
aHN_Gate
(AHM2aHN_List)
(aHN2AHM_List)
245
D-69
Process Type AHMProcType AHM_Startup(4)
Answer := 0
IDLE
246
D-70
Process Type AHMProcType UserAuthentication(4)
IDLE
UserAuthenticationReq(IMUI, Question)
UserAuthenticationResp(Answer)VIA AHN_Gate
IDLE
247
D-71
Process Type AHMProcType TerminalAuthentication(4)
IDLE
TerminalAuthenticationReq(Question)
TerminalAuthenticationResp(Answer)VIA AHN_Gate
IDLE
248
Appendix E
SDL Description of the LMT FE
Manager
249
F-2
System LayerManager Intro(4)
This is the Layer Manager Template.
It is intended to as an example to describe the workings and usage of the LayerManager in SDL/SDT.
A detailed description of the purpose of theLayer Manager and its opertions can be found inl_062_xx
This system consists of two simple FEs (RHT, SHT)with the following relationshipsENV <----> RHTRHT <----> SHTSHT <----> NWK (This interaction is not described here)
Also present is the OManager Block which interacts withthe Layer Managers present in the FEs for configurationand monitoring of running processes
This system contains a LayerManagerLib Process Type which contains some of the generic data, procedures and functionality common to all Layer Managers. This ProcessType is inherited by each Layer Manager. In all cases the Layer Manager in each FE needs to be specialised to handle messages, and in some cases data which are local to tha FE
250
F-3
System LayerManager Types(4)
/* Enumerated Types */
/* FE Locations */NEWTYPE Location_Type LITERALS node_internal, node_external;ENDNEWTYPE Location_Type;
/* System Nodes */NEWTYPE Node_Type LITERALS NULL_NODE, MT, BTS, UMS, MSCP;ENDNEWTYPE Node_Type;
/* FE Types */NEWTYPE FE_Type LITERALS NULL_FE, RHT, SHT, ENVIRON;ENDNEWTYPE FE_Type;
/* Structure Types */
/* FE Address */NEWTYPE Address_Type STRUCT Node Node_Type; FE FE_Type;ENDNEWTYPE Address_Type;
/* Process ID and Status */NEWTYPE Proc_Status_Type STRUCT Proc_id PID; Proc_Status BOOLEAN;ENDNEWTYPE Proc_Status_Type;
/* Array Types */
/* List of PIDs with index of type FE_Type */NEWTYPE PID_List_Type ARRAY (FE_Type, PID);ENDNEWTYPE PID_List_Type;
/* CONSTANTS */SYNONYM MAX_FE_INST INTEGER = 4;
SYNTYPE Range_Type = INTEGER constants 0:MAX_FE_INST ENDSYNTYPE;
/* Syntypes */
SYNTYPE SI_Type = INTEGER ENDSYNTYPE;SYNTYPE IMUI_Type = INTEGER ENDSYNTYPE;SYNTYPE TMTI_Type = INTEGER ENDSYNTYPE;SYNTYPE Status_Type = BOOLEAN ENDSYNTYPE;
Types and Sorts used in the system
251
F-4
System LayerManager Signals(4)
/* Messages exchanged between Omanager and Layer Manager*/
SIGNAL LM_Identify (FE_Type), Create_Ind (FE_Type, PID), Delete_Req (PID), Delete_Resp (PID);
/* Signal from Environment to Omanager */SIGNAL OMAN_RESET;
/* Messages exchanged between Layer Managers for binding */
SIGNAL Bind_Req (FE_Type, PID), Bind_Resp (FE_Type, PID, PID), Unbind_Ind (FE_Type, PID, PID);
/* System Messages between ENV, RHT and SHT FEs */SIGNAL User_Reg_Req (PID, PID, IMUI_Type, SI_Type), User_Reg_Resp (PID, PID, Status_Type), User_Registration_Req (PID, PID, IMUI_Type, SI_Type, TMTI_Type), User_Registration_Resp (PID, PID, Status_Type);
/* Signal Lists used at System Level */
SIGNALLIST LM2OM_List = Create_Ind, Delete_Resp, LM_Identify;SIGNALLIST OM2LM_List = Delete_Req;
SIGNALLIST ENV2RHT_List = Bind_Req, User_Reg_Req;SIGNALLIST RHT2ENV_List = Bind_Resp, Unbind_Ind, User_Reg_Resp;
SIGNALLIST RHT2SHT_List = Bind_Req, User_Registration_Req;SIGNALLIST SHT2RHT_List = Bind_Resp, Unbind_Ind, User_Registration_Resp;
SIGNALLIST ENV2OM_List = OMAN_RESET;
Signals visible at block level in the system
252
F-5
System LayerManager Blocks(4)
REMOTE PROCEDURE Find_Location; FPAR IN FE_Type, IN Address_Type, IN/OUT Location_Type;
OManager
LayerManagerLib
SHTBlock_Type RHTBlock_Type
RHT_FE:RHTBlock_Type
SHT_FE:SHTBlock_Type
ENV_OMan
(ENV2OM_List)
RHT_ENV(RHT2ENV_List)
(ENV2RHT_List)
RHT2ENV_Gate
RHT_OM
(LM2OM_List)
(OM2LM_List)RHT2OM_Gate
RHT_SHT
(RHT2SHT_List)
(SHT2RHT_List)
RHT2SHT_Gate
SHT2RHT_Gate
SHT_OM
(LM2OM_List)
(OM2LM_List)
SHT2OM_Gate
253
F-6
Block OManager OManager(1)
/* New Types used in this Block */
/* An Array of PIDs with Max_Inst elements */NEWTYPE Proc_Arr_Type ARRAY (Range_Type, PID);ENDNEWTYPE Proc_Arr_Type;
/* An Array of all Processes Present in each FE in the system */NEWTYPE FE_Proc_Arr_Type ARRAY (FE_Type, Proc_Arr_Type);ENDNEWTYPE FE_Proc_Arr_Type;
/* An aray of counters for each FE Type in the system */NEWTYPE FE_Count_Arr_Type ARRAY (FE_Type, Range_Type);ENDNEWTYPE FE_Count_Arr_Type;
/* An Array to hold the locaton of each FE in the system */NEWTYPE FE_Location_Arr_Type ARRAY (FE_Type, Location_Type);ENDNEWTYPE FE_Location_Arr_Type;
/* Messages exchanged between the OMan and IF_Proc */
SIGNAL FE_Location_Req (FE_Type, Address_Type),FE_Location_Resp (Location_Type);
SIGNALLIST IF2OM_List = FE_Location_Req;SIGNALLIST OM2IF_List = FE_Location_Resp;
CONNECT RHT_OM, SHT_OM AND OM_LM;CONNECT ENV_OMan AND ENV_OM;
/* IF Proc is the Interface Process. Procedures which are exported to be used by the FEs in the system are located here */
OMan_Proc
IF_Proc
ENV_OM
(ENV2OM_List)
OM_LM(OM2LM_List)
(LM2OM_List)
OM2IF
(IF2OM_List)
(OM2IF_List)
254
F-7
Process OMan_Proc OMan_Proc(5)
/* This process stores and data regarding all Layer Managers and Process present in each FE in the system
It also stores the location of the FEs in the system */
/* Array for the Layer Manager PIDs */DCL Layer_Man_Ids PID_List_Type;
/* Array of all FE Procs in the system */DCL FE_Proc_Ids FE_proc_Arr_Type;
/* Counters for each FE in the system */DCL FE_Counters FE_Count_Arr_Type;
/* Location of all FEs */DCL FE_Location FE_Location_Arr_Type;
DCL count Range_Type;DCL Source_FE FE_Type;DCL FE_Id FE_Type;DCL Proc_Id PID;DCL Dest_Address Address_Type;
Configure the Location of Each FEin the system on startup
initialise all system counters
FE_Location(ENVIRON):= node_internal
FE_Location(SHT) := node_internal
FE_Location(RHT):= node_internal
FE_Counters(Environ) := 0
FE_Counters(RHT):= 0
FE_Counters(SHT):= 0
IDLE
255
F-8
Process OMan_Proc LM_identify(5)
On Startup each Layer Manager identifies itself to the OManager
IDLE
LM_Identify(FE_Id)
Layer_Man_Ids (FE_Id):= SENDER
IDLE
256
F-8
Process OMan_Proc LM_identify(5)
On Startup each Layer Manager identifies itself to the OManager
IDLE
LM_Identify(FE_Id)
Layer_Man_Ids (FE_Id):= SENDER
IDLE
257
F-10
Process OMan_Proc Proc_Reset(5)
If necessary the Omanager can initiate the reset of all FE Processes in the system.
Here it does this on receipt of an OMAN_REST command from the environment
IDLE
OMAN_RESET
Proc_Reset(RHT)
Proc_Reset(SHT)
IDLE
Proc_Reset
258
F-10
Process OMan_Proc Proc_Reset(5)
If necessary the Omanager can initiate the reset of all FE Processes in the system.
Here it does this on receipt of an OMAN_REST command from the environment
IDLE
OMAN_RESET
Proc_Reset(RHT)
Proc_Reset(SHT)
IDLE
Proc_Reset
259
F-11
Process OMan_Proc FE_Location_Req(5)
Look up the Location of an FE in the local Tables
If the destination FE is not in this node or if thedestination FE is the same as the source FE then he destination is node_external
IDLE
FE_Location_Req(Source_FE, Dest_Address)
Dest_Address!FE= Source_FE
FE_Location_Resp(node_external)
IDLE
Dest_Address!FE= RHT
Dest_Address!FE= SHT
Dest_Address!FE= Environ
FE_Location_Resp(node_external)
IDLE
FE_Location_Resp(node_internal)
IDLE
(TRUE)(FALSE)
(FALSE)
(FALSE)
(FALSE)(TRUE)
(TRUE)
(TRUE)
260
F-12
; FPAR IN FE_Id FE_Type;
Procedure Proc_Reset 1(1)
DCL Dest_Id PID;DCL Delete_Id PID;DCL count INTEGER;
count := 0
count =FE_Counters(FE_Id)
Dest_Id :=Layer_Man_Ids(FE_Id)
Delete_Id :=FE_Proc_Ids(FE_Id)(count)
Delete_Req(Delete_Id)TO Dest_Id
Wait_Delete_Resp
Delete_Resp(Delete_Id)
Count :=Count + 1
(TRUE)(FALSE)
261
F-13
Process IF_Proc IF_Proc(1)
A set of exported Proceduresused by all FEs
EXPORTEDFind_Location
IDLE
*
IDLE
262
F-14
; FPAR IN FE_Id FE_Type, IN Dest_Addr Address_Type, IN/OUT Location Location_Type;
Procedure Find_Location 1(1)
FE_Location_Req(FE_Id, Dest_Addr)
Wait_Resp
FE_Location_Resp(Location)
263
F-15
Process Type LayerManagerLib Types(2)
/* An arrray type to contain the PIDs of the Local FE and their status */
NEWTYPE FE_Proc_Arr_Type ARRAY (Range_Type, Proc_Status_Type)ENDNEWTYPE FE_Proc_Arr_Type;
/* Define an array for the binding mechanism to use. For each FE instance a list of all PIDs that it is bound to is needed. */
NEWTYPE Bind_Arr_Type ARRAY (Range_Type, PID_List_Type)ENDNEWTYPE Bind_Arr_Type;
/* Arrays
A list of local Processes anda list of the processes they are bound to */
DCL Proc_List FE_Proc_Arr_Type;DCL Bind_List Bind_Arr_Type;
/* Local Data common to all LMs */
DCLlocal_fe FE_Type,proc_id PID,num_procs Range_Type,index Range_Type,result BOOLEAN,location Location_Type;
This Process Type contains a set of procedures and data which should becommon to each of the Layer Managers.
This Process Type will be inherited by each Layer Manager Process Type in the system
264
F-16
Process Type LayerManagerLib Macro_Definitions(2)
Procedure Decleration Page
Create_Proc_List_Entry Initialise_Bind_FEs
Reset_Proc_List_Entry Get_Bind_Entry
Find_Inactive_Proc Set_Bind_Entry
Get_Pointer
265
F-17
; FPAR IN Proc_id PID;
Procedure Create_Proc_List_Entry 1(1)
This Procedure is called once for each FE Process.It places the PID of the process in Proc_List and marks thatprocess as being inactive.
The number of local processes is incremented.
Proc_List (num_procs)!Proc_id:= Proc_Id
Proc_List (num_procs)!Proc_Status:= FALSE
266
F-18
; FPAR IN index Range_Type;
Procedure Initialise_Bind_FEs 1(1)
Set all elements in the Bind_List entry for index to NULL
Bind_List(index)(ENVIRON):= NULL
Bind_List(index)(RHT):= NULL
Bind_List(index)(SHT):= NULL
267
F-19
; FPAR IN proc_id PID;
Procedure Reset_Proc_List_Entry 1(1)
As processes are static, it makes no sense to delete a process.However a process can be marked as inactive. This means that itis now free to take part in a new procedure
Search Proc_List to find the input Proc_Id. Mark that Process as inactive
index := 0
Proc_List(index)!Proc_Id= proc_id
Proc_List(index)!Proc_Status:= FALSE
index :=index + 1
index =num_procs
(TRUE)(FALSE)
(FALSE)
(TRUE)
268
F-20
; FPAR IN/OUT index Range_Type, IN/OUT proc_id PID, IN/OUT result BOOLEAN;
Procedure Find_Inactive_Proc 1(1)
Search the Proc_Listreturn the PID and index of the first inactive ProcMark the Process as active
If no inactive processes are found then return FALSE
index := 0
Proc_List(index)!Proc_Status
Proc_List(index)!Proc_Status:= TRUE
proc_id :=Proc_List(index)!Proc_Id
result :=TRUE
index :=index + 1
index =num_procs
result := FALSE
(FALSE)(TRUE)
(FALSE)
(TRUE)
269
F-21
; FPAR IN index Range_type, IN fe FE_Type, IN proc_id PID;
Procedure Set_Bind_Entry 1(1)
Read from the Bind_List the entry for the FE stored in row index
Bind_List(index)(fe) := proc_id
270
F-22
; FPAR IN proc_id PID, IN/OUT index Range_Type, IN/OUT result BOOLEAN;
Procedure Get_Pointer 1(1)
Get the index of a given PID in Proc_List.
If the PID is not present in Proc_List thenreturn FALSE
index :=0
Proc_List(index)!Proc_ID= proc_id
result :=TRUE
index :=index + 1
index =num_procs
result := FALSE
(TRUE)
(FALSE)
(FALSE)
(TRUE)
271
F-23
Block Type SHTBlock_Type SHT_Block(1)
/* Messages exchanged between the SHT Processes and the Layer Manager */
SIGNAL UserRegistrationReq (Address_Type, Address_Type, IMUI_Type, SI_Type, TMTI_Type), UserRegistrationResp (Address_Type, Address_Type, Status_Type), Identify_Ind, Reset_Ind, Reset_Req;
/* Signallist */
SIGNALLIST LM2SHT_List = UserRegistrationReq, Reset_Req;SIGNALLIST SHT2LM_List = UserRegistrationResp, Identify_Ind, Reset_Ind;
SHTLayerManager_Type SHTProc_Type
SHT_LM(1,1):SHTLayerManager_Type
SHT(MAX_FE_INST, MAX_FE_INST):SHTProc_Type
SHT2RHT_GATE
(SHT2RHT_List)
(RHT2SHT_List)
SHT2OM_Gate
(LM2OM_List)
(OM2LM_List)
SHT2OM_Gate
SHT2RHT_GateLM_OM (LM2OM_List)
(OM2LM_List)LM2OM_GateLM_RHT(SHT2RHT_List)
(RHT2SHT_List)
LM2RHT_Gate
LM_SHT
(LM2SHT_List)
(SHT2LM_List)
LM2SHT_Gate
SHT2LM_Gate
272
F-24
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type SHTLayerManagerType(8)
/* LOCAL DATA */
DCLSource_Address Address_Type,Dest_Address Address_Type,
Source_Proc PID,Dest_Proc PID,
Source_FE FE_Type,
IMUI IMUI_Type,TMTI TMTI_Type,SI SI_Type,Status Status_Type;
IMPORTED PROCEDURE Find_Location; FPAR IN FE_Type, IN Address_Type, IN/OUT Location_Type;
Inherited TYPESFE_Proc_Arr_TypeBind_Arr_Type
Inherited DATADCL Proc_List FE_Proc_Arr_Type;DCL Bind_List Bind_Arr_Type;
DCL local_fe FE_Type;DCL proc_id PID;DCL num_procs Range_Type;DCL index Range_Type;DCL result BOOLEAN;
Inherited PROCEDURESCreate_Proc_List_Entry (Proc_id)Reset_Proc_List_Entry (Proc_id)Find_Inactive_Proc (index, proc_id, result)Get_Pointer (proc_id, index, result)
Initialise_Bind_FEs (index)Get_Bind_Entry (index, fe, proc_id)Set_Bind_Entry (index, fe, proc_id)
LM2OM_Gate
(LM2OM_List)
(OM2LM_List)
LM2RHT_Gate
(SHT2RHT_List)
(RHT2SHT_List)
LM2SHT_Gate
(LM2SHT_List)
(SHT2LM_List)
273
F-25
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type Startup(8)
On Process Startup, intialise all local variablessend a LM_Identify message to the OManager
local_fe:= SHT
num_procs:= 0
index:= 0
result:= FALSE
LM_Identify(local_fe)VIA LM2OM_Gate
IDLE
274
F-26
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type Proc_Setup(8)
As Local Processes startup they identify themselves tothe Layer Manager. Creste an entry in Proc_List for each process as it identifies itself. Initialse the bind_list entry for the processincrement number of processes
IDLE
Identify_Ind
Create_Proc_List_Entry(SENDER)
Initialise_Bind_FEs(num_procs)
num_procs :=num_procs +1
Create_Ind(local_fe, SENDER)VIA LM2OM_Gate
IDLE
275
F-27
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type Oman_Proc_Reset(8)
The Omanager can ask that a process be reset.
Send a reset request to the process and delete all data associtedwith the process.
ASSUMPTION all processes will be reset by the OManager at the same timeand so there is no need to initialse deletng of data in other Layer Managers
IDLE
Delete_Req(proc_id)
Get_Pointer(proc_id, index, result)
result
Initialise_Bind_FEs(index)
Reset_Proc_List_Entry(proc_id)
Reset_ReqTO proc_idVIA LM2SHT_Gate
Delete_Resp(proc_id)VIA LM2OM_Gate
IDLE
IDLE
(TRUE)(FALSE)
276
F-28
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type Bind_Req(8)
On Receipt of a bind_req, search for an inactive process and allocate it forthe procedure.Sebnd a bind_resp
IDLE
Bind_Req(Source_FE, Source_Proc)
Find_Inactive_Proc(index, proc_id, result)
result
Set_Bind_Entry(index, Source_FE, Source_Proc)
Bind_Resp(Source_FE, Source_Proc, proc_id)
IDLE
Bind_Resp(Source_FE, Source_Proc, NULL)
IDLE
(TRUE)(FALSE)
277
F-29
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type User_Registration_Req(8)
On Receipt of a User_Registration_Req message from the RHT block,route the message to the correct SHT process
IDLE
User_Registration_Req(Source_Proc, Dest_Proc, IMUI, SI, TMTI)
Source_Address!Node:= NULL_NODE
Source_Address!FE:= RHT
Dest_Address!Node:= NULL_NODE
Dest_Address!FE:= local_fe
UserRegistrationReq(Source_Address, Dest_Address, IMUI, SI, TMTI)TO Dest_ProcVIA LM2SHT_Gate
IDLE
278
F-30
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type UserRegistrationResp(8)
On Receipt of a UserRegistrationResp from an SHT proc Check if the destination is node_internal or node_external
If node_Internal then the dest must be an RHTFind the bound RHT procroute the message to the RHT Block
If node_external, call external routing mechanism
IDLE
UserRegistrationResp(Source_Address, Dest_Address, Status)
Source_Proc := SENDER
Use of RPCs up-datesthe SENDER variable sostore the Source_Proc now
Find_Location(local_fe, Dest_Address, location)
location= node_internal
Get_Pointer(Source_Proc, index, result)
result
Get_Bind_Entry(index, Dest_Address!FE, Dest_Proc)
User_Registration_Resp(Source_Proc, Dest_Proc, Status)VIA LM2RHT_Gate
IDLE
IDLE
IDLE
(TRUE)
(TRUE)(FALSE)
(FALSE)
279
F-31
INHERITS LayerManagerLib;
Process Type SHTLayerManager_Type Proc_Reset(8)
On receipt of a Reset_Ind from a ProcReset the status of the ProcInitiate the deletion of any binds it has with other processesDelete the local bind data for that proc
IDLE
Reset_Ind
Get_Pointer(SENDER, index, result)
result
Get_Bind_Entry(index, RHT, Dest_Proc)
Initialise_Bind_FEs(index)
Reset_Proc_List_Entry(SENDER)
Unbind_Ind(local_fe, SENDER, Dest_Proc)
IDLE
IDLE
(TRUE)(FALSE)
280
F-32
Process Type SHTProc_Type SHT_Proc(3)
/* Local Data */
DCLSource_Address Address_Type,Dest_Address Address_Type,
TMTI TMTI_Type,IMUI IMUI_Type,SI SI_Type,Status Status_Type;
Initialise_Data On process startup, initialse thelocal data and send an Identify messageto the Layer Manager
Initialise_Data
Identify_IndVIA SHT2LM_Gate
IDLE
SHT2LM_Gate(SHT2LM_List)
(LM2SHT_List)
281
F-33
Process Type SHTProc_Type Reset_Req(3)
*
Reset_Req
Initialise_Data
IDLE
In any stateOn Receipt of a Reset_Reqreset all local data and goto the IDLE state
282
F-34
Process Type SHTProc_Type UserRegistrationReq(3)
This is the only message received in this example. Send a UserRegistrationResp to the RHT
When the procedure is complete, reset the processreinitialise the local datasend a reset_Ind to the Layer Manager
IDLE
UserRegistrationReq(Source_Address, Dest_Address, IMUI, SI, TMTI)
Status :=TRUE
UserRegistrationResp(Dest_Address, Source_Address, Status)VIA SHT2LM_Gate
Initialise_Data
Reset_Ind
IDLE
283
F-35
Procedure <<Process Type SHTProc_Type>> Initialise_Data 1(1)
TMTI := 0
IMUI := 0
SI := 0
Status:= FALSE
284
F-36
Block Type RHTBlock_Type RHT_Block(1)
/* Messages exchanged between the RHT Processes and the Layer Manager */
SIGNAL UserRegReq (Address_Type, Address_Type, IMUI_Type, SI_Type), UserRegResp (Address_Type, Address_Type, Status_Type), UserRegistrationReq (Address_Type, Address_Type, IMUI_Type, SI_Type, TMTI_Type), UserRegistrationResp (Address_Type, Address_Type, Status_Type), Identify_Ind, Reset_Ind, Reset_Req;
/* Signallist */
SIGNALLIST LM2RHT_List = UserRegReq, UserRegistrationResp, Reset_Req;SIGNALLIST RHT2LM_List = UserRegResp, UserRegistrationReq, Identify_Ind, Reset_Ind;
RHT_LM(1,1):RHTLayerManager_Type
RHT(MAX_FE_INST, MAX_FE_INST):RHTProc_Type
RHTLayerManager_Type RHTProc_Type
RHT2ENV_Gate
(RHT2ENV_List)
(ENV2RHT_List)
RHT2SHT_GATE
(RHT2SHT_List)
(SHT2RHT_List)
RHT2OM_Gate
(LM2OM_List)
(OM2LM_List)
RHT2ENV_Gate
LM_ENV
(ENV2RHT_List)
(RHT2ENV_List)LM2ENV_Gate
LM_OM (LM2OM_List)
(OM2LM_List)LM2OM_Gate
RHT2OM_Gate
LM_SHT(RHT2SHT_List)
(SHT2RHT_List)
LM2SHT_Gate
RHT2SHT_Gate
LM_RHT
(LM2RHT_List)
(RHT2LM_List)
LM2RHT_Gate
RHT2LM_Gate
285
F-37
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type RHTLayerManagerType(12)
IMPORTED PROCEDURE Find_Location; FPAR IN FE_Type, IN Address_Type, IN/OUT Location_Type;
/* LOCAL DATA */
DCLSource_Address Address_Type,Dest_Address Address_Type,
Source_Proc PID,Dest_Proc PID,
Source_FE FE_Type,
IMUI IMUI_Type,TMTI TMTI_Type,SI SI_Type,Status Status_Type;
Inherited TYPESFE_Proc_Arr_TypeBind_Arr_Type
Inherited DATADCL Proc_List FE_Proc_Arr_Type;DCL Bind_List Bind_Arr_Type;
DCL local_fe FE_Type;DCL proc_id PID;DCL num_procs Range_Type;DCL index Range_Type;DCL result BOOLEAN;
Inherited PROCEDURESCreate_Proc_List_Entry (Proc_id)Reset_Proc_List_Entry (Proc_id)Find_Inactive_Proc (index, proc_id, result)Get_Pointer (proc_id, index, result)
Initialise_Bind_FEs (index)Get_Bind_Entry (index, fe, proc_id)Set_Bind_Entry (index, fe, proc_id)
LM2OM_Gate
(LM2OM_List)
(OM2LM_List)
LM2ENV_Gate
(RHT2ENV_List)
(ENV2RHT_List)
LM2SHT_Gate
(RHT2SHT_List)
(SHT2RHT_List)
LM2RHT_Gate
(LM2RHT_List)
(RHT2LM_List)
286
F-38
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Startup(12)
On Process Startup, intialise all local variablessend a LM_Identify message to the OManager
local_fe:= RHT
num_procs:= 0
index:= 0
result:= FALSE
LM_Identify(local_fe)VIA LM2OM_Gate
IDLE
287
F-39
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Proc_Setup(12)
As Local Processes startup they identify themselves tothe Layer Manager. Creste an entry in Proc_List for each process as it identifies itself. Initialse the bind_list entry for the processincrement number of processes
IDLE
Identify_Ind
Create_Proc_List_Entry(SENDER)
Initialise_Bind_FEs(num_procs)
num_procs :=num_procs +1
Create_Ind(local_fe, SENDER)VIA LM2OM_Gate
IDLE
288
F-40
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Oman_Proc_Reset(12)
The Omanager can ask that a process be reset.
Send a reset request to the process and delete all data associtedwith the process.
ASSUMPTION all processes will be reset by the OManager at the same timeand so there is no need to initialse deletng of data in other Layer Managers
IDLE
Delete_Req(proc_id)
Get_Pointer(proc_id, index, result)
result
Initialise_Bind_FEs(index)
Reset_Proc_List_Entry(proc_id)
Reset_ReqTO proc_idVIA LM2RHT_Gate
Delete_Resp(proc_id)VIA LM2OM_Gate
IDLE
IDLE
(TRUE)(FALSE)
289
F-41
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Bind_Req(12)
On Receipt of a bind_req, search for an inactive process and allocate it forthe procedure.Sebnd a bind_resp
IDLE
Bind_Req(Source_FE, Source_Proc)
Find_Inactive_Proc(index, proc_id, result)
result
Set_Bind_Entry(index, Source_FE, Source_Proc)
Source_FE= ENVIRON
IDLEBind_Resp(Source_FE, Source_Proc, proc_id)VIA LM2ENV_Gate
IDLE
Bind_Resp(Source_FE, Source_Proc, NULL)
IDLE
(TRUE)
(FALSE)(TRUE)
(FALSE)
290
F-42
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type User_Reg_Req(12)
On Receipt of a User_Reg_Req message from the environment,route the message to the correct RHT process
IDLE
User_Reg_Req(Source_Proc, Dest_Proc, IMUI, SI)
Source_Address!Node:= NULL_NODE
Source_Address!FE:= ENVIRON
Dest_Address!Node:= NULL_NODE
Dest_Address!FE:= RHT
UserRegReq(Source_Address, Dest_Address, IMUI, SI)TO Dest_ProcVIA LM2RHT_Gate
IDLE
291
F-43
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type UserRegistrationReq(12)
In this example, the sending of a UserRegistrationReq messsage initiates the bindingof the Source RHT Proc with an SHT proc.
If the Layer Manager cannot tell from the message name alone that a new binding is neededthen it may also need to interpret one of the fields in the messages to get this infromation
IDLE
UserRegistrationReq(Source_Address, Dest_Address, IMUI, SI, TMTI)
Bind_Req(local_fe, SENDER)VIA LM2SHT_Gate
Wait_SHT_Resp
292
F-44
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Wait_SHT_Resp(12)
On receipt of a Bind_Resp from the SHT, complete the binding in the RHTand send any pending messages
Wait_SHT_Resp
Bind_Resp(Source_FE, Source_Proc, Dest_Proc)
Dest_Proc= NULL
Get_Pointer(Source_Proc, index, result)
result
Set_Bind_Entry(index, Dest_Address!FE, Dest_Proc)
User_Registration_Req(Source_Proc, Dest_Proc, IMUI, SI, TMTI)
IDLE
IDLE
IDLE
(FALSE)
(TRUE)(FALSE)
(TRUE)
293
F-45
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type User_Registration_Resp(12)
On Receipt of a User Regsitration Resp from the SHT send the messageto the correct RHT Process
IDLE
User_Registration_Resp(Source_Proc, Dest_Proc, Status)
Source_Address!Node:= NULL_NODE
Source_Address!FE:= SHT
Dest_Address!Node:= NULL_NODE
Dest_Address!FE:= RHT
UserRegistrationResp(Source_Address, Dest_Address, Status)TO Dest_ProcVIA LM2RHT_Gate
IDLE
294
F-46
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type UserRegResp(12)
On Receipt of a UserRegResp from an RHT proc Check if the destination is node_internal or node_external
If node_Internal then the dest should be ENVIRONFind the bound procroute the message to the environment
If node_external, call external routing mechanism
IDLE
UserRegResp(Source_Address, Dest_Address, Status)
Source_Proc:= SENDER
Use of an RPC updates the SENDERvariable so save the Source_Proc here
Find_Location(local_fe, Dest_Address, location)
location= node_internal
Get_Pointer(Source_Proc, index, result)
result
Get_Bind_Entry(index, Dest_Address!FE, Dest_Proc)
Dest_Address!FE= ENVIRON
User_Reg_Resp(Source_Proc, Dest_Proc, Status)VIA LM2ENV_Gate
IDLE
IDLE
IDLE
IDLE
(TRUE)
(TRUE)
(TRUE)(FALSE)
(FALSE)
(FALSE)
295
F-47
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Unbind_ind(12)
On receipt of an Unbind messages, delete all data associated withthe Source Process.
In this example the RHT only receives Unbind messages from the SHT.
IDLE
Unbind_Ind(Source_FE, Source_Proc, Dest_Proc)
Get_Pointer(Dest_Proc, index, result)
result
Set_Bind_Entry(index, Source_FE, NULL)
IDLE
IDLE
(TRUE)(FALSE)
296
F-48
INHERITS LayerManagerLib;
Process Type RHTLayerManager_Type Proc_Reset(12)
On receipt of a Reset_Ind from a ProcReset the status of the ProcInitiate the deletion of any binds it has with other processesDelete the local bind data for that proc
If a local process is reset that means the procedure the process was runnning is completeThis implies that any SHT processes involved in th procedure have already reset themselvesSo only the Environment needs to be informed of the of the reset
IDLE
Reset_Ind
Get_Pointer(SENDER, index, result)
result
Get_Bind_Entry(index,ENVIRON, Dest_Proc)
Initialise_Bind_FEs(index)
Reset_Proc_List_Entry(SENDER)
Unbind_Ind(local_fe, SENDER, Dest_Proc)VIA LM2ENV_Gate
IDLE
IDLE
(TRUE)(FALSE)
297
F-49
Process Type RHTProc_Type RHT_Proc(5)
/* Local Data */
DCLSource_Address Address_Type,Dest_Address Address_Type,
TMTI TMTI_Type,IMUI IMUI_Type,SI SI_Type,Status Status_Type,
UserRegTimeout TIME,UserRegDuration DURATION;
TIMER UserRegTimer;
Initialise_Data On process startup, initialse thelocal data and send an Identify messageto the Layer Manager
UserRegDuration:= 10
Initialise_Data
Identify_IndVIA RHT2LM_Gate
IDLE
RHT2LM_Gate(RHT2LM_List)
(LM2RHT_List)
298
F-50
Process Type RHTProc_Type Reset_Req(5)
*
Reset_Req
Initialise_Data
IDLE
In any stateOn Receipt of a Reset_Reqreset all local data and goto the IDLE state
299
F-51
Process Type RHTProc_Type UserRegReq(5)
On receipt of a UserRegReq message,
Send a UserRegistrationReq to the SHT.Start the UserRegTimer
Enter the Wait_UserRegistrationResp state
IDLE
UserRegReq(Source_Address, Dest_Address, IMUI, SI)
Source_Address:= Dest_Address
Dest_Address!Node:= NULL_NODE
Dest_Address!FE:= SHT
UserRegTimeout :=NOW + UserRegDuration
SET(UserRegTimeout, UserRegTimer)
UserRegistrationReq(Dest_Address, Source_Address, IMUI, SI, TMTI)VIA RHT2LM_Gate
Wait_UserRegistrationResp
300
F-52
Process Type RHTProc_Type UserRegistrationResp(5)
When the UserRegistrationResop message is received in the Wait_UserRegistrationResp statesend a UserRegResp to the environmentReset the UserRegTimer
This Registration Procedure is now complete so reset the process
Wait_UserRegistrationResp
UserRegistrationResp(Source_Address, Dest_Address, Status)
RESET(UserRegTimer)
Source_Address:= Dest_Address
Dest_Address!Node:= NULL_NODE
Dest_Address!FE:= ENVIRON
UserRegResp(Source_Address, Dest_Address, Status)VIA RHT2LM_Gate
Initialise_Data
Reset_IndVIA RHT2LM_Gate
IDLE
301
F-53
Process Type RHTProc_Type UserRegTimeout(5)
If the UserRegTimer Expires while in The Wait_User_Registration stateSend a UserRegResp with status = Falsereinitialise the process
Wait_UserRegistrationResp
UserRegTimer
Status :=FALSE
Source_Address:= Dest_Address
Dest_Address!Node:= NULL_NODE
Dest_Address!FE:= ENVIRON
UserRegResp(Source_Address, Dest_Address, Status)VIA RHT2LM_Gate
Initialise_Data
Reset_IndVIA RHT2LM_Gate
IDLE
302
F-54
Procedure <<Process Type RHTProc_Type>> Initialise_Data 1(1)
TMTI := 11
IMUI := 0
SI := 0
Status:= FALSE
303
304
Appendix F
SDL Description of the MT SNL
305
E-1
Block Type Mobile_Terminal Mobile_Terminal(5)
/* Title : SDL Framework for Specfication, Testing and Implementation of Lower Layer Signalling Control in the MT
authors : Michael Barry ( University of Limerick ) Date : 07 July 1997
Version : 1.1
Status :
History.
Version 1.1
|--------------------|---------------|-----------|----------------| | Document Version | author | Date | Comments | |--------------------|---------------|-----------|----------------| | Issue 1.0 | M Barry | 07-7-97 | First Draft | |--------------------|---------------|-----------|----------------|
*/
306
E-2
Block Type Mobile_Terminal MT_Signals(5)
307
E-3
Block Type Mobile_Terminal MT_Signallists(5)
SIGNALLIST SNL_Service_in = N_UNITDATAreq;
SIGNALLIST SNL_Service_out = N_UNITDATAind,N_NOTICEind;
SIGNALLIST SNL_Config_In = Node_Address, Higher_Address, VPI_VCI, Node_Addr, FE_Addr;
SIGNALLIST SNL_Config_Out = VPI_VCI_Resp;
SIGNALLIST SNL2SBE_List = DCCH_Open_Req;
SIGNALLIST SBE2SNL_List = DCCH_Open_Resp;
SIGNALLIST SNL2RAL_List = Sig_Data_Req;
SIGNALLIST RAL2SNL_List = Sig_Data_Ind;
308
E-4
Block Type Mobile_Terminal Block_Declerations(5)
NL_Terminal
MT2ENV_Gate
(MT2ENV_List)
(ENV2MT_List)
MT2Config_Gate
(MT2Config_List)
(Config2MT_List)
309
E-5
Block Type Mobile_Terminal BlockInteractionPage(5)
MT_SNL:NL_Terminal
MT2ENV_Gate
MT2Config_Gate
SNL_CCS
(SNL_Config_In)
(SNL_Config_Out)Config_Gate
SNL_Service
(SNL_Service_Out)
(SNL_Service_In)
SNL_Service_Gate
SNL_RAL
(SNL2RAL_List)
(RAL2SNL_List)
SNL2RAL_Gate
MT2ENV_GateMT2ENV_Gate
SBE_SNL
(SBE2SNL_List)
(SNL2SBE_List)
SNL2SBE_Gate
310
E-6
Block Type NL_Terminal Comments(2)
/* Title : SDL Framework for Specifictaion and Testing of the NL_Terminal, to be located in the MT
Authors : Michael Barry (University of limerick) Daniel Madden (University of limerick)
Date : 26/06/1997
Version : 1.0
Status : Draft
Ver 1.0 : The Block diagram needs extensive reworking to improve readability and definition of signals
History.
|--------------------|---------------|-----------|--------------| | Document Version | Author | Date | Comments | |--------------------|---------------|-----------|--------------| | Issue 1.0 | M Barry | | First Draft | | | D Madden | | | |--------------------|---------------|-----------|--------------|*/
SIGNAL
/* Netwok Layer Messages */UDT (SNLMessage);
SNL_Service_Gate
(SNL_Service_Out)
(SNL_Service_In)
SNL2RAL_Gate(SNL2RAL_List)
(RAL2SNL_List)
SNL2SBE_Gate(SNL2SBE_List)
(SBE2SNL_List)
Config_Gate
(SNL_Config_Out)
(SNL_Config_In)
311
E-7
Block Type NL_Terminal NL_Terminal_Interacations(2)
Service_Send( 0, )
R_Transmit_MT( 0, )
Configuration
Service_Rec( 0, )
R_Received_MT( 0, )
SNL_Service_gate
In_Service
(SNL_Service_In)
1
UDT
SBE(SNL2SBE_List)
(SBE2SNL_List)
SNL2SBE_Gate
RAL_Out
(SNL2RAL_List)
SNL2RAL_Gate
SNL_Service_gate
Config_Gate
Config
(SNL_Config_In)
(SNL_Config_Out)
Out_Service
(SNL_Service_Out)
2
UDT
SNL2RAL_Gate
RAL_In
(RAL2SNL_List)
312
E-8
;FPAR Current_Node NodeAddressTypeC;
Process <<Block Type NL_Terminal>> Service_Send Initialisation(2)
DCL PDU SNLMessage;DCL Source_Address SNLAddressTypeC;DCL Dest_Address SNLAddressTypeC;DCL Msg MessageOctetTypeC;DCL Msg_Num INTEGER;
Service_Send_Fixed
Only One Instance neededTakes a N_UNITDATA messageand creates a SNL PDU
Sends the message to the routing process
Create_UDT
Msg_Num:= 0
IDLE
313
E-9
;FPAR Current_Node NodeAddressTypeC;
Process <<Block Type NL_Terminal>> Service_Send IDLE(2)
IDLE
N_UNITDATAreq(Source_Address, Dest_Address, Msg)
Create_UDT
Msg_Num :=Msg_Num + 1
UDT(PDU)
IDLE
314
E-10
Procedure <<Block Type NL_Terminal/Process Service_Send>> Create_UDT Create_UDT(1)
PDU!msg := UDT
PDU!SNLMessage_u!udt!src:= Source_Address
PDU!SNLMessage_u!udt!dest:= Dest_Address
PDU!SNLMessage_u!udt!payload!message := Msg!message
PDU!SNLMessage_u!udt!len := Msg!length
315
E-11
;FPAR Current_Node NodeAddressTypeC;
Process R_Transmit_MT R_Transmit_MT(5)
DCL Pdu SNLMessage;DCL NewPdu SNLMessage;DCL Edge_ID BTSIdTypeC;DCL TC TCType;DCL Length LengthType;DCL QM QMType;DCL Status ResultTypeC;DCL DCCH_ID ralSapIdTypeC;DCL Current_EDGE BTSIdTypeC;DCL MT_ID MTIdTypeC;
Function R_Transmit_MT
One instance for BTS
Passes routed packets to theData Link Layer using lower layerPrimitives
On Startup This Process identifiesitself to the Routing database.
It then recieves the address of the network entity it will pass messagesto.
This information is sent to Link_Controlwhich returnds the PID of the processin the data link layer used to passmessages
316
E-12
;FPAR Current_Node NodeAddressTypeC;
Process R_Transmit_MT Initialisation(5)
TC := 0
QM := 0
Edge_ID:= 0
IDLE
317
E-13
;FPAR Current_Node NodeAddressTypeC;
Process R_Transmit_MT UDT(5)
idle
UDT(Pdu)
DCCH_Open_Req(MT_ID)
DCCH_Pending
318
E-14
;FPAR Current_Node NodeAddressTypeC;
Process R_Transmit_MT DCCH_Open_Resp(5)
DCCH_Pending
DCCH_Open_Resp(Edge_ID, DCCH_ID, Status)
Status =RESULTOK
Update_Edge(Edge_ID, Status)
Status =RESULTOK
Create_Add(Edge_ID, NewPdu)
Sig_Data_Req(TC, QM, Length, NewPdu)
Length :=Pdu!SNLMessage_u!udt!len + 7
Sig_DATA_Req(TC, QM, Length, Pdu)
IDLE
(TRUE)
(TRUE)(FALSE)
(FALSE)
319
E-15
;FPAR Current_Node NodeAddressTypeC;
Process R_Transmit_MT Procedures(5)
Create_Add
Update_Edge
320
E-16
;FPAR IN Edge_ID BTSIdTypeC, IN/OUT Pdu SNLMessage;
Procedure Create_Add Create_Add(1)
PDU!msg:= IDN
PDU!SNLMessage_u!idn!src!node:= Current_Node
PDU!SNLMessage_u!idn!dest!node:= Edge_Id
PDU!SNLMessage_u!idn!len := 14
321
E-17
; FPAR IN/OUT Edge_ID BTSIdTypeC, IN/OUT Status ResultTypeC;
Procedure Update_Edge Update_Edge(1)
return TRUE ifEDGE is to be updated
Edge_ID = Current_EDGE
Status :=RESULTNOK
Status := RESULTOK
Current_EDGE :=EDGE_ID
(TRUE) (FALSE)
322
E-18
Process <<Block Type NL_Terminal>> Configuration VPI_VCI(1)
DCL Current_Node NodeAddressTypeC;
IDLE
Node_Address(Current_Node)
R_Received_MT(Current_Node)
R_Transmit_MT(Current_Node)
Service_Rec(Current_Node)
Service_Send(Current_Node)
IDLE
323
E-19
;FPAR Current_Node NodeAddressTypeC;
Process <<Block Type NL_Terminal>> Service_Rec Service_Rec(2)
DCL MsgNo INTEGER;DCL PDU SNLMessage;DCL Source_Address SNLAddressTypeC;DCL Dest_Address SNLAddressTypeC;DCL Msg MessageOctetTypeC;
Service_Rec_Fixed
Only one instance necessary
Outputs messages to TCAP or to UCC depending on Dest_Address
No duplicates at the momenttaken out for convienence
Create_Unitdata
IDLE
324
E-20
;FPAR Current_Node NodeAddressTypeC;
Process <<Block Type NL_Terminal>> Service_Rec IDLE_UDT(2)
IDLE
UDT(PDU)
Create_Unitdata
Dest_Address!node= Current_Node
Source_Address!selector= UCCASELECTOR
N_Noticeind(Source_Address, Dest_Address, Msg )
IDLE
N_Noticeind(Source_Address, Dest_Address, Msg)
Dest_Address!selector= UCCASELECTOR
N_UNITDATAind(Source_Address, Dest_Address, Msg )
N_UNITDATAind(Source_Address, Dest_Address, Msg)
(TRUE)
(TRUE) (FALSE)
(FALSE)
(TRUE) (FALSE)
325
E-21
Procedure <<Block Type NL_Terminal/Process Service_Rec>> Create_Unitdata Create_Unitdata(1)
MsgNo := PDU!SNLMessage_u!udt!seqNum
Source_Address :=PDU!SNLMessage_u!udt!src
Dest_Address := PDU!SNLMessage_u!udt!dest
Msg!message :=PDU!SNLMessage_u!udt!payload!message
Msg!length :=PDU!SNLMessage_u!udt!len
326
E-22
;FPAR Current_Node NodeTypeC;
Process R_Received_MT R_Received_MT(1)
DCL Pdu SNLMessage;DCL TC TCType;DCL Length LengthType;DCL QM QMType;
Process R_Receive_MT
One instance for each BTS.
recieves routed packets from theData Link Layer using lower layerPrimitives ans distributes withinentity
idle
Sig_DATA_ind(TC, QM, Length, Pdu)
UDT(Pdu)
idle
On Startup This Process identifiesitself to the Routing database.
It then recieves the address of the network entity it will receive messagesfrom.
This information is sent to Link_Controlwhich returnds the PID of the processin the data link layer used to passmessages
327
328
Appendix G
List of publications
Publications
Arik Elberse, Michael Barry, Gary Fleming; DECT Data Services; Proceedings of DECT in Fixed and
Mobile Networks; Paris, France; July 1996
John Nelson, Michael Barry, Gary Fleming, Daniel Madden; UMTS Signalling Network Layer and its
Verification using SDL; Proceedings of the ACTS Mobile Summit; Granada, Spain; November 1996
Nadege Faggion, Michael Barry, Andreas Weber, Caren Crowley; Application of In Protocols and
Framework to Mobility Management in the Rainbow Project; Proceedings of the ACTS Mobile Summit;
Aalborg, Denmark; October 1997
Abdelkerime Saidi, Gary Fleming, Michael Barry, Amre El-Hoyidi, Bernard Perrin, Georgous Niko-
laidis, Ionnais Modeas, Flavio Piolini; Rainbow Demonstrator Transport Chain; Proceedings of the ACTS
Mobile Summit; Aalborg, Denmark; October 1997
Michael Barry, Andreas Gammelgaard, John Nelson, Dietrich Zeller; Protocols to Implement the SNL
for COBUCO and RAINBOW; Proceedings of the ACTS Mobile Summit; Aalborg, Denmark; October
1997
Michael Barry, Liam Gray, Bernard Perrin, Guy Reyniers; Control Plane Management in the RAIN-
BOW System; Proceedings of the ACTS Mobile Summit; Rhodes, Greece; June 1998
Deliverables contributed to
CEC Deliverable AC015/CSELT/RAP1/DS/R/008/b1; ”RAS Architectures: definition, allocation and
specification of BTS/MS functional entities”; October 1996
CEC Deliverable AC015/UL/RAP1/DS/R/009/b1; ”Specification of the non emulated UMTS BTS/MS
protocols and related migration issues”; October 1996
CEC Deliverable AC015/CSELT/RAP1/DS/I/012/b1; ”Specification of the BTS Hardware/Software
platforms”; December 1996
CEC Deliverable AC015/CSEM/RAP1/DS/I/013/b1; ”Specification of the MS Hardware/Software plat-
329
forms”; December 1997
CEC Deliverable AC015/CSELT/RAP1/DS/R/016/b1; Detailed specification of interfaces towards FRAMES;
January 1997
CEC Deliverable AC015/CSELT/RAP1/DS/I/023/b1, ”Prototype of BTS equipment”, December 1997
CEC Deliverable AC015/CSEM/RAP1/DS/I/024/b1, ”Prototype of MS equipment”, December 1997
330