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.


November 27 1998

Abstract

Control Architectures for an Advanced Mobile Terminal


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

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



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


LAPDm


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].


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


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



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


Internet


N/B-ISDN



GSMAccess Part

DECTAccess Part

GSM Access Adaptation DECT Access Adaptation

Iu Interface

UMTS GRANRadio Dependent

Part #1

UMTS GRANRadio Access

Part #


Part #n


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


Part #1


Part #1


Part #n


Part #n

UMTS GRANGSM Radio

Dependent Part

GSMRadio Access

Part

UMTS GRANDECT Radio

Dependent Part

DECTRadio Access

Part

UMTS GRANRadio Independent Part

t





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


[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.


UserRegistrationReq

UserRegistrationResp



[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.


LocationUpdateReq

LocationUpdateResp



[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.


AccessReq

AccessResp



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


HandoverInitiationReq

HandoverInitiationResp



[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



HandoverExecuteResp

BearerSetupReq

BearerSetupResp

BearerReleaseReq

BearerReleaseResp

CallControlGroup

BearerModifyReq

HandoverResp

BearerOpenReq

BearerOpenResp

BearerCloseReq

BearerCloseResp

HandoverExecuteReq

HandoverReq

SwitchResp

SwitchReq


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


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


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


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


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


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.




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



Mobility Adaptation Layer(MAL)



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


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

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

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.


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


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


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


Transport


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


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 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


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.


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

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

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

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.


|--------------------|---------------|-----------|----------------| | 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


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


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



|--------------------|---------------|-----------|----------------| | 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;


IMPORTED PROCEDURE Get_TMTI; FPAR IN/OUT TMTIType;


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



|--------------------|---------------|-----------|----------------| | 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;



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;


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 Store_SI; FPAR IN IMUIType, IN SIType;

IMPORTED PROCEDURE Get_SI; FPAR IN IMUIType, IN/OUT SIType;


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


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


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


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


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


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


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


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


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


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


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)


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 */


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


Process Type RHTLayerManager_Type RHTLayerManagerType(12)

IMPORTED PROCEDURE Find_Location; FPAR IN FE_Type, IN Address_Type, IN/OUT Location_Type;

/* LOCAL DATA */


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


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


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


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


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


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


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!FE:= ENVIRON


Dest_Address!FE:= RHT

UserRegReq(Source_Address, Dest_Address, IMUI, SI)TO Dest_ProcVIA LM2RHT_Gate

IDLE

291

F-43


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


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


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


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!FE:= SHT


Dest_Address!FE:= RHT

UserRegistrationResp(Source_Address, Dest_Address, Status)TO Dest_ProcVIA LM2RHT_Gate

IDLE

294

F-46


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


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


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


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)


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 */


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!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


UserRegistrationResp(Source_Address, Dest_Address, Status)

RESET(UserRegTimer)



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


UserRegTimer

Status :=FALSE



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

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


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


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


Process R_Transmit_MT Initialisation(5)

TC := 0

QM := 0

Edge_ID:= 0

IDLE

317

E-13


Process R_Transmit_MT UDT(5)

idle

UDT(Pdu)

DCCH_Open_Req(MT_ID)

DCCH_Pending

318

E-14


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


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


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


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

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

A Flexible Control Architecture for the UMTS Mobile Terminal

Documents

Transcript of A Flexible Control Architecture for the UMTS Mobile Terminal