Bss Documentation

Alcatel BSS
BSS System Description
BSS Document Concept Guide Release B8
3BK 20822 AAAA TQZZA Ed.04
BLANK PAGE BREAK
Status Short title
RELEASED System Description

All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel/Evolium.
2 / 262
Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 EVOLIUM Radio Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Extended GSM Band (E-GSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 GSM 850 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Frequency Band Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 BSS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 BSS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Base Station Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Base Transceiver Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Transcoder And Transmission Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 The Multi-BSS Fast Packet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Extended GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 E-GSM Mobile Station Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 E-GSM Management After Initial Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 E-GSM Determination at Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.4 TCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 External Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Network Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Mobile Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Phase 2 Mobile Support in a Phase 1 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Operations and Maintenance Center-Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Telecommunications Management Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Q3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 BSS Telecommunications Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Call Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 Mobility Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 Radio Resource Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.4 The A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.5 The Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.6 The Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7 Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.8 The Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.9 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.10 Dynamic SDCCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Packet Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 GPRS Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 GPRS Channels and System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 MPDCH Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Master Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Static Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Multiple PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16 16 17 17 17 17 18 18 19 19 19 20 20 21 24 25 27 27 28 28 28 29 30 31 35 35 36 36 37 37 38 38 38 39 40 40 41 42 45 48 49 50 50 51 54 54 54 54 56 57 57
3 / 262
Contents
2.3
2.2.7 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 GPRS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.3.1 The Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.3.2 The BSCGP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.3.3 The GCH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.3.4 Specific LCS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4 GPRS Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.1 MAC and RLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.2 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.3 Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.4.4 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.4.5 Radio Power Control and Radio Link Measurement . . . . . . . . . . . . . . . . . . . . . . . . 67 2.5 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 2.5.1 Time Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.5.2 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.5.3 PCM Link Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.5.4 TBF Resource Re-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.6 Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.6.1 PDCH Allocation with "High Load Traffic" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.6.2 Smooth PDCH Traffic Adaption to Cell Load Variation . . . . . . . . . . . . . . . . . . . . . . 72 2.6.3 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.6.4 GPRS Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.7 Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.7.1 GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.7.2 Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.7.3 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 2.7.4 Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.7.5 GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 2.7.6 GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 2.7.7 GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.8 Location Services (LCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.8.2 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.8.3 LCS Positioning Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2.8.4 LCS Scenario in Circuit-Switched Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 2.8.5 Physical Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 2.8.6 SMLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 2.8.7 BSS and Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 2.8.8 LCS O&M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 2.9 High Speed Data Service (HSDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.9.1 HSDS Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.9.2 GPRS CS3/CS4 and EGPRS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 2.9.3 Transmission Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 2.9.4 Cell/GPU Mapping Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 2.9.5 GCH Congestion Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.1.1 Call Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.1.2 Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.2 Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.2.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.2.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.2.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.3 Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.3.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.3.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.3.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4 / 262
Contents
3.3.4 Off Air Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 IMSI Attach-Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Paging Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 In-queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Classmark IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Classmark Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Location Updating with Classmark Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 IMSI/TMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Authentication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Mobile Station Ciphering Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.2 BSS Ciphering Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.3 Ciphering Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.4 Ciphering Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Tandem Free Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.1 TFO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.2 TFO Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.3 TFO Optimization and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 In-Call Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 In-Call Modification Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Circuit-Switched Group 3 Fax Data Rate Change . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Synthesized Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Speech Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Continuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Voice Activity Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 BSS Discontinuous Transmission Towards Mobile Station . . . . . . . . . . . . . . . . . 4.4.5 Mobile Station Discontinuous Transmission Towards BSS . . . . . . . . . . . . . . . . . 4.5 Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 BTS Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Mobile Station Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Power Control Decision and Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5 Change Power Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Principal Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Radio Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Handover Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 Target Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5 Synchronous and Asynchronous Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6 Circuit-Switched Telecom Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 BTS Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2 BSC Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Call Re-establishment by the Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
118 118 119 121 123 124 124 125 127 128 129 131 132 133 133 134 134 135 135 136 136 138 139 140 141 143 144 144 145 146 146 147 148 149 150 150 150 151 151 152 154 154 154 155 156 157 159 160 161 162 169 171 174 176 176 177 179
5 / 262
Contents
Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Call Release Procedures in Normal Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Normal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Calls Terminated Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Call Release - Special Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 BSC-Initiated Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 BSC-Initiated SCCP Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 BTS-Initiated Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.5 Mobile Station-Initiated Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.6 Remote Transcoder Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Preserve Call Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Normal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Abnormal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling User Traffic Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Analog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Interleaving and Forward Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Speech Data Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Digital Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.5 Digital 64 kbit/s A-law Encoded Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.6 Enhanced Full-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.7 Half-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.8 Adaptive Multiple Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.9 Channel Mode Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Circuit-Switched Data Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Non-Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 SMS-CB Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Phase 2+ Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Support of Localized Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 PLMN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 Rural and Coastal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Urban Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Concentric Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Sectored Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Standard Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Enlarged Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Umbrella Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Mini Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Microcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 Indoor Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Cell Shared by Two BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Subsystem O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 System O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 O&M Control - Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 LMTs and the IMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
181 182 183 183 188 189 189 191 193 193 196 197 198 198 199 201 202 202 203 203 203 204 204 205 206 206 209 210 210 211 212 213 213 214 215 217 218 219 219 219 220 221 221 222 222 222 223 226 227 229 230 230 232 233 233
6 / 262
Contents
8.3
8.4
8.5
8.6
8.7
8.8
8.2.2 OML Auto-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.4 Security Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O&M Control - The OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Multiple Human-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 ACO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Secured X.25 Connection From BSC to OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.4 Electronic Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.2 Logical Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.3 Software Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.4 Auto-Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.5 OML Auto-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.6 Network Element Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Management - Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.1 Alarm Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.2 Alarm Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 BSC Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.4 BTS Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.5 Alarms Detected by the TSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.6 MFS Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.7 Recovery Example: Carrier Unit Failures with BCCH . . . . . . . . . . . . . . . . . . . . . . 8.5.8 Automatic Power-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.9 BSC Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.1 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.3 Radio Measurements Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.4 Results Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.1 Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.2 Audit Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
233 234 234 234 235 236 236 238 238 239 240 240 240 242 243 244 245 246 247 250 252 252 253 255 255 256 256 257 257 258 259 259 260 261
7 / 262
Figures
Figures
Figure 1: BSS in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figure 2: Antenna Diversity on G1 and G2 BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figure 3: Antenna Diversity on the BTS A9100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 4: Transmission Components in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 5: Cell Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 6: Logical Position of External Components Associated with BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 7: Location Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figure 8: TMN System Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figure 9: General Telecommunication Layers in GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figure 10: BSS Application, Transmission Layers and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 11: Time Slot 4 of a TDMA Frame Supporting Access Grant Channels . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 12: Model LLC Packet Data Unit used in GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Figure 13: The Alcatel GPRS Solution in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Figure 14: GPRS Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figure 15: GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Figure 16: Mobile Station-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . 75 Figure 17: GGSN-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figure 18: Mobile-Originated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Figure 19: Mobile-Terminated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Figure 20: Mobile-Originating Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Figure 21: Network-Originating Packet Data Protocol Context De-activation Processes . . . . . . . . . . . . . . . . 83 Figure 22: GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Figure 23: GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Figure 24: Mobile Station-Originating GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure 25: Network-Originating GPRS Detach Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Figure 26: Generic LCS Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Figure 27: Radio and Link Establishment for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Figure 28: SDCCH Channel Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Figure 29: Immediate Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Figure 30: Connection for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Figure 31: Normal Assignment for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Figure 32: Channel Activation Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Figure 33: Channel Assignment Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Figure 34: Call Connection for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Figure 35: Radio and Link Establishment for Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Figure 36: Normal Assignment for Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Figure 37: CCCH with Three Blocks Reserved for AGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Figure 38: Four TDMA Frame Cycles Providing 24 Paging Sub-channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Figure 39: Paging Message Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8 / 262
Figures
Figure 40: Location Update with Classmark Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Figure 41: Location Update with Mobile Station Sending Location Area Identity of Previous VLR . . . . . . . 133 Figure 42: Ciphering Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Figure 43: Example of TFO Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Figure 44: Frequency Hopping within an FHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Figure 45: Different Forms of Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Figure 46: Power Control Flow of Measurement and Decision Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Figure 47: Power Output Balancing Based on Received Quality and Signal Levels . . . . . . . . . . . . . . . . . . . . 157 Figure 48: Quality and Level Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Figure 49: Better Zone Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Figure 50: Better Cell Handover (Power Budget) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Figure 51: Distance Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Figure 52: Umbrella Cell Load in Mobile Velocity Dependent Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Figure 53: Asynchronous External Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Figure 54: Mobile Station Disconnecting a Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Figure 55: Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Figure 56: Initiation of Normal Release by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Figure 57: BSC/BTS/Mobile Station Interactions in Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Figure 58: Normal Release Final Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Figure 59: Call Release Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Figure 60: Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Figure 61: BSC-initiated Call Release toward the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Figure 62: BTS-initiated Call Release following LAPD Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Figure 63: Call Release due to Mobile Station-Initiated Radio Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Figure 64: Call Release due to Communication Failure detected by Transcoder . . . . . . . . . . . . . . . . . . . . . . 197 Figure 65: Encoded Speech Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Figure 66: Multiplexed Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Figure 67: Data Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Figure 68: Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Figure 69: Example: Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Figure 70: Sectored Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Figure 71: Example of Extended Cell Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Figure 72: Umbrella Cell with Mini Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Figure 73: Example: Handovers due to Threshold Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Figure 74: Indoor Cell Example Network Hierarchy with Three Layers and Two Bands . . . . . . . . . . . . . . . . 226 Figure 75: Multiple HMI Access to OMC-Rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Figure 76: ACO Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Figure 77: X.25 Without Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Figure 78: X.25 With Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Figure 79: RSL Correlation on the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
9 / 262
Figures
Figure 80: Example: Alarm Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Figure 81: Example: Loss of Carrier Unit Holding BCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
10 / 262
Tables
Tables
Table 1: Types of Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 2: Network Subsystem Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Table 3: Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Table 4: Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Table 5: System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Table 6: GPRS System Information Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Table 7: GPRS System Information Messages Used with MPDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Table 8: Gb Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Table 9: BSCGP Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Table 10: GPRS Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Table 11: Cell Reselection Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Table 12: Network Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Table 13: Time Slot Allocation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Table 14: TBF Allocation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Table 15: PDCH Traffic Load States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Table 16: HSDS Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Table 17: Types of Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Table 18: Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Table 19: Cell List Identifier and Paging Performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Table 20: Paging Request Message and Mobile Station Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Table 21: Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Table 22: Classmark IE Field Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Table 23: Classmark Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Table 24: Mobile Station Ciphering Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Table 25: Downlink Discontinuous Transmission Status in Channel_activation . . . . . . . . . . . . . . . . . . . . . . . . 151 Table 26: Operator Discontinuous Transmission Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Table 27: Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Table 28: Mobile Station Maximum and Minimum Power Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Table 29: Target Cell Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Table 30: Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Table 31: AMR Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Table 32: Circuit-Switched Data Rate Conversions Across the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Table 33: Subsystem O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Table 34: Configuration Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Table 35: Fault Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Table 36: BTS Alarm Hardware Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Table 37: BTS Alarms Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Table 38: Performance Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Table 39: Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
11 / 262
Tables
12 / 262
Preface
Preface
Purpose
This document provides detailed descriptions of the functions and features of the Alcatel BSS. Some functions and features may not be available on the system installed at your location. The technical information in this document covers: Mobile Communications Support These areas describe how the BSS handles communications between a mobile station and the NSS. It follows a call through the Alcatel BSS, and describes how each element in the system functions individually and with other elements. This shows how the BSS and its units react as a system. Operations and Maintenance. These areas describe the O&M functions within the system. It describes both local and distributed O&M functions in a BSS.
Audience
This manual is for people requiring an in-depth understanding of the functions of the Alcatel BSS: Network decision makers who require an understanding of the underlying functions of the system, including: Network planners Technical design staff Trainers. Operations and support staff who need to know how the system operates in normal conditions, including: Operators Support engineers Maintenance staff Client Help Desk personnel.
13 / 262
Preface
Assumed Knowledge
The document assumes that the reader has an understanding of: GSM GPRS Mobile Telecommunications Network Management concepts and terminology.
14 / 262
1 Introduction
1 Introduction
This chapter gives a brief overview of the Alcatel BSS, its functions and features.
15 / 262
1 Introduction
1.1 Overview
The BSS provides radio coverage for GSM subscribers in a defined area. Its principal role is to provide and support signaling and traffic channels between mobile stations and the NSS. The following figure shows the BSS within the PLMN, and its links to the PSTN and the PSDN in a fixed network.
PLMN Mobile Stations Network Subsystem MSC TC BTS BSC MFS SGSN PSDN Fixed Network PSTN
Base Station Subsystem
Router
OMCR
AGPS server
NMC
MFS NMC PSDN PSTN SGSN
: Multi-BSS Fast Packet Server : Network Management Center : Packet Switched Data Network : Public Switched Telephone Network : Serving GPRS Support Node
Figure 1: BSS in the PLMN
1.1.1 EVOLIUM Radio Solutions

To respond to the swiftly evolving needs in BSSs, Alcatel offers the EVOLIUM Radio Solutions. The Alcatel EVOLIUM Radio Solutions includes the following BSS equipment described in this document: A9120 BSC G2 Transcoder A9125 Transcoder BTS A9100 BTS A9110 A9135 MFS.
Note:
BTS G1 and BTS G2 are still supported by EVOLIUM.
16 / 262
1 Introduction
1.1.2 Extended GSM Band (E-GSM)

The Alcatel BSS supports the E-GSM band. E-GSM consists of: The 900 MHz primary band, called the P-GSM band. This uses 890-915 MHz for uplink, and 935-960 MHz for downlink The 900 MHz extended band, called the G1 band. This uses 880-890 MHz for uplink, and 925-935 MHz for downlink. This corresponds to a total number of 174 addressable frequencies.
1.1.3 GSM 850

The GSM 850 MHz band was introduced in Release 1999 of the 3GPP Standard in 1999 to allow operators to replace progressively the D-AMPS and CDMA technologies that were using these frequencies. Besides certain Asian countries, the GSM 850 MHz band concerns in particular the Latin American countries where many operators already use the GSM system in their network with GSM 1900 MHz to extend or replace their existing D-AMPS network. The term GSM 850 is used for any GSM system which operates in the 824 MHz to 849 MHz band for the uplink direction and in the 869 MHz to 894 MHz band for the downlink direction. The GSM 850 band is defined by 124 absolute radio frequency channel numbers (ARFCN) among the 1024 ARFCNs available in the GSM standard.
1.1.4 Frequency Band Configurations

The Alcatel BSS supports the following multiband network configurations: BSS with a mix of GSM 850 and GSM 1900 cells BSS with a mix of GSM 850 and GSM 1800 cells BSS with a mix of GSM 900 and GSM 1800 cells BSS with a mix of GSM 900 and GSM 1900 cells. Refer also to the Basic GSM System Specifications.
1.1.5 GPRS
GPRS, the solution chosen by European Telecommunication Standards Institute to answer the demand for increased data transmission rates, is available in the Alcatel BSS. This means there are now two parallel systems in the PLMN: circuit-switched transmission for voice, and packet-switched transmission for data. For information on how GPRS functions in the BSS, see GPRS in the BSS (Section 2).
17 / 262
1 Introduction
1.2 BSS Functions

Functions are defined by the International Telecommunications Union and European Telecommunication Standards Institute recommendations. This section provides an overview of the BSS functions with a system-wide view; that is, how the BSS functions work together within the system. Network elements and functional units are indicated where applicable, but are not described. For more information, refer to the specific network element description manuals, such as the BTS Functional Description. The BSS provides signaling and traffic channels between the mobile station and the NSS. To ensure a high level of service to the subscribers, the BSS offers the following functions: Call Set Up Call Handling Call Release Operations & Maintenance.
1.2.1 Call Set Up

Call Set Up is used for speech and data calls. The three basic types of call are shown in the following table. Type of Call Mobility Management Description Mobility Management calls, such as location update, are used by the system to gather mobile station information. The exchanges are protocol messages only. Therefore, only a signaling channel is used.
Supplementary Supplementary service calls, such as SMS, allow the mobile Service station to send and receive messages to and from the BTS. These calls pass small amounts of information. Therefore, only a signaling channel is used. User Traffic User traffic calls, such as speech or data calls to a correspondent, can pass large amounts of information. Therefore, they require greater bandwidth than a signaling channel. These calls use traffic channels.
Table 1: Types of Call Set Up

Call set up processes include: Radio and Link Establishment to assign a signaling channel between the mobile station and the NSS Classmark handling to manage different mobile station power and ciphering capabilities Ciphering to ensure data security on the Air Interface The normal assignment process to assign a traffic channel between the mobile station and the NSS.
18 / 262
1 Introduction
See Call Set Up (Section 3) for more information.
1.2.2 Call Handling

The call handling function is used to supervise and maintain calls which are in progress. Call handling involves: In-call channel modification during a call Maintenance of call integrity and quality through features such as Frequency Hopping, Discontinuous Transmission or Radio Power Control Handover to change channels when a mobile station moves from one cell to another Handover when the quality of the current channel drops below an acceptable level Ciphering to ensure data security on the Air Interface Overload control to manage the call load on the system. See Call Handling (Section 4) for more information.
1.2.3 Call Release

The call release function ensures that resources allocated to a call are free for reuse when they are no longer required by the current call. Specifically the Call Release function includes: Call Release in normal service: Calls terminated by call management Calls terminated following a channel change. Special Cases: Call release following a reset BSC-initiated release BTS-initiated release Mobile station-initiated release. See Call Release (Section 5) for more information.
1.2.4 Operations & Maintenance

O&M provides the operator interface for the management and control of the BSS, and its interconnection to the NSS. O&M is divided into three principal areas: Configuration Management Fault Management Performance Management. See Operations & Maintenance (Section 8) for more information.
19 / 262
1 Introduction
1.3 BSS Components

There are three main units in the BSS: The BSC, which acts as the controller of the BSS. The BSC provides control of the BTSs and their resources, and performs switching functions within the BSS The BTS, which provides the radio transmission and reception functions for a cell The Transcoder, which performs rate adaptation and encoding/decoding of speech and data between the MSC and the BSC. The BSS shown in Figure 1 is supervised by the OMC-R. In a large network, one or more high-level supervisors, such as NMCs, can exist to centralize network management activities. The NMC has the authority to send directives to the OMC-R. For more information about the NMC, refer to documentation supplied with the NMC.
1.3.1 Base Station Controller

The BSC provides control of the BTSs and manages radio resources and radio parameters. From a transmission point of view, the BSC also performs a concentration function if more radio traffic channels than terrestrial channels are connected to the MSC. A single BSC can control a large number of BTSs. The exact number is a function of the BSC equipment and the configurations used. The BSC provides: Resource management Database management Radio measurement processing Channel management Operations and maintenance functions within the BSS Communication with the OMC-R Switching between the Air Interface channels (and their associated Abis channels), and the A Interface channels. Further information concerning these interfaces can be found in The A Interface (Section 1.7.4), The Abis Interface (Section 1.7.6) and The Air Interface (Section 1.7.8). The BSC also incorporates the following transmission equipment: The Base Station Interface Equipment (BSIE), which performs signaling and submultiplexing on the Abis Interface The Transcoder Submultiplexer Controller (TSC), which collects and processes transmission data. It also provides an operator interface to certain transmission functions via a Local Maintenance Terminal. For a more detailed description of the BSC, refer to the EVOLIUM BSC/TC Overall Description document.
20 / 262
1 Introduction
1.3.2 Base Transceiver Station

The BTS provides radio transmission, control and baseband functions for a cell. The BTS also supports the Air Interface with the mobile stations. Alcatel furnishes two families of BTS: BTS G1 or G2 BTS A9100 or BTS A9110. These families of BTS have different architectures, and are not functionally identical, (e.g., only the BTS A9100 or BTS A9110 can support GPRS). The BTS performs the following functions under the control of the BSC: Transmit and receive functions Antenna diversity Frequency hopping Radio channel measurements Radio frequency testing. The BTS also includes BIEs which enable it to communicate with the BSC over the Abis Interface. In the BTS A9100 and BTS A9110, the BIE is integrated into the SUM. For a more detailed description of the BTS, refer to the BTS Functional Description or the EVOLIUM BTS A9100/A910 Functional Description documents.
1.3.2.1 Antenna Diversity

Antenna Diversity is a BTS feature that protects against multipath fading. This is achieved by duplicating the receive antenna and receive path up to the Frame Unit of the BTS (or the TRE for a BTS A9100 or BTS A9110). The Frame Unit (or TRE) uses the data burst which has the fewest errors. This increases the low-power mobile station range, thereby allowing larger cells.
21 / 262
1 Introduction
1.3.2.2 G1 and G2 BTS Antenna Diversity

Antenna diversity on G1 and G2 BTSs duplicates the receive antenna and receive path up to the Frame Unit. The Frame Unit uses the data burst which has the fewest errors. This increases low-power mobile station range, thus allowing larger cells and lowering infrastructure investment. The following figure shows the antenna diversity path through the G1 and G2 BTS.
OTHER ANTENNAS
TX C O U P L I N G a a ab best of a&b b b a U N I T RX
B I E
FU
F H U
CU
RX (option)
OMU CONTROL BASEBAND CONTROL BASEBAND RADIO COUPLING
BIE CU FHU FU OMU RX TX
: Base Station Interface Equipment : Carrier Unit : Frequency Hopping Unit : Frame Unit : Operations and Maintenance Unit : Receiver : Transmitter
Figure 2: Antenna Diversity on G1 and G2 BTSs
22 / 262
1 Introduction
1.3.2.3 BTS A9100/A9110 Antenna Diversity

Antenna diversity on the BTS A9100 or BTS A9110 follows the same principle as in the G1 and G2 BTSs. The antennas are used for both transmit and receive, and the receive path is duplicated up to the TRE, providing the same gain in efficiency and low-power mobile station range. The following figure shows the antenna diversity path through the BTS A9100.
TRE 1
ab best of a&b a b a ANT a Tx / Rx a a b b
TRE 2 S U M
ab best of a&b
TRE 3
ab ab best of a&b b a
TRE 4
ab best of a&b b a
b a
b ANT b Tx / Rx
ANy
ANx
ANC
BASEBAND CONTROL BASEBAND RADIO COMBINING RADIO DUPLEXING
ANT ANx ANy SUM TRE
: Antenna : Antenna Network Type x : Antenna Network Type y : Station Unit Module : Transmitter/Receiver Equipment
Figure 3: Antenna Diversity on the BTS A9100
Note:
The configuration shown above (1 Sector, 3X4 Transceivers) is one example only. Other combinations of Antennas and TREs are possible. There is no ANy in the BTS A9110, and ANy is not needed if the sector has two TREs.
23 / 262
1 Introduction
1.3.3 Transcoder And Transmission Function

The Transcoder is the key component for the transmission function, which provides efficient use of the terrestrial links between the equipment of the BSS. In addition to the Transcoder, Submultiplexers are also used for transmission functions. The Transcoder provides: Conversion between A-law and Radio Test Equipment-Long Term Prediction encoded traffic (speech) Conversion between A-law and Algebraic Code Excited Linear Prediction encoded traffic (speech) Rate adaptation (data) O&M control of the transmission function. The Transcoder is normally located next to the MSC. The Submultiplexer performs submultiplexing on the Ater Interface, between the MSC and the BSC. When submultiplexing is used, a Submultiplexer is located at each end of the link. The following figure shows how transmission components are distributed in the BSS.
TSC OMCR
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
BTS
BIE
BIE
BSC
TC
TSC BTS
BIE SM TSC TC
: Base Station Interface Equipment : Submultiplexer : Transcoder Submultiplexer Controller : Transcoder
Figure 4: Transmission Components in the BSS
24 / 262
1 Introduction
1.3.4 The Multi-BSS Fast Packet Server

The MFS is preferably located at the Transcoder/MSC site. It is internal to the BSS and provides the following functions: PCU (Packet Control Unit) functions: PAD (packet assembly/disassembly) function Scheduling of packet data channels Automatic Retransmission Request functions Channel access control functions Radio channel management functions. The Gb Interface protocol stack. The MFS converts GPRS frames, carried on multiple 16 kb/s links from multiple BTSs, to one or more frame relay channels connected to the SGSN on the Gb Interface. See The Gb Interface (Section 2.3.1) for details. The set up of Packet Data Channels is controlled by the MFS. It also negotiates resources with the BSC and routes GPRS packets. When an additional channel is required on a BTS, the MFS asks the BSC to allocate a channel and to connect it to an Ater channel which the MFS controls. The Alcatel solution also supplies two dedicated GPRS interfaces between the MFS and the BSS: The BSCGP Interface supplies routing of GPRS messages and resource negotiation between the BSC and the MFS The GCH Interface routes user data traffic and signaling between the MFS and the BTS transparently (to the BSC). Hardware and software management of the MFS is provided using the IMT.
1.3.4.1 GPRS Processing Units

The MFS is divided into GPRS processing units (GPU) which are interconnected via an Ethernet bus and controlled by a control station. The GPU handles the O&M and telecom functions of several cells, but a cell cannot be shared between several GPUs. A GPU cannot be connected to more than one BSC, which means that each GPU cannot manage simultaneously several BSSs. Even so, the use of several GPUs per BSS is required for traffic capacity reasons. The MFS is in charge of associating each cell to a GPU. This later operation is called GPU cell mapping.
25 / 262
1 Introduction
The GPU is in charge of: O&M functions: Initialization of the MFS Software download Software configuration Performance monitoring. Telecom functions: Radio and transmission resources control Radio link control of packet connections Common control channels management MS radio resource control Logical Link Control (LLC) Protocol Data Unit (PDU) transfer Multiframe management Congestion control Gb Interface management Signaling management on the GSL Interface.
1.3.4.2 GPU Protocol Management

The GPU is split into two sub-units, the Packet Management Unit (PMU) and the Packet Traffic Unit (PTU). The protocols handled by a GPU are split in the following manner: Protocols handled by the PTU: Radio Interface protocols (RLC and MAC) GCH Interface protocols (L2-GCH and L1-GCH). The PTU manages the corresponding GCH Interface (see The GCH Interface (Section 2.3.3) for more information). Protocols handled by the PMU: Gb Interface protocols (BSSGP, Network Service, and Full Rate) BSC Interface protocols (BSCGP, L2-GSL, and L1-GSL) RRM protocol. The PMU manages the corresponding Gb and GSL interfaces.
1.3.4.3 Multi-GPU per BSS

To increase the GPRS capacity of the BSS in terms of number of PDCH, several GPU boards can be connected to the BSC to support the PCU function. This feature is applied regardless of the BTS type.
26 / 262
1 Introduction
1.3.4.4 Cell Mapping

Mapping a cell means that a cell is associated with a GPU. Remapping a cell means that a cell, already linked to a GPU, is moved to another GPU. The mapping of cells onto GPUs is performed by the MFS, which actually defines the mapping of cells onto LXPUs (logical GPU). An LXPU is either the primary GPU, or the spare GPU in the case of switchover. All the GPRS traffic of one cell is handled by only one GPU. The following figure shows an example of cell mapping.
MFS
Cell 1 Cell 4 Cell 3 Cell 5 Cell 6 Cell 7 Cell 8 Cell 12 Cell 11 Cell 10 Cell 14 Cell 13 Cell 9 Cell 2
GPU1
BSC
GPU2
GPU3
GPU4
GPU
: GPRS Processing Unit
Figure 5: Cell Mapping
1.4 Extended GSM

Two 10 MHz extended bands for GSM 900 in the range 880-890 MHz/925-935 MHz have been specified as an option on a national basis. The reason for this is mainly due to the lack of primary band frequencies in countries outside Europe. The term "G1" is used for the extended band. The term "P-GSM" is used for the primary band. The term "E-GSM" is used for the whole GSM-900 frequency band, i.e., the primary band (890-915 MHz/935-960 MHz) plus the extended band (880-890 MHz/925-935 MHz). This corresponds to 174 addressable carrier frequencies and leads to an increase of 40% against the 124 frequencies in the primary band. All BCCH frequencies and SDCCH channels are entirely supported on the GSM primary band. This allows for the support of both primary and extended band mobiles in the same network.
1.4.1 E-GSM Mobile Station Recognition

From messages sent by the mobile station, the BSS determines if a mobile supports the E-GSM band. The mobile station is determined to be E-GSM if: The FC bit of Classmark 2 is set to 1 (regardless of the value of the Band 2 bit of Classmark 3) or The FC bit of Classmark 2 is set to 0, and the Band 2 bit of Classmark 3 is set to 1. If the information is not available, the mobile station is considered as not supporting the G1 band. The BSS never triggers a Classmark Interrogation procedure to obtain the E-GSM ability of a mobile station.
27 / 262
1 Introduction
1.4.2 E-GSM Management After Initial Determination

Once the E-GSM ability has been initially determined as described above, it may happen that the mobile station radio characteristics change during a transaction. If the BSC receives a classmark change message, it takes this into account and updates the E-GSM ability according to the content of the received message.
1.4.3 E-GSM Determination at Handover

In the case of internal handover, the E-GSM ability of a mobile station is stored in the BSC memory. In the case of external incoming Handover, the handover request message includes either Classmark 1 or Classmark 2 IE, and optionally Classmark 3 IE. If Classmark 1 is present and Classmark 3 is not present or Classmark 3 is present but does not contain the Band 2 bit, the mobile station is not considered as E-GSM. If both Classmark 1 and Classmark 3 are present, and Classmark 3 contains the Band 2 bit, the BSC gets the E-GSM ability of the mobile station from Classmark 3. If Classmark 2 is present and Classmark 3 is not present, or Classmark 3 is present but does not contain the Band 2 bit, the BSC gets the E-GSM ability of the mobile station from Classmark 2 ("FC" bit). If both Classmark 2 and Classmark 3 are present, the mobile station is seen as E-GSM: If the FC bit of Classmark 2 is set to 1 (whatever the value of the band 2 bit of Classmark 3) If the FC bit of Classmark 2 is set to 0 and the band 2 bit of Classmark 3 is set to 1. After an incoming external handover, if a classmark change message has been received from the mobile station, the BSC ignores any subsequent classmark update message received from the MSC.
1.4.4 TCH Allocation

The allocation of G1 band channels can be done for Normal Assignment (NASS), Internal Channel Change (ICC), or External Channel Change (ECC). Each TRE has the capability to support the P-GSM or the E-GSM band. Each TRX is configured as a P-GSM TRX or a G1 TRX. When a TCH is needed, if it is for an E-GSM mobile station, then a TCH belonging to the G1 TRX subset is preferably chosen. If no resource is available in the G1 TRX subset, the mobile station is allocated to the P-GSM TRX subset.
28 / 262
1 Introduction
1.5 External Components

The BSS communicates with three external components: The NSS on the A Interface The mobile station on the Air Interface The OMC-R on the BSS/OMC-R Interface. The following figure shows the logical position of the External Components.
PLMN Mobile Stations BTS BTS BTS
Abis Interface
Base Station Subsystem

Ater Interface A Interface
Network Subsystem MSC
Fixed Network PSTN
Transcoder BSC MFS

Gb Interface
SGSN
GGSN
PSDN
Router
OMCR HLR
AGPS server
NMC
GGSN HLR MFS NMC PSDN PSTN SGSN
: Gateway GPRS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Network Management Center : Packet Switched Data Network : Public Switched Telephone Network : Serving GPRS Support Node
Figure 6: Logical Position of External Components Associated with BSS
29 / 262
1 Introduction
1.5.1 Network Subsystem

Managing communication within the PLMN and external networks is the primary role of the NSS. The NSS manages the subscriber administration databases. It contains these components: Component MSC Description Performs and coordinates the outgoing and incoming Call Set Up function. The MSC is a large capacity switch used for passing mobile traffic to mobile subscribers, or to subscribers of external networks. This part of the NSS interfaces with the BSS. The HLR is the central database within a given network for mobile subscriber specific data. It contains static data such as access authorization, information about subscribers and supplementary services. It also controls the dynamic data about the cell in which the mobile station is located. The VLR temporarily stores information about mobile stations entering its coverage area. Linked to one or more MSCs, the VLR transmits data to a new VLR when a mobile station changes areas. The AuC manages the security data used for subscriber authentication. The EIR contains the lists of mobile station equipment identities.
Home Location Register
Visitor Location Register
Authentication Center Equipment Identity Register
Table 2: Network Subsystem Components
30 / 262
1 Introduction
1.5.2 Mobile Stations

Mobile stations provide radio and processing functions which allow subscribers to access the mobile network via the Air Interface. Subscriber-related information is stored on a specific device called a SIM. The SIM is a removable smart-card that conforms to internationally recognized standards specified by the ISO. It contains the IMSI. This is used by the Network Operator to identify the subscriber in the network and to provide security and protection against misuse. Each mobile station has its own IMEI. The IMEI is used by the Network Operator to prevent stolen, or non-type approved mobile stations, from accessing the network. There are three types of mobile station in GSM: Phase 1 Phase 1 extended Phase 2. For information on GPRS mobile stations, refer to GPRS Elements (Section 2.1.2). Mobile stations have different capabilities according to the class of mobile station and the purpose for which the mobile station was designed. These differences include power output and ciphering. Only phase 2 mobile stations can turn off ciphering, or change the ciphering mode, during a channel change procedure such as a handover. The ciphering capability of a mobile station is signalled to the BSS in the mobile station classmark. Ciphering is used to protect information transmitted on the Air Interface. This is performed between the BTS and the mobile station (i.e., Air Interface). Transmission ciphering does not depend on the type of data to be transmitted (i.e., speech, user data, signaling), but on normal transmission bursts. See Ciphering (Section 3.8) for further information concerning mobile station ciphering capabilities.
1.5.2.1 Mobile Station Idle Mode

A mobile station is in idle mode when it is switched on, but not communicating with the network on an SDCCH or a traffic channel. The BSS supports four idle mode functions: Cell selection and cell reselection GSM/GPRS to UMTS cell reselection Location updating Overload control.
31 / 262
1 Introduction
1.5.2.2 Mobile Station Cell Selection and Reselection

A mobile station monitors the broadcast messages from the BTS. This includes monitoring the FCCH and SCH. The mobile station chooses the best cell on which to camp. If this cell is in a location area other than that stored in the mobile station memory, then the mobile station initiates a location update procedure. For a mobile station to camp on a cell, it has to synchronize with the cell. The BTS broadcasts an FCCH and an SCH at a defined time in the BCCH cycle. These channels are used as reference points for the mobile station to synchronize with the BCCH. Once synchronized, the mobile station continues to monitor these channels to stay synchronized. This type of synchronization, along with cell configuration and channel frequency information, enables the mobile station to calculate where channels occur in the multiframe sequences. Timing advance information is sent to the mobile station when an SDCCH is assigned. The mobile station uses the channel configuration information to calculate which part of the CCCH contains its paging message, and therefore which time slot to monitor for paging messages. When the mobile station is camped on a cell, it continues to monitor the BCCH transmissions from neighboring cells. The BCCH frequencies of the neighboring cells are transmitted on the BCCH of the home cell (sys_info 2). The mobile station can decide to camp on a new cell if it receives a better signal from an adjacent cell. Reasons for moving to a new cell include: A problem in the existing cell The mobile station moving. If the mobile station moves to a new cell which is in the same location area as the one currently in its memory, it does not initiate a location update. It recalculates its paging group and monitors the new paging channel. Paging messages are broadcast from all cells in a particular location area.
1.5.2.3 GSM/GPRS to UMTS Cell Reselection

The reselection of a UTRAN cell is triggered by a multi-RAT mobile station in circuit-switched idle mode, packet-switched idle mode, or packet-switched transfer mode. In NC0 mode, a multi-RAT mobile station can reselect a UTRAN cell in any GMM state. In dedicated mode, the multi-RAT mobile station follows the GSM handover procedures. The BSS then broadcasts the set of UTRAN cell parameters which allows the multi-RAT mobile station to reselect a UTRAN cell on its own.
32 / 262
1 Introduction
1.5.2.4 Location Updating

The location update procedure is always initiated by the mobile station. Location update is performed after the call has finished (cell reselection). Reasons for location updates include: A periodic update Periodic location update is performed by the mobile station after a lack of signaling activity for a specific time. If the timer expires, the mobile station initiates a location update, even if it has not changed location area. The duration of the mobile station timer is defined by the network and sent to the mobile station as system information messages on the BCCH. The time can be between six minutes and 25 hours. A handover to a cell in a new location area. When a mobile station is handed over to a cell in a new location area, there is no automatic location update in the network. A new Location Area Identity in the BCCH (sys_info 3 and sys_info 4) is detected by the mobile station when the current call has finished, and initiates the location update procedure. This saves the system performing several location updates if the mobile station is handed over several times during a call. The mobile station camps on a cell with a different location area code to the one in the mobile station memory. The mobile station initiates the location update procedure by sending a channel_request message indicating that the call is for a location update. The BSS assigns a dedicated signaling channel and establishes a signaling path between the mobile station and the MSC. See Mobile-Originated Call (Section 3.2) for more information. When a signaling path is established, the mobile station sends the Location Area Identity of the old cell on which it was camped to the MSC. The new VLR interrogates the old VLR for authentication and subscriber information. For more information, see Location Updating with Classmark Procedure (Section 3.6.3) and Authentication (Section 3.7). The Location Area Identity is made up of: Mobile Country Code Mobile Network Code Location Area Code.
33 / 262
1 Introduction
The BSS adds the cell identity of the mobile stations current location to the message sent to the MSC. This information is sent in a Mobility Management sub-layer message and is transparent to the BSS. The NSS stores this information either in its HLR or its VLR. Following a location update procedure, the VLR can assign a new Temporary Mobile Subscriber Identity (TMSI) to the mobile station. See Authentication (Section 3.7) for more information about the TMSI. The following figure shows a mobile station as it moves to a new location area.
VLR
: Visitor Location Register
Figure 7: Location Update
1.5.2.5 Overload Control

To protect itself against overload, the system can bar access to mobile stations, by changing the RACH control information in the system information messages described in Table 5. For further information, see GPRS Overload Control (Section 2.6.4) and Overload Control (Section 4.7).
34 / 262
1 Introduction
1.5.3 Phase 2 Mobile Support in a Phase 1 Infrastructure

When a phase 2 mobile station is used in a phase 1 infrastructure network, the BSS functions as phase 2 on the Air Interface and has the capability of functioning as phase 1 or phase 2, depending on the MSC capabilities. The infrastructure (BSS and MSC) remains phase 1. This conforms to updated GSM recommendations for phase 1. The problems of using phase 2 mobile stations on a phase 1 network are: The implementation rules for phase 1 are not strictly defined. Therefore some implementations cannot function with phase 2 mobiles For example, some of the spare bits in phase 1 are now used by the phase 2 protocol. However, some phase 1 infrastructures reject the message as spare bits are used. Some protocol changes in phase 2 changed or replaced a phase 1 protocol For example, power and quality measurements sent by phase 2 mobile stations have a finer range of power control, which the phase 1 infrastructure must process. Phase 2 mobile stations send some phase 2 messages even though they are in a phase 1 environment. For example, phase 2 mobile stations send either new messages or new elements in messages, which the phase 1 infrastructure could reject. This blacklists the mobile station due to an invalid protocol message for phase 1. Depending on what these messages are, the updates to the phase 1 infrastructure would accept these messages/elements. The messages can be either ignored or only partially treated. This is based on information contained in the messages or elements.
1.5.4 Operations and Maintenance Center-Radio

The OMC-R supervises one or more BSSs. It performs the following functions: Manages the BSS software versions Acts as the central repository for configuration data Manages fault and performance measurement reports Handles supervision of alarms and events Manages the MFS. The reported data is available to the operator from the OMC-Rs central database. The OMC-R only performs O&M activities. It does not perform user traffic processing or call establishment and control activities. Refer to the Operations & Maintenance Principles for more information. Operator actions via the terminal interface trigger commands throughout the BSS. The OMC-R provides object-oriented management information, and supports a Manager/Agent scheme to perform and control management activities. The terminal interface supports different user profiles with different access rights.
35 / 262
1 Introduction
1.6 Network Management

Normally the OMC-R provides all the network management and control functions required by the BSS. However, the management and control functions are proprietary to the system supplier. In keeping with International Telecommunications Union and European Telecommunication Standards Institute recommendations, the Telecommunications Management Network (TMN) model has been developed to standardize the Network Management function. Network Management is compatible with all equipment, even that of different manufacturers. Network Management is controlled from one or several NMCs.
1.6.1 Telecommunications Management Network

The ability to transfer management information across the Telecommunications Management Network environment is defined by a protocol suite, the Q Interfaces. The following figure shows the hierarchical structure of the TMN. It graphically defines the respective management responsibilities in the three main levels of the Management Information Tree (MIT). The Telecommunications Management Network is more fully discussed in the BSS/MFS and TMN Functions section of the Operations & Maintenance Principles document.
NMC Operator (Resource Management) NMC Q3 OMCR Operator (Resource and Equipment Management) OSS Network Management and Network Element Management
OMCR
Mediation Function
MFS
Network Element
Security Block (SBL) Management BTS
BSC
BSS
BTS
BTS
OSS MFS NMC
: Operation Support System : Multi-BSS Fast Packet Server : Network Management Center
Figure 8: TMN System Hierarchy
36 / 262
1 Introduction
1.6.2 Q3 Interface
Communication between the NMC and the OMC-R takes place across the Q3 Interface (see Figure 8). The Q3 protocols can be divided into: Association connection and disconnection mechanisms Message format and structure Command types. For more information on Network Management and the Q3 Interface, see the Operations & Maintenance Principles.
1.7 BSS Telecommunications Layers

The telecommunications functions of a GSM network are split into layers. These layers are split into two basic categories, Application and Transmission: The Application layer is split into sub-layers, to control: Call Management Mobility Management Radio Resource Management. The Transmission layers, which provide transmission between the various components.
Note:
These Transmission layers relate to the OSI layers, that is, the Physical Layer (i.e., Layer 1) and the Data Layer (i.e., Layer 2). The protocols used for these layers are standard. The following figure shows the general distribution of the telecommunication functions within a GSM network.
MS BTS BSC NSS CM MM RRM GSM Application Layers
TRANSMISSION
CM MM MS RRM
: Call Management : Mobility Management : Mobile Station : Radio Resource Management
Figure 9: General Telecommunication Layers in GSM
37 / 262
1 Introduction
1.7.1 Call Management Sub-layer

The Call Management sub-layer performs Call Control to establish, maintain and release calls. SMS within Call Management allows the mobile station to send and receive messages of up to 160 characters. The Supplementary Service functions are also provided to the mobile stations as part of Call Management.
1.7.2 Mobility Management Sub-layer

The Mobility Management sub-layer is used by the NSS to manage the subscriber database, including information on subscriber location and authentication. It is also used by the mobile stations to send location updates when they move to new location areas.
1.7.3 Radio Resource Management Sub-layer

The Radio Resources Management sub-layer establishes, maintains and releases stable connections between the mobile station and the MSC for the duration of a call. This includes functions such as managing the limited radio resources, to ensure high service availability. It also performs handovers when a mobile station moves during a call, or the channel quality falls below an acceptable level. RRM functions occur mainly between the mobile station and the BSC. The following figure shows the application layers, transmission layers and Interfaces of the BSS.
MS BTS BSC MSC CM MM RRM BSSAP BSSAP BSSAP GSM Application Layers
LAPDm
LAPDm
LAPD
LAPD
SCCP SS7
SCCP SS7
Layer (2)
Layer (1)
Layer (1) Layer (1)
Layer (1) Layer (1)
Layer (1)
08.60 Air Interface

BSSAP CM LAPD LAPDm Layer 1 Layer 2 MM RRM SCCP SS7 TC
TC A Interface
Abis Interface
: BSS Application Part : Call Management : Link Access Protocol on the D Channel : Link Access Protocol on the Dm Channel : Physical Layer : Data Link Transfer Layer : Mobility Management : Radio Resource Management : Signal Connection Control Part : Signaling System No. 7 : Transcoder
Figure 10: BSS Application, Transmission Layers and Interfaces
38 / 262
1 Introduction
1.7.4 The A Interface

The A Interface is used for communication between the BSC and the MSC. The connection between the BSC and MSC can be either terrestrial lines or a satellite link. The A Interface includes the: Physical Layer 1 The physical layer provides a physical connection to transport the signals. It supports a 2 Mbit/s link divided into 32 x 64 kbit/s channels by Time Division Multiplex. The actual physical link used depends on Network Operator implementation. Data Link Layer 2 Layer 2 provides the frame handling functions for the interface. It is also used to pass signaling messages using the International Telecommunications Union (ITU) SS7 protocol. This comprises the: Message Transfer Part, which provides the mechanism for reliable transfer of the signaling messages Signaling Connection Control Part, which provides the mechanism to identify transactions relating to a specific communication. Application Sub-Layer 3 RRM To transfer Layer 3 messages relating to a transaction, the SCCP uses the BSS Application Part. This is divided into two parts: Direct Transfer Application Part, which transfers messages directly between the MSC and the mobile station. These messages are not interpreted by the BSS. The BSS must read and recognize the initial message as a DTAP message. BSS Management Application Part which supports procedures between the MSC and the BSC, such as resource management and handover control. On the A Interface, the process is terminated at the BSC. Messages for the BSS, passed by the BSSMAP, are interpreted by the BSC Layer 3.
39 / 262
1 Introduction
1.7.5 The Ater Interface

The part of the A Interface between the Transcoder and BSC is known as the Ater Interface. It is a set of 2Mbit/s PCM links. Ater Mux Interface The Ater Mux Interface is the result of multiplexing four Ater Interfaces. Transcoding is a Layer 1 process, therefore the difference between the two interfaces is at the physical level. Optimized Ater Interface Mapping This feature improves efficiency on the Ater Mux PCM connection between the A9120 BSC and the G2 Transcoder. Four Ater Interfaces are submultiplexed onto the Ater Mux connection. This interconnects four Digital Trunk Controllers and four Transcoder Rate Adaption Units, achieving a 4:1 mapping. The 4:1 mapping of the A9120 BSC and G2 Transcoder allows up to 116 traffic channels.
1.7.6 The Abis Interface

The Abis Interface is used for communication between the BSC and the BTS. The Abis Interface includes: Physical Layer 1 The physical layer provides a physical connection to transport the signals. It supports a 2 Mbit/s link divided into 32 x 64 kbit/s channels by TDM. The physical link used depends on the Network Operator implementing the interface. Data Link Layer 2 The data link layer provides frame handling and signaling functions using the LAPD. This layer supports three types of signaling links: The Radio Signaling Link for signaling to the mobile station (including SMS) The O&M Link for O&M information The OML Auto-detection feature (see OML Auto-Detection (Section 8.4.5)) allows the time slot reserved for the O&M Link to be used for signaling (if there are no G1/G2 BTS on the Abis Interface). This provides for an increase in the amount of telecom traffic on the Abis Interface. The Layer 2 Management Link for the Layer 2 management functions such as frame checking and error correction. Application Layer 3: BTS Management Sub-layer The BTS management sub-layer is used for Layer 3 messages between the BSC and the BTS. Some of these messages are transparent to the BTS. These are passed directly to the mobile station using the BTS RRM sub-layer 3 on the Air Interface. Non-transparent messages include messages for radio link layer control and channel management.
40 / 262
1 Introduction
1.7.7 Satellite Links

The Abis and Ater interfaces were designed to use terrestrial transmission links. However, in developing countries the terrestrial transmission infrastructure does not exist and in many cases is difficult and costly to provide. There is also a need in the developed world to provide temporary GSM coverage for transient mobile population density increases, for example at sporting events. Using geostationary earth orbiting satellites is a simple and relatively low-cost solution to these problems. Unfortunately, there is one major drawback, transmission delay. The Geostationary orbit is located at an altitude of 35,786 km above the equator, therefore propagation delay of radio signals can vary between 119 ms at the equator to a maximum delay of 139 ms. The delay for one hop (the path from one point on earth to another point, via one satellite link) varies between 238 and 278 ms. This delay degrades speech quality, but although the degradation is worse than experienced in the PSTN, it is usable. The delay also has an effect on signaling messages. Satellite links can be used on the Abis Interface or on the Ater Interface, but not both. Modification of parameters is done from the OMC-R and propagated to the BSC and the concerned BTSs. A new connection type parameter is associated with each Abis link. The operator can set the parameter at Abis creation time. If the satellite link is made using the Ater Interface, the new connection type parameter associated with the Ater as a whole is used. Both Abis and Ater connection types can be either terrestrial or via satellite. The default value for each is terrestrial.
Note:
This is not a standard GSM feature and Alcatel cannot guarantee the performance because there are so many unknown factors, such as error rate and mobile population variations, which have significant effects because of the delay.
1.7.7.1 Abis Interface Using Satellite Links

This feature is available only for EVOLIUM BTSs and later. When the link is installed on the Abis Interface, for those BTS where the satellite link is installed, the following features are not available: Closed multidrop PCM synchronization (the BTS must be configured as free running). Synchronous handovers, fax and data (in circuit-switched mode, transparent and not transparent), are supported.
1.7.7.2 Ater Interface Using Satellite Links

On the Ater Interface, the satellite link can be installed either on the Ater (between the BSC and the Transcoder), or on the A Interface (between the Transcoder and the MSC). Because this latter case is rare, the wording Ater is used for both cases. When only some of the time slots are routed via the satellite, at least the Qmux and the X.25 (if the satellite link is on the A Interface) must be routed. Channels that are not routed must be blocked, either from the MSC or from the OMC-R. If only one link is forwarded, there is no longer redundancy on the following: SS7, X.25, and Qmux.
41 / 262
1 Introduction
1.7.8 The Air Interface

The Air Interface is the radio interface between the BTS and the mobile station. The Air Interface includes: Physical Layer 1 Data Link Layer 2 RRM sub-layer 3 of the application layer.
1.7.8.1 Air Interface Layers

The Air Interface layers are described below. Physical Layer 1 is a radio link where channels are divided by time and frequency Data Link Layer 2 provides frame handling and signaling functions, using a modified version of the LAPDm Application Sub-Layer Radio Resources Management. On the Air Interface, most of the Layer 3 messages are transparent to the BTS. The BTS uses Layer 3 to extract certain information from some messages before passing on the equivalent message. For example, when the BTS receives an encryption_command message from the BSC, it reads the Ki value and the algorithm to be used, before passing on the cipher_mode_command message. This procedure is explained in detail in Ciphering (Section 3.8)
1.7.8.2 Air Interface Channels

The Air Interface is divided by frequency and time, using Frequency Division Multiplex Access (FDMA) and Time Division Multiple Access (TDMA). This provides frames of eight time slots for each frequency supported by the cell. The channels of the cell are then assigned to specific time slots within the TDMA frames. GPRS traffic uses the same radio resources as circuit-switched traffic, and is carried on the same type of physical channel. Refer to GPRS in the BSS (Section 2) for information on GPRS channels. However, not all channels require the full capacity of a time slot at each occurrence of a frame. Channels are configured to share time slots by only using certain occurrences of the frame. The cycle of frame occurrences is known as a multiframe. A multiframe can be 26 or 51 occurrences of a frame, depending on the channels configured within it. Within a multiframe, the same physical channel can support more than one logical channel.
42 / 262
1 Introduction
The following figure shows time slot four of a TDMA frame supporting Access Grant Channels.
A G C H A G C H A G C H A G C H A G C H
Frame 1
Frame 2
Frame 3
Frame 4
Frame 5
AGCH
: Access Grant Channel
Figure 11: Time Slot 4 of a TDMA Frame Supporting Access Grant Channels
Channels can be divided into traffic channels and control channels.
1.7.8.3 Traffic Channels

A traffic channel can be used for speech or data. The Alcatel BSS supports the following types of traffic channels. Traffic Channel Speech Types
Full-rate speech traffic channel Enhanced full-rate speech traffic channel Half-rate speech traffic channel.
Data
Full-rate data traffic channel (9.6 Kbit/s) Full-rate data traffic channel (4.8 Kbit/s) Half-rate data traffic channel (4.8 Kbit/s) Full-rate data traffic channel (<2.4 Kbit/s) Half-rate data traffic channel (<2.4 Kbit/s).
Table 3: Traffic Channels
43 / 262
1 Introduction
1.7.8.4 Control Channels

CCHs control communications between the BSS and the mobile stations. The four types of CCH are described below. Control Channel BCCH Description
The BCCH broadcast cell information to any mobile station in range. Three channels use the BCCH time slot: FCCH: used on the downlink for frequency correction of the mobile station with the BTS SCH: used on the downlink for frame synchronization of the mobile station with the BTS BCCH: used to broadcast system information to the mobile stations on the downlink, to give the cell configuration, and how to access the cell.
CCCH
The CCCH communicate with mobile stations in the cell before a dedicated signaling channel is established. Three channels use the CCCH time slot: RACH: used on the uplink by the mobile station for initial access to the network PCH: used on the downlink for paging messages to the mobile station AGCH: used on the downlink to give the mobile station access information before a dedicated channel is assigned.
DCCH
The DCCH pass signaling information for a specific mobile station transaction. Two channels use the DCCH time slot: SDCCH: used for signaling and short message information CBCH: uses an SDCCH channel for Short Message Service - Cell Broadcasts.
ACCH
The ACCH pass signaling information for a specific mobile station transaction. An ACCH channel is always associated with a traffic channel. Two channels use the ACCH time slot: FACCH: associated with a traffic channel, and can steal slots out of 24 or 26 slots which are normally dedicated to the traffic channel for signaling purposes as well as the SACCH slot. SACCH: associated with a traffic channel, which uses one out of 26 slots for signaling purposes.
Table 4: Control Channels
44 / 262
1 Introduction
1.7.9 System Information Messages

System information messages transmit information about the cell to the mobile station. There are six system information messages. Four are sent on the BCCH as a general broadcast to any mobile stations in the cells, and two are sent on the SACCH to mobile stations in communication with the BSS. System information messages 2 and 5 have several variations to avoid compatibility problems with phase 1 mobile stations. The following table shows the system information messages, the channel on which they are transmitted and the type of information in each. Message Sys_info 1 Channel BCCH Information Cell channel description RACH control information. Sys_info 2 BCCH Neighbor cell BCCH frequency list Indication of which Network Color Code it is allowed to monitor RACH control information. Sys_info 2bis (multiband systems only) BCCH Extended Neighbor cell BCCH frequency list in the same band as the serving cell. This message is only sent if Sys_info 2 is not sufficient to encode all available frequencies. RACH control information. Spare bits Sys_info 2ter (multiband systems only) BCCH Extended Neighbor cell BCCH frequency list in different band as serving cell. The minimum number of cells, if available, to be reported in each supported band in measurement results. RACH control information. 3G cell description. Spare bits
45 / 262
1 Introduction
Message Sys_info 3
Channel BCCH
Information Cell Identity Location Area Identity Control channel description Cell options: Power central information Discontinuous Transmission (mechanism) information Radio link time out. Cell selection parameters: Cell reselect hysteresis for Location Area reselection Maximum transmit power allowed in cell Additional reselection parameter Allows/forbids new establishment causes (phase 2 mobile stations) Minimum receive level to access cell. RACH control information Spare bits setting flags and timers.
Sys_info 4
BCCH
Location Area Identity. Cell selection parameters: Cell reselect hysteresis for Location Area reselection Maximum transmit power allowed in cell Additional reselection parameter Allows/forbids new establishment causes (phase 2 mobile stations) Minimum receive level to access cell. RACH control information CBCH channel description CBCH Mobile Allocation Spare bits setting flags and timers.
Sys_info 5 Sys_info 5bis (multiband systems only)
SACCH SACCH
Neighbor cell BCCH frequency list. Extended Neighbor cell BCCH frequency list. This message is only sent if: The serving cell is a GSM 1800 cell and Sys_info 5 is not sufficient to encode all GSM 1800 neighbor frequencies The serving cell is a GSM 900 cell, and The mobile station is phase 2, and There are neighboring GSM 1800 cells, and Sys_info 5ter is not sufficient to encode all of the GSM 1800 cells.
46 / 262
1 Introduction
Message Sys_info 5ter (multiband systems and phase 2 mobile stations only) Sys_info 6
Channel SACCH
Information Extended Neighbor cell BCCH frequency list in different band as serving cell. The minimum number of cells, if available, to be reported in each supported band in measurement results.
SACCH
Cell Identity Location Area Identity Cell options: Power control information Discontinuous Transmission information Radio link time out Indication of which Network Color Code it is allowed to monitor.
Sys_info 7 and 8
BCCH
SI 7 Rest Octets SI 8 Rest Octets SI 4 Rest Octets_S LSA Parameters LSA ID information LSA identity
Sys_info 13
BCCH
SI 13 Rest Octets without PBCCH configured in the cell: SI 13 Rest Octets GPRS Mobile Allocation GPRS cell options GPRS Power Control parameters. SI 13 Rest Octets with PBCCH configured in the cell: SI 13 Rest Octets GPRS Mobile Allocation PBCCH description.
Sys_info 16 and 17
BCCH
SI 16 Rest Octets SI 17 Rest Octets LSA Parameters LSA ID information LSA identity
Table 5: System Information Messages
47 / 262
1 Introduction
1.7.10 Dynamic SDCCH Allocation

Dynamic SDCCH allocation is a specific time slot used for signaling (SDCCH) or for traffic (TCH), depending on the overload. The operator configures: A set of static SDCCH/x time slots to handle normal SDCCH traffic A set of dynamic SDCCH/8 time slots, used for TCH traffic, or for SDCCH traffic The general principles for dynamic SDCCH are: Automatic allocation of SDCCH/8 time slots (minimum and maximum) on a cell basis Only SDCCH/8 time slots are concerned. It is not necessary to add or delete a SDCCH/3, or a SDCCH/4, or a SDCCH/7 time slot The set of static SDCCH/x and dynamic SDCCH/8 time slots represents the maximum number of allocatable SDCCH time slots The static SDCCH/8 time slots cannot be used for TCH purposes The dynamic allocatable SDCCH/8 time slots are allocated for SDCCH when all the static SDCCH/8 time slots are busy A TCH call cannot free a time slot for SDCCH/8 allocation A TCH is preferably not allocated dynamic SDCCH/8 time slots.
48 / 262
2 GPRS in the BSS
2 GPRS in the BSS

GPRS in the BSS provides an introduction to GPRS and describes: Packet Switching GPRS Elements GPRS Channels and Interfaces GPRS Network Functions GPRS Data Transmission.
49 / 262
2 GPRS in the BSS
2.1 Overview
The success of GSM has taken place in parallel with the explosion of interest in the Internet and related data services. Presently, data transmission over the Air Interface is limited to 9.6 kb/s, too slow for use of graphic-intensive services such as the World Wide Web and personal video conferencing. In addition, the circuit-switched method used for data transmission makes inefficient use of radio resources, which are under increasing pressure from the growth in GSM subscribers and use. The solution chosen by the European Telecommunication Standards Institute for the double challenge of increased demand for data service and pressure on radio resources is called General Packet Radio Service. The European Telecommunication Standards Institute recommendations establish a standard for inserting an alternative transmission method for data in the PLMN: packet switching instead of circuit switching. The Alcatel GPRS solution follows the ETSI GSM phase 2+ recommendations closely.
2.1.1 Packet Switching

In circuit switching, a connection is established and maintained during the entire length of the exchange, whether data is being transmitted or not. Resources are dedicated to a single end-to-end connection, and a radio channel in a cell, with its associated transmission channels, may be unavailable for use even when little or no information is passing across it at a given moment. In packet-switched systems, data is transmitted over virtual circuits, which exist only while data is actively being transmitted over them. This means that during idle time, time slots can be used for carrying other data. Packet-switching systems operate according to the following general procedures: 1. The PAD function disassembles data into "packets" of a predefined size. 2. The PAD encloses the packets in a data envelope (headers and footers). This data envelope includes information about origin and destination points, and the order in which the packets contents are to be reassembled at the destination. The figure below shows a model of a GPRS Packet Data Unit at the LLC layer. 3. Packets move from origin to destination point by different routes and can arrive at the destination in a different order than that in which they were sent.
50 / 262
2 GPRS in the BSS
4. At the destination, another PAD reads the envelope information, strips it off, and reassembles the data in the proper order.
Header Address Control Field Field DATA
Information Field
Footer
FCS
ENVELOPE
Address Field Contains: Protocol discriminator Command/response SAPI (mobility management, QoS, SMS)
FCS SAPI : Frame Check Sequence
Control Field 4 possible types: Confirmed information transfer Supervisory functions Unconfirmed information transfer Control functions
: Service Access Point Indicator
Figure 12: Model LLC Packet Data Unit used in GPRS

Examples of packet-switching protocols include X.25 and Internet Protocol. Since GPRS is compatible with these widely used protocols, it is suitable for access to public or custom packet data services, or to the Internet. Mobile telephones using packet data services must be connected to a portable computer or an electronic organizer.
2.1.2 GPRS Elements

The different elements shown in the figure below represent a parallel system to the circuit-switched system used in GSM until now.
To Public Data Networks
MS
OMCR Gb FRDN Gb Packet Switched Traffic
SGSN
GGSN
BSS
BTS GCH BTS Abis BSC GCH BSCGP Transcoder Ater MSC/ VLR Circuit Switched Traffic MFS
To PSTN
GCH
BSCGP FRDN GCH GGSN MFS PSTN SGSN VLR
: BSC GPRS Protocol : Frame Relay Data Network : GPRS Channel : Gateway GPRS Support Node : Multi-BSS Fast Packet Server : Public Switched Telephone Network : Serving GPRS Support Node : Visitor Location Register
Figure 13: The Alcatel GPRS Solution in the PLMN

In the Alcatel solution, the MFS with its associated interfaces is the BSS element. All other components are external to the BSS.
51 / 262
2 GPRS in the BSS
The following internal and external components are described in this chapter: GPRS mobiles The Serving GPRS Support Node The Gateway GPRS Support Node The Multi-BSS Fast packet Server.
2.1.2.1 GPRS Mobiles

There are three classes of GPRS-capable mobile stations: Class A, Class B, and Class C. Currently, only class B and C mobile stations are supported. Class A Class A mobile stations can handle circuit-switched voice and GPRS traffic simultaneously. Class B Class B mobile stations can be IMSI attached and GPRS attached at the same time, but use only one service (circuit switched or packet switched) at a time. A GPRS-attached class B mobile station can initiate an IMSI connection and suspend its GPRS service in the following cases: When the user is not engaged in any GPRS data transfer, and either: A mobile station-originated call is initiated The mobile station receives a mobile-termination call. When the user is engaged in a GPRS session (e.g., an Internet session), and either: A mobile station-originated call is initiated The mobile station receives a mobile-termination call. The mobile station performs a LAU procedure in network mode II or network mode III. Class C Class C mobile stations can be either IMSI-attached or GPRS-attached, but not both, and can use circuit-switched or GPRS services alternately.
52 / 262
2 GPRS in the BSS
2.1.2.2 The Serving GPRS Support Node

The SGSN is a GPRS network entity at the same hierarchical level as the MSC. It is external to the BSS and communicates with it via Frame Relay over the Gb Interface. The SGSN is involved in requesting specific network resources for GPRS traffic. It performs GPRS paging, authentication, and cipher setting procedures based on the same algorithms, keys and criteria as in circuit-switched GSM traffic. When a mobile station wants to access GPRS services, it makes its presence known to the network by performing a GPRS Attach procedure. This establishes a logical link between the mobile station and the SGSN. The mobile station is then available for SMS over GPRS, paging from the SGSN, and notification of incoming GPRS data. The SGSN also participates with other network elements in the routing and relaying of packets from one node to another. One SGSN can be connected to many MSCs and many MFSs.
2.1.2.3 The Gateway GPRS Support Node

The GGSN is connected with SGSNs via an IP-based backbone. It provides interworking between the GPRS network and external packet-switched networks. It is external to the BSS. When the mobile station sends or receives GPRS data, it activates the Packet Data Protocol address that it wants to use. This has the effect of making the mobile station known to the GGSN. User data is transferred transparently from the mobile station and external data systems by the GGSN using encapsulation and tunnelling. This allows data packets equipped with GPRS-specific protocol information to be transferred between the mobile station and GGSN. This reduces the requirement for the GPRS system to interpret external data protocols. The GGSN also works with other network elements in the routing and relaying of packets from one node to another.
2.1.2.4 The Multi-BSS Fast Packet Server

See The Multi-BSS Fast Packet Server (Section 1.3.4) for details of the MFS.
53 / 262
2 GPRS in the BSS
2.2 GPRS Channels and System Information Messages

GPRS traffic uses the same radio resources as circuit-switched traffic, and is carried on the same type of physical channel. When a physical channel is allocated to carry packet logical channels (using TDMA frames, as does circuit-switched traffic), it is called a Packet Data Channel, or PDCH.
2.2.1 MPDCH Handling

Both primary and secondary Master PDCHs are static. The number of MPDCHs is determined by the operator, the MPDCHs are established on the BCCH TRX.
2.2.2 Master Channels

Master Channels are packet channels that carry Packet Broadcast Control Channel (PBCCH) only on the MPDCH, the Packet Common Control Channel (PCCCH), the Packet Data Traffic Channel (PDTCH) and the Packet Associated Control Channel (PACCH). PDTCH and PACCH are not supported by the MPDCHs (i.e., no data on the MPDCHs). They allow: More performance packet services to be offered through: Enhanced cell reselection by using optimized cell reselection criteria Optimized system information reception (the mobile station does not interrupt its data transfer to acquire or refresh system information from serving and neighbor cells) Faster TBF establishment (through dedicated PCCCH channels and multislot TBF allocation in one phase). GPRS signaling traffic to be placed on dedicated PCCCH channels. This prevents CCCH channel congestion, and thus degradation of the quality of the circuit-switched services, even at a low level of GPRS traffic (e.g., cells where the signaling induced by the circuit-switched services is already high, or cells at the border of a Location Area). Multiple MPDCHs may be required in case of an increase in the GPRS traffic in the cell.
2.2.3 Static Allocation

A dedicated O&M parameter allows the operator to configure the primary MPDCH. Only a primary MPDCH can be configured for static allocation. The primary MPDCH is permanently established in the cell even if there is no GPRS traffic. This is useful if the operator wants the mobile station to perform autonomous cell reselection based on the C31 and C32 parameters, or if the paging load is high, independent of the GPRS traffic.
54 / 262
2 GPRS in the BSS
2.2.3.1 GPRS Primary Master Channel

This feature can be enabled on a per cell basis. When there is a MPDCH in a cell, it is established as soon as GPRS is supported in the cell and is kept even if there is no GPRS traffic. The GPRS Primary Master Channel is a Packet Data Channel (PDCH) carrying the Packet Broadcast Control Channel (PBCCH) to broadcast GPRS system information in the cell and the Packet Common Control Channel (PCCCH) providing GPRS-specific control channels. When there is a GPRS Primary Master Channel in a cell, the Alcatel BSS broadcasts its channel description on the BCCH. Mobile stations can monitor the broadcast and thus receive all GPRS-specific system information pertaining to the cell. The Primary Master Channel is mandatory when the Optimized Access on CCCH feature is not used. There can be at most one Primary Master Channel in a cell. The Primary Master Channel feature allows the operator to set a primary Master Channel and to benefit from the following advantages, on a per cell basis: More complete GPRS system information is broadcast, which enhances the overall performance of the network. For example, the permanent broadcast of C31 and C32 criteria enhances cell reselection for all GPRS-attached mobile stations Better performance in a GPRS network by reducing the load on the CCCH Shortened access time for multislot mobile stations A faster paging cycle Higher radio resource efficiency due to the flexibility in the mapping of logical channels onto the physical channels.
2.2.3.2 GPRS Secondary Master Channel

The GPRS Secondary Master Channel is a Packet Data Channel (PDCH) carrying the Packet Common Control Channel (PCCCH) providing GPRS specific control channels. In addition to the Primary Master Channel, one or several Secondary Master Channels can be allocated in the cell. The secondary master PDCH are always established or released in the cell. The feature provides the operator with the following improvement: increase the GPRS signaling capacity as the traffic load increases in the cell.
55 / 262
2 GPRS in the BSS
2.2.4 Multiple PCCCH

To allow an increase in GPRS traffic and its associated signaling, more than one MPDCH is required. A secondary MPDCH is required to handle the increase in signaling. The following logical channels can be multiplexed on one MPDCH: PBCCH and PCCCH. The MPDCH carrying the PBCCH is the primary Master PDCH. The PBCCH carrier is indicated on the BCCH (in the SI 13 message). Up to four MPDCH can be allocated in a cell (one primary MPCCH, three secondary MPDCH). The additional MPDCH are secondary Master PDCH. When the primary MPDCH is activated, the BSC broadcasts the SI 13 message with PBCCH radio configuration. When the primary MPDCH is de-activated (always decided by the MFS even following a fault, e.g., TRX recovery impacting the MPDCH), the SI 13 message no longer contains a PBCCH description. Paging and assignment messages are routed either on the CCCH or PCCCH depending on MPDCH presence. The MPDCHs are established on the BCCH TRX. The following table describes the parameters that can be defined by the operator. Parameter Name BS_PBCCH_BLKS Definition Coded on 2 bits: 00=Block B0 used for PBCCH 01=Blocks B0 and B6 used for PBCCH 10=Blocks B0, B6, and B3 used for PBCCH 11=Blocks B0, B6, B3, and B9 used for PBCCH Type Number Mandatory Rules If: BS_PBCCH_BLKS=1 then PSI_REPEAT_PERIOD > 3. If: BS_PBCC H_BLKS > 1 then PSI_REPEAT_PERIOD > 4/BS_PBCC H_BLKS.
BS_PAG_BLKS _RES
Number of blocks allocated to the PAGCH or PDTCH or PACCH per 52 multiframe. Number of static PRACH blocks. Number of dynamic PRACH blocks.
Number
None.
BS_PRACH_ BLKS BS_PRACK_ BLKS_MAX
Number
BS_PRACH_BLKS <= BS_PRACH_BLKS_MAX BS_PRACH_BLKS_MAX >= BS_PRACH_BLKS S/(16 * BS_PRAC H_BLKS_ MAX) > round_trip_delay.
Number
56 / 262
2 GPRS in the BSS
2.2.5 Logical Channels

The types of logical channels which can be carried on a PDCH are the: Packet Traffic Channel This channel is analogous to a circuit-switched traffic channel, and is used for user data transmission and its associated signaling. It has two sub-channels: Packet Data Traffic Channel which contains the user data traffic Packet Associated Control Channel (bi-directional) which contains the signaling information. If multiple PDTCHs are assigned to one mobile station, the PACCH is always allocated on one of the PDCHs on which PDTCHs are allocated. The function of these sub channels is analogous to their circuit-switched counterparts. Packet Timing Advance Control Channel. This bi-directional channel is used for maintaining a continuous timing advance update mechanism.
2.2.6 Virtual Channels

Packet switching is a mode of operation adapted to transmission of "bursty" data - that is, data which comes in intense "bursts" separated by periods of inactivity. The network establishes a connection during the transmission of such a "burst" of data. If there is no activity on this connection, the connection is taken down. When the original user needs to send or receive another burst of data, a new temporary connection is set up. This can be on another channel in the same cell, or in another cell if the mobile station is in motion. The routing of one burst of data may be different from the routing of another. The establishment and disestablishment of temporary connections is transparent to the user. The user sees an exchange of data that seems to be a continuous flow, unless the network is over congested. This semblance of continuous flow is a Virtual Channel. A virtual channel can be represented as the flow of data between two terminals during a user session. The user has the impression of a single continuous connection, but in the network, this is not the case. A single data transfer, either in the uplink or in the downlink direction, can pass between the MFS and the mobile station via one or more PDCH. A PDCH is shared between multiple mobile stations and the network. It contains asymmetric and independent uplink and downlink channels.
57 / 262
2 GPRS in the BSS
2.2.7 System Information Messages

GPRS system information messages, like their GSM counterparts, transmit information about the cell to the mobile station. GSM BCCH messages, shown in Table 5, are also used in GPRS. In addition, GPRS also uses the messages shown in the following tables. Message SI 13 Channel BCCH Information The SI 13 message is sent on the BCCH and contains all the necessary information required for GPRS. It also indicates the presence and the location of the PBCCH in the serving cell. The SI 13 message is broadcast only if GPRS is supported in the cell.
Table 6: GPRS System Information Message

Also, when an MPDCH exists, the messages shown in the following table are used. Message PSI 1 Channel PBCCH Information The PSI 1 message is sent on the PBCCH and gives information on: Cell selection Control of the PRACH Description of the control channels Description of power control parameters. To reduce the possibility that a mobile station involved in a data transfer has to re-read the PBCCH, the PSI 1 message is also broadcast on PACCH/D of a mobile station in packet transfer mode: When one of the packet system information messages has been modified Every T_PSI_PACCH seconds. PSI 2 PBCCH The PSI 2 message is sent on the PBCCH in several instances (up to eight) in order to give information on: Reference frequency list Cell allocation GPRS mobile allocation PCCCH channel description Non-GPRS cell options applicable to circuit-switched access Cell identification. If the PSI 2 message is modified, the new PSI 2 message is also broadcast on the PACCH/D of a mobile station that is in packet transfer mode.
58 / 262
2 GPRS in the BSS
Message PSI 3/3bis/3quater
Channel PBCCH
Information The PSI 3/3bis messages are sent on the PBCCH in several instances (up to 16) in order to give information on: BCCH allocation in the neighbor cells. The list of BCCH frequencies is then called the BA(GPRS) list. Cell selection parameters for the serving cell and the neighbor cells Localized Service Area (LSA) identification of the serving cell and of the neighbor cells for the SoLSA feature. Up to 32 neighbor cells can be defined by the PSI 3/3bis messages. In order to reduce the number of PSI 3/3bis instances, the coding of the PSI 3/3bis messages is optimized by compressing the redundant parameters. PSI 3quater is used to describe 3G cells for 2G to 3G cell reselection.
PSI 8
PBCCH
The PSI 8 message is optionally sent on the PBCCH to give information on the configuration of the cell broadcast channel (CBCH).
Table 7: GPRS System Information Messages Used with MPDCH
59 / 262
2 GPRS in the BSS
2.3 GPRS Interfaces

New interfaces have been introduced for GPRS needs. These interfaces link the MFS and the SGSN, the BTS, and the BSC.
2.3.1 The Gb Interface

The Gb Interface uses frame relay techniques to link the PCU function of the MFS and the SGSN. Physically, it can be routed in a variety of ways: A direct connection between the MFS and the SGSN Via a public Frame Relay Data Network Via the MSC Via the Ater Mux Interface through the Transcoder to the MSC. In this case it carries a combination of packet-switched and circuit-switched traffic and signaling. Combinations of these methods are also possible. See Figure 13 for the position of the Gb Interface in the system. The Gb Interface provides end-to-end signaling between the MFS and the SGSN, and serves as the BSS-GPRS backbone. Its principal functions are shown in the following table. Function Network services Description Transfer of BSSGP-PDUs between the BSS and the SGSN Allocation and load sharing of PDUs among Virtual Channels Access to intermediate Frame Relay Data Network BSS-GPRS Protocol services Radio resource information Quality of Service Information Routing information Transfer of LLC-PDUs between the BSS and the SGSN Suspend and Resume procedures for class B mobile stations
Table 8: Gb Interface Functions
60 / 262
2 GPRS in the BSS
2.3.2 The BSCGP Interface

The BSCGP Interface provides communication between the BSC and the MFS (see Figure 13). The BSC GPRS Protocol controls two LAPD connections (for redundancy) using 64 kb/s time slots. The following information is carried on the BSCGP Interface. Function Common radio signaling Description Circuit-switched and packet-switched paging (MFS to BSC) Channel Requests from BSC to MFS Uplink and downlink channel assignment (MFS to BSC) GPRS radio resource management Allocation/de-allocation of resources (MFS to BSC) Release indication (BSC to MFS) Load indication: this limits the allocation for GPRS traffic (BSC to MFS)
Table 9: BSCGP Interface Functions
Note:
The common radio signaling functions of the BSCGP are handled on the GPRS Signaling Link, which is carried inside the Ater Interface.
61 / 262
2 GPRS in the BSS
2.3.3 The GCH Interface

The GCH Interface provides a synchronous connection between the MFS and the BTS, using one to five 16 kb/s time slots. The GCH links pass transparently through the BSC (see Figure 13). Its functions are as follows: Transfer of PDUs between the MFS and the BTS. (Thus packet data is not directly handled by the BSC but passes transparently through it on the GCH Interface.) Synchronization with the radio interface at GCH link establishment Correction of clock drifts between Abis and BTS clocks. The protocol for the GCH Interface uses the two layers described below: L1-GCH Layer L1-GCH is the physical layer based on ITU-T recommendations G.703. The L1-GCH layer uses digital transmission at a rate of 2048 kbit/s with a frame of 32 x 64 kbit/s time slots. An L1-GCH channel has a transmission rate of 16 kbit/s. L2-GCH Layer L2-GCH is the data link layer which is an Alcatel proprietary protocol. This layer is in charge of the data transfer of the GCH frames between the MFS and the BTS. The L2-GCH layer offers a service of data transport for the RLC/MAC layers located in the MFS. Its main functions are: GCH link establishment and release Synchronization with the radio interface RLC/MAC PDUs transfer. The BSC connects one to five Abis terrestrial channels (identified by the corresponding radio time slot) to one to five Ater terrestrial channels upon request from the MFS. This connection is called an EGCH channel, which is controlled by the GCH layer in the BTS and in the MFS. An EGCH is made up of one to five GCHs (one main GCH and n-1 auxiliary GCHs). The main GCH uses the basic 16k Abis nibble. The following principles of dynamic transmission management are implemented: PDCHs are established with the maximum number of GCHs regardless of the supported traffic Unused GCHs, according to the supporting traffic, are released when there is Ater congestion In case of GPRS TBF allocation, PDCHs are established with a reduced number of GCHs during the Ater congestion state. For more information on GSM transmission, refer to Call Set Up (Section 3).
62 / 262
2 GPRS in the BSS
2.3.4 Specific LCS Interfaces

For LCS, the following specific interfaces are used: SAGI Supports the exchange of messages between SMLC and the external GPS server following an Assisted GPS positioning request in the circuit-switched domain RRLP(BSCLP) Supports the exchange of messages between BSC and the SMLC (i.e., MFS) in the circuit-switched domain.
2.4 GPRS Network Functions

This section describes various GPRS-specific network functions necessary for successful packet data transfer. This includes paging, cell reselection, error checking and re-establishment, as well as radio power control and link measurement.
2.4.1 MAC and RLC Functions

Since multiple mobile stations can be competing for the same physical resource(s), an arbitration procedure is necessary. This is provided by the Medium Access Control function. The MAC function operates between the MFS and the mobile station, and works in conjunction with the Radio Link Control function. Radio Link Control defines the procedures for retransmission of unsuccessfully delivered data blocks (error correction) and for the disassembly and reassembly of PDUs.
2.4.2 Temporary Block Flow

When PDUs need to be transferred between the MFS and the mobile station, a temporary point-to-point physical connection is set up to support the unidirectional transfer of PDUs on one or more PDCHs. This connection is called a Temporary Block Flow (TBF). A TBF is maintained only for the duration of the data transfer. The TBF is allocated radio resources on one or more PDCHs and comprises a number of RLC/MAC blocks carrying one or more PDUs. A typical user session, in which data is exchanged bi-directionally, requires the establishment of one TBF in each direction. The path of each TBF can be different.
63 / 262
2 GPRS in the BSS
2.4.3 Mobility Management

The GPRS Mobility Management (GMM) activities related to a GPRS subscriber are characterized by the following states: State Idle Description In idle mode, the subscriber is not attached to the GPRS MM and therefore not known to the different GMM entities. The GMM context holds no valid location or routing information for the subscriber. When the mobile station starts the GPRS attach procedure, the mobile station enters the GMM Ready state to request access to the network. When the GMM Ready timer expires or is de-activated by the network, the mobile station returns to GMM Standby state.
GMM Ready
GMM Standby
Table 10: GPRS Mobility Management States
2.4.3.1 Cell Reselection Modes

Network-controlled reselection modes are defined below. Mode NC0 Description A GPRS mobile station performs autonomous cell reselection without sending measurement reports to the network. A GPRS mobile station performs autonomous cell reselection. Additionally, when it is in the GMM Ready state, it periodically sends measurement reports to the network. A GPRS mobile station in GMM Ready state does not perform autonomous cell reselection. When in GMM Ready state, it sends measurement reports to the network that controls the cell reselection.
NC1
NC2
Table 11: Cell Reselection Modes
64 / 262
2 GPRS in the BSS
2.4.3.2 Error Checking

Since the integrity of the data transmitted is crucial, packet-switched networks employ a method of error checking. This confirms that the data received correspond exactly to the data transmitted. In GPRS, an LLC-PDU includes a Frame Check Sequence used to detect errors in the header and information fields of the PDU (see Figure 12). The Frame Check Sequence uses the Cyclic Redundancy Check method of error checking. Most of the mobile stations use non-acknowledged LLC transmission (which can raise some issues with TCP). Error detection is done at RLC level. In case of cell reselection, the Alcatel BSS retransmits the last LLC-PDU if all its RLC blocks were not acknowledged.
2.4.3.3 Mobility Management Process

Mobility Management in GPRS can be accomplished by the combination of autonomous cell reselection by the mobile station and packet error correction. The process is as follows: 1. The mobile station performs an autonomous cell reselection. The process is based on average measurements of received signal strength on the BCCH frequencies of the serving cell and the neighbor cells as indicated in the GPRS neighbor cell list. This refers to NC0. The cell reselection procedure is the same as for circuit-switched traffic, but based on GPRS reselection parameters configurable by the operator. If the cell does not have a PBCCH, the mobile station applies existing circuit switching parameters using the BCCH. 2. Once the mobile station is camped on the new cell, the data transfer is resumed. If an LLC-PDU has not been correctly received, it is re-emitted. This process produces a slight overhead on throughput but has the advantage of greatly simplifying the cell change process.
2.4.3.4 Link Re-establishment

If the mobile station detects a radio link failure, it will re-establish the link with the SGSN. The BSS transmits the reselection configuration parameters to be used by the mobile station. Mobile-controlled reselection is equivalent to circuit-switched call re-establishment. Refer to Call Re-establishment by the Mobile Station (Section 4.8) for more information.
2.4.3.5 Full Intra-RA LLC-PDU Rerouting

This feature is implemented for a cell handled by another GPU when there is an absence of information on the target cell where the mobile station moves to. The BSS links the old and new cells using the information they have in common for that mobile station, namely the TLLI and the RAI. Once this link is set up, the BSS reroutes data from the old cell to the new cell. The BSS autonomously decides to performs LLC-PDU rerouting on a cell change when the SGSN does not support the Inter-NSE Rerouting (INR) R4 option. If the SGSN supports this option then autonomous rerouting does not occur.
2.4.3.6 NC2 for Mobile Station in Packet Transfer Mode

To reduce the number of cell reselections, the mobile station in packet transfer mode does not make autonomous reselections. It sends measurement reports to the network, therefore NC2 mode is selected.
65 / 262
2 GPRS in the BSS
2.4.3.7 Enhanced Cell Reselections for R97 onwards Mobile Station

NC2 mode is activated when the mobile station enters the packet transfer mode and NC2 mode is de-activated either at the end of the packet transfer mode or at GMM Ready timer expiry (O&M parameter) This reduces the number of cell reselections triggered during GPRS sessions. When this feature is activated, the BSS prevents multi-RAT mobile station from monitoring 3G cells while in packet transfer mode. This allows network control of mobile station cell reselection in packet transfer mode. NC2 for mobile station in packet transfer mode is activated by O&M. When activated, the network controls cell reselection of each mobile station in a packet data transfer. Each of these mobile station periodically reports its measurements to the serving cell and on the six strongest neighbor cells. This enables the network to decide whether or not an NC cell reselection is performed and which neighbor cell is the best candidate for reselection. This feature reduces the number of cell reselections triggered when the mobile station is in packet transfer mode.
2.4.4 Paging
Paging is the procedure by which the network contacts a mobile station. The network can co-ordinate circuit-switched and packet-switched paging if there is a Gs Interface between the MSC and the SGSN. This means that circuit-switched paging messages can be sent on the channels used for packet-switched paging messages, and vice-versa. Three modes are defined. Mode Network Operation Mode 1 Description Circuit-switched paging messages are sent via the SGSN and MFS. The circuit-switched paging message for the GPRS-attached mobile station is sent on the PPCH or CCCH paging channel, or on the PACCH. This means that the mobile station only needs to monitor one paging channel. It receives circuit-switched paging messages on the PACCH when the mobile station is in packet transfer mode.
66 / 262
2 GPRS in the BSS
Mode Network Operation Mode 2
Description Circuit-switched paging messages are sent via the MSC and BSC, but not the MFS. The circuit-switched paging message for the GPRS-attached mobile station is sent on the CCCH paging channel. The channel is also used for packet-switched paging messages. This means that the mobile station only needs to monitor the PCH. Circuit-switched paging continues on the PCH even if the mobile station is assigned a PDCH. The MPDCH cannot be used.
Network Operation Mode 3
Circuit-switched paging messages are sent via the MSC and BSC, but not the MFS. The circuit-switched paging message for the GPRS-attached mobile station is sent on the CCCH paging channel. The packet-switched paging message is sent on either the PPCH (if allocated) or on the CCCH paging channel.
Table 12: Network Operation Modes

Packet-switched paging does not use the Local Area for paging, but a GPRS Routing Area. The RA is smaller, thus fewer cells are involved.
2.4.5 Radio Power Control and Radio Link Measurement

In order to decrease the level of interference in a network, the uplink and downlink transmissions are constantly measured and a balance maintained between transmission power and the actual quality of the link. In GPRS, power control is implemented in an open loop on the uplink path. This maintains speech quality in the network and keeps a low bit error rate for data transmission. The BSS broadcasts the configuration parameters necessary for the mobile station. When it first accesses a cell, the mobile station sets its output power as defined in the system information. It then resets its power output according to the parameters broadcast, and to an evaluation of the uplink path loss.
2.5 Resource Management

In order to provide flexibility to the operator in managing the use of resources by circuit-switched and packet-switched traffic, resources are shared between the MFS and the BSC. Use of these resources by one system or the other can be controlled by a variety of parameters to meet operators needs. The MFS and BSC co-ordinate resource management over the BSCGP Interface. In GPRS, resource management refers principally to the allocation of Packet Data Channels. PDCHs are dynamically allocated according to user-settable criteria. When a Temporary Block Flow request is made, resources are allocated on one or more PDCH for the transfer of PDUs. The allocation process takes place as follows: 1. A TBF establishment request is received through a Packet Channel request for the uplink, or through a downlink LLC-PDU for the downlink.
67 / 262
2 GPRS in the BSS
2.
The number of PDCHs is determined by the: Mobile station multislot class. This is not always known in the uplink case O&M parameter (MAX_PDCH_PER_TBF). This defines the maximum number of allocatable PDCHs per TBF.
3. If the requested number of PDCHs is not available, a request to establish a TBF is sent to the BSC. 4. PDCHs are allocated to the TBF.
2.5.1 Time Slot Allocation

GPRS allows bandwidth to be shared between several mobiles. On a radio time slot, bandwidth can be shared between up to nine users on the downlink path and six on the uplink path, or up to 16 GPRS requests within one time slot. Circuit-switched data services require at least one time slot per user. The radio blocks on each time slot are equally distributed among the users assigned to the channel. For example, on the uplink path when coding scheme 2 is used, the minimum raw bit rate per user is 1.9 kbit/s (13.4/7) instead of 13.4 kbit/s. The following table describes the parameters for time slot allocation. This parameter: MAX_UL_TBF_ SPDCH MAX_DL_TBF_ SPDCH N_TBF_PER_ SPDCH Is used to: Define the maximum number of users (between one and six) that share a PDCH in the uplink direction. Define the maximum number of users (between one and nine) that share a PDCH in the downlink direction. Define the optimum number of shared users per direction and per PDCH. This ensures a good bit rate as long as the GPRS load is normal.
Table 13: Time Slot Allocation Parameters

If MAX_UL_TBF_SPDCH is set to five, the minimum raw bit rate per user will be increased from 1.9 kbit/s to 2.68 kbit/s (13.4/5). When the PDCH reaches five, it is declared full and will not accept a sixth shared user. However, setting the N_TBF_PER_PDCH parameter will affect a compromise between resource efficiency and quality of service For example, if N_TBF_PER_PDCH = 2 and coding scheme 2 is used, the preferred raw bit rate per user will be 6.7 kbit/s/s (13.4/2). When the number of users on the PDCH reaches the N_TBF_PER_PDCH value (2), the PDCH is declared "busy" and will preferably not accept a third user. But if the GPRS load is such that all PDCHs are busy, the BSS will override the number of users set in N_TBF_PER_PDCH and increase the number of shared resources to the maximum, using the MAL_XL_TBF_SPDCH value.
68 / 262
2 GPRS in the BSS
2.5.2 Frequency Hopping

Frequency hopping improves the bit error rate and therefore contributes to overall network quality. Frequency hopping, already provided for circuit-switched channels, has been extended to the packet-switched channels for GPRS implementation. The BSS sends the hopping law when setting up a connection. All GPRS channels then use the same hopping law in a synchronized scheme. For detailed information on frequency hopping, refer to Call Set Up (Section 3).
2.5.3 PCM Link Sharing

Resource allocation is made easier by the use of a shared 2048 kb/s PCM link. GPRS signaling and traffic channels can be multiplexed with circuit-switched traffic channels on this link between the MFS and the BSC. Traffic on the Ater Mux Interface between the MFS and the Transcoder is either processed by the MFS as GPRS traffic, or passed transparently through the cross-connect in the MFS to the BSC as circuit-switched traffic.
2.5.4 TBF Resource Re-allocation

Resource re-allocation is enabled using the EN_RES_REALLOCATION parameter. The feature provides radio and transmission resources for a TBF following an uplink request received from the mobile station, or following one or more downlink LLC-PDUs received from the SGSN, when there is no established TBF for the mobile station. More than one TRX can be allocated to GPRS services in any given cell. Resource allocation must be prioritized, so priority is set on PDCH groups. The allocation is granted to the PDCH group with the highest priority. This avoids PDCH groups in a congested state and PDCH groups that are dual-rate capable. The requested throughput is served by the: Maximum number of slots allowed by the mobile station multislot class GPRS service constraints (the operator gives the maximum number of allowed slots for one GPRS connection) Network constraints (resource availability). The allocation strategy consists of maximizing the allocated PDCH(s) use and, if necessary, requesting additional PDCH(s) from the BSC. EGPRS traffic has priority over GPRS traffic. For example, TRXs with high throughput are used for EGPRS traffic. Although GPRS throughput is optimized using TRXs with high throughput, this occurs only when there is no conflict with EGPRS traffic.
69 / 262
2 GPRS in the BSS
The four types of TBF re-allocations are described in the table below: This type of re-allocation... T1 T2 Is used to...
Maintain a TBF alive despite a pre-emption. Re-allocate an on-going TBF when establishing a concurrent TBF when: A downlink TBF is established concurrent with an existing uplink TBF, which is allocated with the maximum number of time slots supported in the direction of the bias, re-allocation cannot be given to the mobile station An uplink TBF is established concurrent with a downlink TBF.
T3
Offer better throughput to on-going TBFs when: A TBF cannot be served with the maximum number of PDCHs it supports because: Of lack of resources at the time of the request The EGPRS class is used to establish a GPRS TBF, where the GPRS mobile station class allows a greater number of allocated PDCHs with better PDCH allocation available to serve the TBF. "Signaling traffic" becomes "data traffic" An EGPRS TBF is served on a TRX which offers a higher throughput (i.e., a better TRX class). In this case, "Signaling traffic" becomes "data traffic", and an EGPRS TBF is served on a TRX which offers a higher throughput (i.e., a better TRX class).
T4
Move an uplink GPRS TBF sharing one PDCH with a downlink EGPRS TBF onto PDCHs which do not support a downlink EGPRS TBF. When one PDCH is shared between an uplink GPRS TBF and a downlink EGPRS TBF, the downlink EGPRS TBF is limited to GMSK (i.e., MCS4). Consequently, after a T4 re-allocation the downlink EGPRS TBF is able to use 8-PSK (i.e., up to MCS9).
Table 14: TBF Allocation Types
70 / 262
2 GPRS in the BSS
2.6 Traffic Load Management

Traffic load conditions affect PDCH allocation, as described in Congestion Control (Section 2.6.3). A PDCH can have one of four possible states, as shown in the following table. State Empty Active Explanation No established TBFs. At least one established TBF and the total number of established TBFs is smaller than a defined threshold (O&M parameter N_TBF_PER_SPDCH). The number of established TBFs is greater than or equal to O&M parameter N_TBF_PER_SPDCH but smaller than the maximum allowed (O&M parameter MAX_UL/DL_TBF_SPDCH). The number of established TBFs is equal to the maximum set by O&M parameter MAX_UL/DL_TBF_SPDCH.
Busy
Full
Table 15: PDCH Traffic Load States
2.6.1 PDCH Allocation with "High Load Traffic"

Additional O&M parameters are available to define a condition of "high load" traffic in the BSC. When traffic exceeds the threshold defining "high load", the following occurs: 1. The cell is activated for packet-switched traffic and MAX_SPDCH_DYN is equal to MAX_PDCH - Nb_TS_MPDCH. Resources (Min_PDCH - Nb_TS_MPDCH) are requested from the BSC (pre-allocation phase). 2. Additional PDCHs are requested from the BSC until the maximum number of SPDCHs is allocated. 3. The BSC sends a Load Indication with a decreased MAX_SPDCH_DYN, a soft pre-emption is activated on the exceeding PDCHs. T_PDCH_Pre-emption is activated. 4. During the soft pre-emption process, when T_PDCH_Pre-emption expires, a fast pre-emption process is activated on the PDCHs that are still marked as soft pre-empted. 5. The BSC sends a load indication with an increased MAX_SPDCH_DYN. Packet-switched traffic might increase again until MAX_SPDCH_DYN is reached.
71 / 262
2 GPRS in the BSS
This is the process that takes place during the phase marked "High BSC Load". The following figure shows a typical sequence illustrating the PDCH allocation procedure. Numbers in bold refer to the steps above.
allocated SPDCHs
(3)
Max_SPDCH_Dyn
(4) (5)
Max_SPDCH_Dyn
(2)
Max_PDCH Nb_TS_MPDCH
Max_PDCH_High_Load Nb_TS_MPDCH Min_PDCH Nb_TS_MPDCH
(1) time
PDCH
: Packet Data Channel
Figure 14: GPRS Traffic Load Management
2.6.2 Smooth PDCH Traffic Adaption to Cell Load Variation

To avoid wasting GPRS traffic resources when entering a high load situation, (with the ability to allocate GPRS traffic on multiple TRXs, the gap between MAX_PDCH and MAX_PDCH_HIGH_LOAD can be much bigger than in B6.2), the BSC evaluates the total (circuit and packet-switched) traffic per cell and indicates the number of PDCHs that can be granted for GPRS traffic to the MFS. The BSC notifies the MFS about any change in the number of available GPRS resources. Thus the GPRS traffic is constantly adapted to the actual traffic situation in the cell. The parameter which controls smooth PDCH traffic adaptation is Load_EV_Period_GPRS. It calculates the number of load samples (calculated every TCH_INFO_PERIOD) for the PDCH traffic adaptation load averaging algorithm.
2.6.3 Congestion Control

Capacity on demand allows operators to both reserve a number of PDCH for GPRS traffic and reserve other PDCH for shared traffic, according to the real traffic load in the cell at any given moment. The actual GPRS traffic load is dynamically matched by allocating or de-allocating PDCH after negotiation between the MFS and the BSC. The BSC is the master in the negotiation process, which means if circuit-switched traffic is heavy in a cell, there is no guarantee a GPRS mobile station can establish a call. To ensure GPRS calls are possible at any time, the parameter MIN_PDCH can be set at the OMC-R to define the number of PDCH permanently allocated to GPRS in a cell. Using this parameter to set the minimum number of PDCH allocated to GPRS traffic also sets the maximum number of radio time slots allocated to circuit-switched traffic. For GPRS calls it is also necessary to get an Ater resource. The function "fast GPRS access" (at least one PDCH always established in a cell) fulfills this requirement.
72 / 262
2 GPRS in the BSS
2.6.4 GPRS Overload Control

To prevent traffic overload conditions, the SGSN and the BSS constantly exchange traffic load information. This exchange of information, or flow control, regulates the downlink traffic between the SGSN and the BSS. The BSS sends mobile station and BSSGP Virtual Connection radio status information to the SGSN, which then regulates the output traffic to the BSS when needed. Flow control is thus applied at two levels: mobile station and BVC. Because more than one Network Service Virtual Connection can be used between the BSS and the SGSN, the traffic load can be shared and thus smoothly distributed over the Gb Interface. At data transfer uplink initialization, a Network Service Virtual Connection is selected and the uplink bandwidth is reserved. If a Network Service Virtual Connection is unavailable, traffic is then put on another Network Service Virtual Connection. The reserved bandwidth on the Network Service Virtual Connection is released at the end of the transfer. Load sharing allows different data transfers within the same cell to be carried by different Network Service Virtual Connection.
2.7 Data Transmission

This section describes the actual process for GPRS data transmission, and explains Attach/Detach procedures, Packet Data Protocol Context Activation/De-activation, and mobile-originated and mobile-terminated data transfer.
2.7.1 GPRS Attach

To access GPRS services, the mobile station performs a GPRS Attach or combined GPRS/IMSI Attach to the SGSN. (For more information on IMSI Attach-Detach, a mobility feature, see IMSI Attach-Detach (Section 3.3.5)). This procedure establishes a logical link between the mobile station and the SGSN, and allows the mobile station to be available for paging from the SGSN and notification of incoming GPRS data.
73 / 262
2 GPRS in the BSS
This process is illustrated in the following figure.

MS BTS BSC MFS SGSN HLR
GPRS
Attach
Reque
st
Update
Locati
on
Authe
nticati
on
er scrib Sub ta Da
Subs c Data riber ACK

ate Upd ACK tion
Loca
GPRS
Attach
Accep
GPRS Attach Comp lete
HLR MFS MS GPRS SGSN
: Home Location Register : Multi-BSS Fast Packet Server : Mobile Station : General Packet Radio Service : Serving GPRS Support Node
Figure 15: GPRS Attach

1. The mobile station sends a GPRS Attach Request to the SGSN.This request contains: The mobile station identity (IMSI or P_TMSI) The mobile station Routing Area Identity The type of Attach procedure requested (GPRS Attach, or combined GPRS/IMSI Attach) The mobile station classmark. 2. The SGSN verifies the mobile station identity, sends a location update to the HLR, (if the attach requested is a combined GPRS/IMSI Attach, the MSC/VLR is also updated), and requests a subscriber data profile. 3. The HLR sends a location acknowledgment back to the SGSN with the subscriber data inserted. 4. The SGSN then assigns a P_TMSI to the mobile station. 5. The mobile station acknowledges the P_TMSI, and the Attach procedure is complete. Once the GPRS Attach procedure is performed, the mobile station is in Standby and can activate Packet Data Protocol contexts.
74 / 262
2 GPRS in the BSS
2.7.2 Packet Data Protocol Context Activation

A Point-To-Point GPRS subscription contains one or more Packet Data Protocol addresses. Each Packet Data Protocol address is defined by an individual Packet Data Protocol context in the mobile station, the SGSN, and the GGSN. Before a mobile station can send or receive data, a Packet Data Protocol context must be activated. Only the GGSN or a mobile station in Standby or Ready can activate Packet Data Protocol contexts. The process for mobile-station originating activation and GGSN-originating activation are described separately.
2.7.2.1 Mobile Station-Originating Activation

The following figure illustrates Mobile Station-Originating Activation.
MS BTS
Activat e
BSC
MFS
SGSN
GGSN
PDP C ontext Reque st
Create PDP Context Reque
st
DP te P Crea sponse e xt R onte
ept xt Acc Conte te PDP Activa
GGSN MFS MS PDP SGSN
: Gateway GPRS Support Node : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
Figure 16: Mobile Station-Originating Packet Data Protocol Context Activation

1. The mobile station sends an Activation Request to the SGSN.This request contains: Transaction Identifier Packet Data Protocol type Packet Data Protocol address Access Point Name Quality of Service requested Packet Data Protocol configuration options. 2. The SGSN verifies the mobile station subscriber data, creates a Tunnel Identifier (TID - a logical bi-directional tunnel between the mobile station and the GGSN), and sends the new Packet Data Protocol type and address to the GGSN. 3. The GGSN creates a context, sends an acknowledgment to the SGSN, which sends an acknowledgment to the mobile station. 4. The GGSN can now send data through the SGSN, and billing can begin.
75 / 262
2 GPRS in the BSS
2.7.2.2 GGSN-Originating Activation

The GGSN Packet Data Protocol context activation process is illustrated in the following figure.
MS BTS BSC MFS SGSN HLR GGSN
PDU
PDP Info ting Rou uest Req
Routin
g Info ACK
equest tion R otifica PDU N

PDU N otificatio n Respo nse
ation xt Acitv Conte st PDP Reque
PDP C ontext Activat ion
GGSN HLR MFS MS PDP PDU SGSN
: Gateway GPRS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Protocol Data Unit : Serving GPRS Support Node
Figure 17: GGSN-Originating Packet Data Protocol Context Activation

1. When the GGSN receives data, it sends a message to the HLR requesting the mobile station location. 2. The HLR sends the GGSN location information and the current SGSN IP address. 3. The GGSN sends a PDU Notification Request to the SGSN, which indicates a Packet Data Protocol context needs to be created. 4. The SGSN returns a PDU Notification Response to the GGSN, and sends a Request Packet Data Protocol Context Activation message to the mobile station. This message contains the Packet Data Protocol type and address. 5. The mobile station then begins a Packet Data Protocol context activation procedure as described above.
76 / 262
2 GPRS in the BSS
2.7.3 Data Transfer

When the mobile has data to transfer through the network, data transfers can be mobile originated or mobile terminated. Each transfer type is described.
2.7.3.1 Mobile-Originated Data Transfer

The following figure illustrates the data transfer process when it is mobile originated.
MS
Pack
BSS
SGSN
et Ch Requ annel est
2 3
F L TB et U t Pack ignmen Ass
RLC
PDU
PDU RLC ACK K/N AC

UL L LC P DU
5
PDU RLC ACK /N ACK
LLC MS PDU RLC SGSN TBF UL
: Logical Link Control : Mobile Station : Protocol Data Unit : Radio Link Control : Serving GPRS Support Node : Temporary Block Flow : Uplink
Figure 18: Mobile-Originated Data Transfer

When the mobile station has data to send: 1. An Uplink Temporary Block Flow is requested (either on the PRACH, if there is a master PDCH, or on the RACH). 2. An Uplink Temporary Block Flow is established. 3. Data is sent to the network through the Radio Link Control Protocol Data Units. 4. RLC PDUs are acknowledged by the network. 5. RLC PDUs are re-assembled into Logical Link Control PDUs and sent to the SGSN. 6. On receipt of the last RLC PDUs, an acknowledgment is returned and the Uplink Temporary Block Flow is released.
77 / 262
2 GPRS in the BSS
2.7.3.2 Mobile-Terminated Data Transfer

The following figure illustrates the data transfer process when it is mobile terminated, that is, when the network originates the data transfer.
MS BSS SGSN
STAND BY
Pag PCH H or PPC Pack et Ch Requ annel est F L TB et U t Pack ignmen Ass ing P S
2 3
LLC PDU UL LLC PDU
READY
LLC PDU
F L TB et D t Pack ignmen Ass
DL
DL MS LLC PCH PDU PPCH PS SGSN TBF UL
: Downlink : Mobile Station : Logical Link Control : Paging Channel : Protocol Data Unit : Packet Paging Channel : Packet Switched : Serving GPRS Support Node : Temporary Block Flow : Uplink
Figure 19: Mobile-Terminated Data Transfer

When the network has data to send to the mobile: 1. The SGSN receives a downlink Packet Data Protocol PDU for a mobile station, and sends a paging request to the BSS. 2. The BSS sends packet paging requests to all the cells in the routing area, on the PPCH if there is a master PDCH in the cell, or on the PCH. 3. The mobile station requests the establishment of an uplink TBF from the BSS. 4. The uplink TBF is established, which allows the mobile station to send a Logical Link Control PDU to the SGSN in order to acknowledge the paging message.
78 / 262
2 GPRS in the BSS
5. The SGSN sends the data LLC-PDUs to the BSS. 6. The BSS establishes a Downlink TBF on receipt of the first LLC-PDU, and releases after sending of the last LLC-PDU.
2.7.3.3 Delayed Downlink TBF Release

Delaying the release of downlink TBFs allows enhancement of the data throughput served to mobile station end users. It also significantly reduces the GPRS signaling load. GPRS RLC/MAC procedures were designed for non real-time data transfer where the data arrives as one large block. However, the true nature of packet traffic is usually different from this assumption. For example, TCP-based applications often send small packets between peer entities before the actual data transfer starts. This leads to a high number of TBF establishments and releases. Consequently, resource use is far from optimal and transmission delays unnecessarily long. The problem can be avoided by delaying TBF release for a short period (e.g., 0.5-2s) after the transmission buffer becomes empty. Delayed downlink TBF release can occur in either of the following modes: Acknowledged Mode When the network wishes to delay the release of the TBF, it sends the last RLC data block but does not set the Final Block Indicator (FBI) bit. The network only sets the FBI bit when it wishes to permanently end the TBF. Once the network has sent the RLC data block containing the last octets of the most recent LLC frame to the mobile station, the network maintains the downlink TBF by occasionally sending dummy downlink RLC data blocks to the mobile station, incrementing the BSN with each dummy data block sent. When the network receives a new LLC frame, it begins to transmit new RLC data blocks to the mobile station, beginning with the next available BSN. When the network wishes to poll the mobile station for a Packet Downlink Ack/Nack when it has no LLC data to send, the network sends a dummy downlink RLC data block. The dummy downlink RLC data block is formed by inserting an LLC Dummy UI Command into a CS1 downlink RLC data block. The LLC Dummy UI Command is an invalid LLC-PDU and is discarded by the LLC entity in the mobile station. Unacknowledged Mode. In RLC unacknowledged mode, the mobile station detects the end of the TBF by detecting the Final Block Indicator (FBI) bit set to 1. The mobile station then transmits a Packet Control Acknowledgement, acknowledging the end of the TBF. The procedure for delayed release of downlink TBF in RLC acknowledged mode applies except that no retransmission of data blocks is done.
79 / 262
2 GPRS in the BSS
2.7.3.4 TBF Establishment Time Improvement

TBF Establishment Time Improvement reduces the TBF setting duration in the following ways: Downlink TBF establishment protocol alignment, reducing downlink TBF establishment on PACCH by about 160 ms Immediate uplink TBF establishment to avoid receiving downlink resources before establishing the uplink TBF. This allows an average gain of 500 ms Downlink TBF extension is an enhancement of the delayed downlink TBF release feature (re-activation of the delayed downlink TBF release when an uplink TBF is established) Mobile station context handling (called Handling of mobile station session/enhanced mobile station context in the System Features Description) to keep mobile station characteristics as long as possible Modification of Dummy UI command period when a concurrent uplink TBF is on-going (to avoid the 10% throughput waste in case of uplink FTP transfer).
2.7.3.5 GPRS Fast Access

The EGCH resource guarantees fast access in a cell when combined with the Immediate uplink TBF establishment feature (described in TBF Establishment Time Improvement (Section 2.7.3.4 )). By implementing both features, the first uplink TBF establishment in a cell is sped up by 300 to 400 ms. Initial EGCH resource establishment, combined with the Immediate uplink TBF establishment, optimizes TBF establishment times. Initial EGCH resource establishment guarantees that a first uplink TBF establishment request in a cell is served immediately. It also guarantees the availability of minimum resources in a cell and speeds up the first uplink TBF establishment time. This ensures that a given cell always has at least one established Slave PDCH allowing the "Immediate uplink TBF establishment" sub-feature to take full advantage of the initial reservation and perform well in all cases (except congestion ). Additionally, with a high packet-switched load, the blocking probability because of unavailable Ater resources is reduced. A flag in the OMC-R is set to guarantee, or not, at least one established Slave PDCH in a given cell, usable for GPRS and EGPRS traffic. The user chooses the best compromise between short access times and resource consumption. Typically, a user reserves terrestrial resources for dense urban cells, where there is often GPRS traffic, in order to minimize access times. In rural areas, the user can chose to optimize the Ater consumption and not reserve any terrestrial resources. When disabled, none of the pre-allocated PDCHs are connected to transmission resources. This is done as soon as a TBF needs to be established. The Immediate uplink TBF establishment does not show its best performance. When enabled, one Slave PDCH is always equipped with transmission resources and the EGCH is established in the concerned cell even without GPRS traffic. The need for this PDCH establishment is evaluated at cell start, when EN_FAST_INITIAL_GPRS_ACCESS is set from disabled to enabled. Accordingly, a Slave PDCH is then established or not.
80 / 262
2 GPRS in the BSS
This PDCH cannot be pre-empted. It guarantees to the corresponding cell that a TBF may be established in any case. The location of this established PDCH can vary in time as is the case of pre-allocated MIN_PDCH PDCHs. A periodic background mechanism verifies every T_Initial_PDCH seconds that at least one Slave PDCH is established in the cell. When the T_PDCH_Inactivity(_Last) timer expires, the concerned PDCH established is re-evaluated. When a Master Channel is de-allocated or when EN_FAST_INITIAL_GPRS_ACCESS is changed from "enabled" to "disabled", no specific action is undertaken. If a PDCH establishment is not required, transmission resources are de-allocated after the T_PDCH_Inactivity(_Last) timer expires. The default value of the timer T_PDCH_Inactivity is reduced from 10s to 2s. Because of "Immediate uplink TBF Establishment", initial establishment of one PDCH is sufficient. With the exception of high congestion situations, as soon as there is GPRS traffic in the cell, there is always room for the establishment of an additional uplink TBF on already established PDCHs. Finally, the EN_FAST_INITIAL_GPRS_ACCESS parameter setting interacts with the MIN_PDCH parameter and the number of the Master Channels in the cell. It carries out the following rules:
MIN_PDCH - Nb_TS_MPDCH > 0 if EN_FAST_INITIAL_GPRS_ACCESS =
enabled If there is a Master Channel configured in the cell and EN_FAST_INITIAL_GPRS_ACCESS = enabled, then MIN_PDCH > 1 The EN_FAST_INITIAL_GPRS_ACCESS parameter is set according to overall system dimensioning. These initial resources are statically established and cannot be pre-empted. The cell/GPU mapping is modified in order to take this function into account.
2.7.3.6 GSM-to-UMTS Cell Reselection

The three 3G-neighbor frequencies are set at cell level, enabling network operators to declare different 3G neighborhoods per GSM cell. The Packet System Information is updated in order to lighten mobile station processing, and de-activates 3G measurements when the mobile station switches from PBCCH to circuit-switched dedicated mode. The 3G search de-activation ensures that no 2G-to-3G cell reselection is triggered when the mobile station is in Packet Transfer mode. If NC2 or NC0 is activated, the mobile station cannot perform a cell reselection towards 3G or measure 3G signal strength during the transfer. The mobile station stops receiving the declared 3G frequencies as soon as it receives the Packet Measurement Order message, ceasing the search for 3G cells when in Packet Transfer mode.
81 / 262
2 GPRS in the BSS
2.7.4 Packet Data Protocol Context De-activation

Before a GPRS Detach procedure can be initiated, the Packet Data Protocol context must be de-activated. The de-activation can be done by the mobile station or by the network.
2.7.4.1 Mobile-Originating De-activation

The following figure illustrates this process.
MS
BTS
BSC
ate PDP Context Request
MFS
SGSN
GGSN
1
DeActiv
Delete Context PDP Request
4
Context ate PDP Accept
e PDP Delet sponse xt Re Conte
DeActiv
Figure 20: Mobile-Originating Packet Data Protocol Context De-activation

1. The mobile station sends a De-activate Packet Data Protocol Context Request to the SGSN. 2. The SGSN sends a Delete Packet Data Protocol Context Request to the GGSN, which contains the TID. 3. The GGSN deletes the Packet Data Protocol context, and sends a Delete Packet Data Protocol Context Response with the de-activated TID to the SGSN. 4. The SGSN sends a De-activate Packet Data Protocol Context Accept message to the mobile station, confirming the de-activation.
82 / 262
2 GPRS in the BSS
2.7.4.2 SGSN-Originating De-activation

Network-originated Packet Data Protocol context de-activation processes are shown in the following figure.
MS
BTS
BSC
MFS
SGSN
GGSN
Delete PDP Context Request
e PDP Delet ponse Res text Con
SGSNOriginating
3
Context ate PDP Request
DeActiv
4
DeActiv ate PDP Context Accept
GGSNOriginating
2
Context ate PDP Request
e PDP Delet quest xt Re Conte
DeActiv
3
DeActiv ate PDP Context Accept
Delete PDP Context Response
Figure 21: Network-Originating Packet Data Protocol Context De-activation Processes

1. The SGSN sends a Delete Packet Data Protocol Context Request to the GGSN, which contains the TID. 2. The GGSN de-activates the Packet Data Protocol context and sends a Delete Packet Data Protocol Context Response to the SGSN. 3. The SGSN sends a De-activate Packet Data Protocol Context Request to the mobile station. 4. The mobile station de-activates the context, and returns a De-activate Packet Data Protocol Context Accept.
83 / 262
2 GPRS in the BSS
2.7.4.3 GGSN-Originating De-activation

1. The GGSN sends a Delete Packet Data Protocol Context request to the SGSN, which contains the TID. 2. The SGSN sends a De-activate Packet Data Protocol Context Request to the mobile station. 3. The mobile station de-activates the context and returns a De-activate Packet Data Protocol Context Accept. 4. The SGSN sends a Delete Packet Data Protocol Context Response to the GGSN, which deletes the context. This process is illustrated in Figure 21.
2.7.5 GPRS Suspend

GPRS suspend processes are shown in the following figure.
MS
BTS
BSC
MFS
SGSN
1
RR Susp end
Suspen
3
T3
Suspen
Suspend
Ack
Suspend
Ack
MFS SGSN
: Multi-BSS Fast Packet Server : Serving GPRS Support Node
Figure 22: GPRS Suspend

1. The mobile station sends an RR Suspend (TLLI, RAI, suspension cause) message to the BSC. This is sent as soon as possible after entering the dedicated mode. If the GPRS suspension procedure was initiated during a GPRS transfer, the mobile station releases all its GPRS resources. 2. The BSC sends a Suspend (TLLI, RAI, suspension cause) message to the MFS, via the GSL link. The BSC stores TLLI and RAI in order to be able to request the SGSN (via the MFS) to resume GPRS services when the mobile station leaves dedicated mode. A timer is not necessary to monitor the Suspend Ack reception. If this acknowledgment is not received (i.e., no Suspend Reference Number (SRN) reception, see step 4), the Resume will not be sent at circuit-switched call completion. 3. The MFS sends a Suspend (TLLI, RAI) message to the SGSN. 4. The MFS receives a Suspend Ack from the SGSN, in which there is a Suspend Reference Number which is used in the GPRS resume process. The acknowledgment of the SGSN is supervised by a timer (T3). 5. The MFS sends a suspend acknowledgment to the BSC, with the Suspend Reference Number information.
84 / 262
2 GPRS in the BSS
2.7.6 GPRS Resume

GPRS resume processes are shown in the following figure.
MS BTS BSC
1
Resu me
MFS
SGSN
2
Resu me
T_GPRS_Resume
T4 3 4k c me A Resu
ck me A Resu
5
RR el Re Chann lease
6
Routing Area Up date Request
MFS MS RR SGSN
: Multi-BSS Fast Packet Server : Mobile Station : Radio Resource : Serving GPRS Support Node
Figure 23: GPRS Resume

1. The BSC determines that the circuit-switched radio channel must be released (typically upon circuit-switched call completion). If the BSC is able to request the SGSN to resume GPRS services (i.e., the suspend procedure succeeded and the BSC received the Suspend Reference Number, and no external handover has occurred), the BSC sends a Resume (TLLI, RAI, Suspend Reference Number) message to the MFS. After sending the Resume message, the BSC starts a guard timer (T_GPRS_Resume) and waits for a Resume Ack message from the MFS. The guard timer is set as short as possible, so as to be compatible with the usual RR connection release procedure, and therefore not delay the procedure. However, this message is not sent in the case of successful completion of an external handover. In this case, the BSC deletes any stored data or suspend/resume context related to that mobile station. 2. On receipt of a Resume message from the BSC, the MFS sends a Resume (TLLI, RAI, Suspend Reference Number) message to the SGSN, starts a guard timer (T4) and waits for a Resume Ack message from the SGSN. 3. The MFS receives a Resume Ack from the SGSN. 4. On receipt of the Resume Ack from the SGSN, the MFS stops the guard timer (T4) and sends a Resume Ack message to the BSC. If no Resume Ack is received from the SGSN before expiry of the guard timer (T4), the MFS sends a Resume Nack to the BSC. On receipt of the Resume Ack or Nack message from the MFS, the BSC stops the guard timer (T_GPRS_Resume). 5. The BSC sends an RR Channel Release (GPRS Resumption) message to the mobile station and deletes its suspend/resume context. GPRS Resumption indicates whether the BSS has successfully requested the SGSN to resume GPRS services for the mobile station, (i.e., whether the Resume Ack was received in the BSS before the RR Channel Release message was transmitted). The mobile station then exits dedicated mode. If the guard timer expired, or if a Resume Nack message was received by the BSC, the Channel Release message includes the GPRS Resumption indication equal to NOK.
85 / 262
2 GPRS in the BSS
6. The mobile station resumes GPRS services by sending a Routing Area Update Request message in the following cases: Reception of a Channel Release with GPRS Resumption = NOK Reception of a Channel Release without GPRS Resumption IE T3240 expiry.
2.7.7 GPRS Detach

After the Packet Data Protocol Context has been de-activated, the mobile station or the network can perform a GPRS Detach procedure. Whether the detach is initiated by the mobile station or the network, the results are the same: The mobile station leaves the Ready mode and enters the Idle mode All Packet Data Protocol contexts are deleted The mobile station returns to the circuit-switched system.
2.7.7.1 Mobile Station-Originating Detach

The following figure illustrates this process.
MS
BTS
BSC
MFS
SGSN
GGSN
1
Detach Request
4
tach GPRS De Accept
e PDP Delet sponse e ext R Cont
Figure 24: Mobile Station-Originating GPRS Detach

1. The mobile station sends a GPRS Detach Request to the SGSN. This message contains: The type of Detach (GPRS or GPRS/IMSI) An indication if the Detach is due to a mobile station switch off. 2. The SGSN tells the GGSN to de-activate the Packet Data Protocol context. 3. The GGSN responds to the SGSN with a message that it has de-activated the Packet Data Protocol context. 4. The SGSN sends a Detach Accept message to the mobile station.
86 / 262
2 GPRS in the BSS
2.7.7.2 Network-Originating Detach

Network-originating GPRS Detach procedures are shown in the following figure.
MS
BTS
BSC
MFS
SGSN
GGSN
HLR
1
ation l Loc Cance
1
quest tach Re GPRS De
2 3
Conte
e PDP Delet ponse s xt Re
4
Detach Accept
2
Cancel Location ACK
GGSN HLR MFS MS PDP SGSN
: Gateway GPRS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
Figure 25: Network-Originating GPRS Detach Procedures

A GPRS Detach can be initiated by both the SGSN and the HLR. An SGSN Detach is the most common network Detach. In this procedure: 1. The SGSN sends a Detach Request to the mobile station, which contains the Detach type. The Detach type tells the mobile station if it needs to re-attach and re-activate the Packet Data Protocol context previously used. 2. The SGSN tells the GGSN to de-activate the Packet Data Protocol contexts. 3. The GGSN responds to the SGSN with a message that it has de-activated the Packet Data Protocol context. 4. The mobile station sends the Detach Accept message to the SGSN. If the Detach is requested by the HLR: 1. The HLR sends a Cancel Location message to the SGSN, which initiates the above process. 2. The SGSN confirms the Packet Data Protocol context deletion by sending a Cancel Location Acknowledgment to the HLR.
87 / 262
2 GPRS in the BSS
2.8 Location Services (LCS)

2.8.1 Introduction
Location Services provide mobile station geographical location (i.e., longitude, latitude). LCS is applicable to any target mobile station whether or not the mobile station supports LCS, but with restrictions on positioning method when LCS or individual positioning methods are not supported by the mobile station. LCS clients make requests to the PLMN LCS server for location information on one or several target MSs with a set of parameters such as LCS Client Type, LCS Priority, LCS Quality of Service (QoS), which includes requested position accuracy and allowed response time. LCS clients reside in an entity (including the mobile station) within the PLMN or in an entity external to the PLMN. The target mobile station is positioned by the LCS. Depending on the positioning techniques, some LCS functions reside in the mobile station. LCS in the packet-switched domain is not supported. Network Measurements Results (NMR) are not supported with LCS.
2.8.2 Logical Architecture

LCS Services support requires new network elements in the network subsystem and optionally, depending on positioning techniques and network synchronization, on the radio side. These network elements are: Gateway Mobile Location Center (GMLC) Serving Mobile Location Center (SMLC)
Figure 26: Generic LCS Logical Architecture
88 / 262
2 GPRS in the BSS
As depicted in the above figure: The GMLC is the first network element for external Location Application (LA) access in a GSM PLMN. The GMLC requests routing information from the HLR via the Lh Interface. After performing registration authorization, it sends positioning requests to the MSC or to the SGSN and receives final location estimates from the MSC or the SGSN via the Lg Interface The SMLC is the network element serving the mobile station. The SMLC manages the overall co-ordination and scheduling of resources required to perform positioning of a mobile station. It also calculates the final location estimate and accuracy. The SMLC controls to obtain radio Interface measurements enabling mobile station location in the service area. The SMLC is connected to the BSS (via the Lb Interface). It dialogs with other SMLCs (via the Lp Interface) to obtain measurements managed by another SMLC when the mobile station is at the border of the SMLC-covered area.
2.8.3 LCS Positioning Methods

In LCS, the SMLC, a functional network element in the BSS, is integrated in the MFS and is configured by the OMC-R, if the MFS also provides the GPRS services to several BSCs. The SMLC performs locations services for this set of BSCs. Location requests are received on the A Interface from the NSS. The LCS uses an Alcatel proprietary interface, BSCLP, for signaling protocol between the BSC and the SMLC. LCS supports the following positioning methods: TA Positioning Conventional GPS Positioning Assisted GPS (A-GPS) Positioning.
2.8.3.1 TA Positioning
TA Positioning delivers Cell ID, Timing Advance, and, optionally, Measurement Report information to the SMLC. TA Positioning regroups several distinct methods, depending on the availability and the relevance of the elementary information: The Time Advance (TA) Cell Id (CI), only in omnidirectional cells, the geographic co-ordinates of the BTS is returned instead of the real mobile station position. The TA value is used to determine the region as a circle or a ring Cell Id + Timing Advance (CI+TA). With the TA positioning method, no signaling exchange is required between the SMLC and the mobile station . The TA positioning applies to all mobile stations whether they support LCS or not.
2.8.3.2 Conventional GPS Positioning

Conventional GPS Positioning is based on the GPS location estimate performed in the mobile station and provided to the SMLC.
89 / 262
2 GPRS in the BSS
2.8.3.3 Assisted GPS (A-GPS) Positioning

Assisted GPS (A-GPS) Positioning is split into Mobile Station-Assisted A-GPS and Mobile Station-Based A-GPS positioning methods, depending on where the location calculation is processed: in the network or in the mobile station. For Mobile Station-Assisted A-GPS, the mobile station receives GPS Assistance Data from the SMLC, performs GPS measurements and returns the GPS measurements to the SMLC. The SMLC provides these GPS measurements to the external GPS server, which computes the mobile station location estimate. For Mobile Station-Based A-GPS, the mobile station receives GPS Assistance Data from the SMLC, performs GPS measurements and location calculation, and returns its location estimate to the SMLC.
2.8.4 LCS Scenario in Circuit-Switched Domain

In the circuit-switched domain, an LCS scenario is as follows: 1. An external LCS Client requests the current location of a target mobile station. 2. This request is handled by the GMLC, which verifies the LCS Client identity and authorizations, and determines the MSC of the target mobile station. 3. The MSC receives the location request containing the type of location information requested (current location, assistance data for the mobile station), the mobile station subscribers IMSI, LCS QoS information (accuracy, response time). In idle mode, the MSC performs circuit-switched paging, authentication and ciphering to establish an SDCCH with the mobile station. The mobile station subscriber is only aware of circuit-switched paging when a GPRS mobile station in Packet Transfer Mode suspends GPRS traffic to answer circuit-switched paging.
4. When the mobile station is in dedicated mode (after a specific SDCCH establishment for location, or during an on-going call), the MSC sends the location request to the BSC in the existing SCCP connection for the current call, which forwards it to the SMLC. 5. The SMLC chooses a positioning method and triggers the appropriate procedure to locate the mobile station. Some message exchanges take place between the SMLC and the BSC.
6. The MSC then sends a response to the GMLC. The LCS-related messages exchanged between the BSC and the MFS are conveyed through current GSLs (same SAPI as for GPRS-related messages).
2.8.5 Physical Implementation

The GPU software supports both GPRS and SMLC, and is handled as a whole. For a BSC connected to several GPUs, the SMLC is supported by the pilot GPU (the pilot GPU is the GPU handling procedures at BSS level). When the pilot GPU is reselected, the SMLC function restarts on the new pilot GPU. The LCS-related configuration data is downloaded from the control station to the new pilot GPU. The former pilot GPU clears all the LCS-related telecom contexts as well as the LCS-related configuration data.
90 / 262
2 GPRS in the BSS
2.8.6 SMLC Functions

The SMLC performs the following functions: Handles LCS protocols towards the BSC and the mobile station, and towards the external GPS server Manages call-related location context per mobile station Selects a positioning method Triggers the position calculation process for the TA positioning method and presents the location estimate of the mobile station in a standard format. For Conventional GPS or Mobile Station-Based A-GPS, the calculation is performed in the mobile station Requests and receives GPS Assistance Data destined for the mobile station, when Mobile Station-Assisted and Mobile Station-Based A-GPS Provides GPS measurements performed by the mobile station to the external GPS server, for Mobile Station Assisted A-GPS, to retrieve the mobile station location estimate Uses O&M information present in the MFS or SMLC, provided by the OMC-R Handles errors.
2.8.7 BSS and Cell Configuration

LCS is an optional feature of the Alcatel BSS. It can be blocked by the manufacturer, and enabled or disabled by the operator at the OMC-R level. For LCS cell support, the user activates LCS on the BSS handling this cell. He also activates GPRS for this cell. For example, setting MAX_PDCH to a value greater than zero is mandatory; the cell is locked for GPRS if the operator does not want GPRS running on this cell. The user configures the required transmission resources (Ater and Gb resources) on the GPU(s) connected to this BSC. The O&M characteristics of the serving cell are: Enabled LCS positioning method in the cell Preferred GPS method when several GPS methods are candidates for the location procedure Configuration data availability SMLC and GPS server interface state.
91 / 262
2 GPRS in the BSS
2.8.8 LCS O&M

The OMC-R provides LCS centralized management. Two alarms are used: An alarm indicating the concerned LSN. This alarms attributes are: alarm label: "GPS server not reachable through LSN" alarm type: communicationsAlarm probable cause: lan error perceived severity: minor. An alarm with the following attributes: alarm label: "GPS server not reachable" alarm type: QoS probable cause: underlying resource unavailable specific problem: alarmId translation, component translation (identifying Fabric) perceived severity: major. The user correlates this information with the current router state and with the Ethernet links state between GPUs and hubs.
92 / 262
2 GPRS in the BSS
2.9 High Speed Data Service (HSDS)

2.9.1 HSDS Description
HSDS supports CS1 to CS4 in GPRS and supports EGPRS with MCS1 to MCS9. The coding scheme and the radio modulation are modified to increase the data traffic throughput of a given radio time slot, resulting in an increase of throughput on the Abis and Ater interfaces. On the Ater Interface, several Ater nibbles are allocated dynamically by MFS telecom to handle throughput higher than 16kbit/s On the Abis Interface, a group of 16k nibbles is statically associated with each radio time slot. Depending on the coding scheme or the MCS, from one to five 16k channels are necessary per PDCH between the MFS and the BTS. In an HSDS BSS, each TRX belongs to one of five types characterized by the number of Abis nibbles which are allocated to each radio time slot. The following table explains HSDS terminology: Term EGCH Explanation Set of n-associated 16k channels, one main GCH and n-1 auxiliary GCHs, used to transport PS traffic. There is one EGCH per PDCH. Any of the n 16k channels composing an EGCH. 16k channel. 16k Abis channel either used for circuit-switched or packet-switched traffic. 16k Abis channel exclusively used for packet-switched traffic. 16k GCH channel which uses the basic Abis nibble 16k GCH channel which uses an extra Abis nibble. TRX which can be used for packet-switched traffic, at least for GPRS traffic, characterized by TRX_Pref_Mark = 0. TRX which is EGPRS capable and with n > 1. At least two GCHs are necessary for 8-PSK (MCS5). To a TRX type n, are associated eight basic Abis nibbles and 8 x (n-1) extra Abis nibbles, for HSDS. For a TRX class n, the MFS will use n GCHs to establish one EGCH. The MFS handles a TRX class rather than a TRX type, since the "real" TRX type can be reduced due to hardware capability.
GCH Nibble Basic Abis nibble
Extra Abis nibble
Main GCH Auxiliary GCH PS-capable TRX
8-PSK-capable TRX
TRX type n
TRX class n
93 / 262
2 GPRS in the BSS
Term TRX transmission pool
Explanation In the BSC, pool of 16k extra Abis nibbles allocated to a TRX HSDS where a pool type n contains (n-1) x 8 extra Abis nibbles. Possibility for the TRX to support EGPRS or not and if it is able to support EGPRS, its maximum MCS. The corresponding radio and transmission resources are allocated and the corresponding EGCH is activated. The corresponding radio resource has been allocated by the BSC, but no associated Ater resources are allocated.
TRX EGPRS capability Established PDCH
Allocated PDCH
Table 16: HSDS Terminology
2.9.2 GPRS CS3/CS4 and EGPRS Protocol

2.9.2.1 EGPRS
For HSDS, EGPRS enables data transmission support at a bit rate exceeding GPRS capabilities and uses new modulation and coding schemes on the Air Interface. Data throughput is optimized in concordance with radio propagation conditions (Link Adaptation).
2.9.2.2 Modulation and Coding Schemes

Nine modulation and coding schemes enhance packet data communications (EGPRS), providing raw RLC data rates ranging from 8.8 kbit/s (minimum value per time slot, under the worst radio propagation conditions) up to 59.2 kbit/s (maximum value achievable per time slot under the best radio propagation conditions). Data rates above 17.6 kbit/s require that 8-PSK modulation are used on the A Interface, instead of GMSK. Link adaptation changes Modulation and Coding Schemes (MCS) according to radio conditions. When radio conditions worsen, a protected MCS with more redundancy is chosen, leading to a lower throughput. Inversely, when radio conditions improve, a less protected MCS (less redundancy) is chosen for higher throughput. The three families of coding schemes and their unit payloads are described below. This Family... Family A Family A padding Family B: MCS2 Family C Contains... MCS3, MCS6, MCS8 and MCS9 MCS3, MCS6, and MCS8 MCS5 and MCS7 MCS1 and MCS4 Payload Unit 37 bytes 34 bytes 28 bytes 22 bytes
94 / 262
2 GPRS in the BSS
When a block is retransmitted with a given MCS, it can be retransmitted (if needed) via ARQ with a more robust MCS of the same family. Two selective ARQ mechanisms are used for the transfer of EGPRS RLC data blocks in the acknowledged RLC/MAC mode: Type I ARQ mechanism: with this mechanism, when a RLC data block is retransmitted, the same or another MCS from the same family is selected Type II ARQ mechanism (also called Incremental Redundancy (IR): in this case a second "puncturing scheme" is applied to the same MCS, if an error is detected. Four Coding Schemes are used for GPRS (CS1 to CS4). GPRS and EGPRS signaling always uses CS1. MCS1 to MCS4 are based on GMSK modulation, while MCS5 to MCS9 are based on 8-PSK modulation. The Alcatel BSS does not support MCS5-MCS9 in the uplink direction. Coding Scheme Modulation Maximum rate [kbps] per radio TS basis 59.2 54.4 44.8 29.6 22.4 17.6 14.8 11.2 8.8 21.4 15.6 13.4 9.05
MCS9 MCS8 MCS7 MCS6 MCS5 MCS4 MCS3 MCS2 MCS1 CS4 CS3 CS2 CS1
8-PSK 8-PSK 8-PSK 8-PSK 8-PSK GMSK GMSK GMSK GMSK GMSK GMSK GMSK GMSK
2.9.2.3 Mobile Station Multislot Class Handling

With EGPRS, an EGPRS mobile station multislot class is introduced.
2.9.3 Transmission Handling

Transmission handling is described in the following sections.
95 / 262
2 GPRS in the BSS
2.9.3.1 TRX Hardware Configuration Management

The Abis time slots are connected to the TCUs through the BIUA. The BTS connects each radio time slot to one Abis nibble. All the nibbles for circuit-switched traffic (basic nibbles) for a given TRE are connected to the same TCU. The extra 16k nibbles are connected to any TSU TCU carrying the primary Abis, or any TSU TCU carrying the secondary Abis.
2.9.3.2 Logical Configuration Management and TRX/RSL Mapping

TRXs are mapped to TREs using the current algorithm. After mapping, the following adjustment occurs: TREs are classified according to their packet switching capability and Full Rate/Dual Rate usage, from the highest to the lowest priority: from G4 High Power Full Rate, G4 High Power Dual Rate, G4 Medium Power Full Rate, G4 Medium Power Dual Rate, Evolium A9100 Full Rate, and finally to Evolium A9100 Dual Rate If PS_Pref_BCCH_TRX = True (i.e., the BCCH TRX has the highest priority for PS traffic), the TRX with BCCH is mapped to the highest priority TRE TRXs with TRX_Pref_Mark = 0 are mapped to the TREs with the highest priority, beginning with the TRXs which have the biggest PDCH-group size.
2.9.3.3 TRX Ranking

The BSC determines the ranking of packet switch-capable TRXs for circuit-switched and packet-switched calls to ensure consistent allocation. By this ranking the TRXs selected first by the BSC for circuit-switched calls are those selected last by the MFS for packet-switched calls. Packet switch-capable TRXs are ranked according to the following criteria, from the highest to the lowest: TRX supporting the BCCH, if PS_Pref_BCCH_TRX = True TRX capability (G4 High Power, then G4 Medium Power, and then Evolium A9100) Dual Rate capability (Full Rate TRXs have a higher priority than Dual Rate TRXs) The number of radio time slots available for PS traffic. Circuit switch-only TRXs are not provided to the MFS.
96 / 262
2 GPRS in the BSS
2.9.3.4 TRX Transmission Pool Set Up

TRX transmission pools group together extra Abis nibbles for one TRX. The largest TRX transmission pools are allocated to the TRX with the highest priority for packet-switched traffic. These pools are defined for each sector of each BTS and may be defined for the main and/or the secondary sector when a cell is shared. After the operator defines TRX transmission pools on a BTS, the BSC takes into account TRE hardware capability to assign Dual Rate usage. Since a Dual Rate radio time slot can serve two Half Rate circuit-switched calls, the Dual Rate TRE is used for circuit-switched allocations to ensure better circuit-switched cell capacity.
2.9.3.5 Connection of Extra Abis Nibbles to TREs in the BTS

Extra Abis nibbles are connected to the BTS TREs as follows, enabling a given radio time slot to be connected to n nibbles overall in the BTS. 1. The BSC informs the BTS via the OML of the static mapping of each extra 16k nibble on the Abis to each TRX. 2. The BSC groups extra Abis nibbles so that 8 x (n-1) extra Abis nibbles are mapped to each type n TRX, on top of the already-mapped basic Abis nibbles ( n = 1 to 5). 3. Extra Abis time slots are only mapped on a TCU supporting TRE Full Rate. A Dual Rate TCU does not support extra Abis TS. The same constraint exists between Full Rate TRE and Dual Rate TRE as between Extra Abis TS and Dual Rate TRE. 4. To perform Full Rate TRE or extra Abis TS extension, the operator triggers a compact reshuffling to group all Dual Rate TRE to free TCU for Full Rate TRE or extra Abis time slot.
2.9.3.6 Second Abis Link

When there are insufficient Abis time slots on one Abis link, a second Abis can be attached to the BTS. In this case, the OML, RSL, and basic time slots are always mapped to the first link and extra time slots for the TRX transmission pools are split over the two Abis links and the second Abis link supports extra 16k nibbles for packet traffic. This link does not carry circuit-switched traffic and cannot cross-connect on the secondary Abis. Only EVOLIUM BTS with SUMA boards or Evolium A9110-E support the second Abis link. EVOLIUM BTS with SUMP boards must be upgraded. An EVOLIUM BTS can manage two termination points. It is therefore impossible to do the following: Connect a BTS in chain after a BTS with two Abis Change the Abis from chain to ring if there is a BTS with two Abis Attach a second Abis to a BTS that is not at the end of an Abis chain Attach a second Abis to a BTS that is in an Abis ring.
97 / 262
2 GPRS in the BSS
2.9.3.7 Transmission Power

The three types of transmission power are described below: GMSK Output Power The BTS sets all TRE transmit GMSK output power to the same level, the minimum value among the maximum TRE output power in a sector and in a given band. 8-PSK Output Power For one given TRE, the maximum output power is lower in 8-PSK than in GMSK because of the 8-PSK modulation envelope which requires a quasi-linear amplification. The TRE transmit power in 8-PSK does not exceed the GMSK transmit power in the sector and in the band. In 8-PSK, the applicable leveling aligns, when necessary, the 8-PSK transmit power to the GMSK transmit power in the sector and in the band. Modulation Delta Power. The Modulation Delta Power is the difference between the GMSK output power of the sector for the TRE band and the 8-PSK output power of the TRE. 8-PSK High Power Capability is true if Modulation Delta Power is less than 3 dB, else it is an 8-PSK Medium Power Capability type TRE.
2.9.4 Cell/GPU Mapping Modification

The algorithm which maps the cells on the GPUs takes into account the number of extra Abis nibbles allocated per TRX. This avoids all cells having static GCHs, mapped on the same GPU and thus limits the risk of Ater blocking. The cell/GPU mapping process includes: A new parameter (Nb_Extra_Abis_TS) per cell to the MFS in order to steer the cell - GPU mapping. Nb_Extra_Abis_TS is the number of auxiliary 64k channels in the TRX Transmission pools of the cell The number of MPDCHs (Nb_TS_MPDCH) The number of GCHs used by the initial PDCH, when En_Fast_Initial_GPRS_Access = True One GCH, if Nb_Extra_Abis_TS = 0 Two GCHs, if Nb_Extra_Abis_TS differs from 0. After a change of pools configuration, the cell is "misaligned" and the operator must resynchronize the MFS.
2.9.5 GCH Congestion Control Algorithm

When the DSP enters the Ater congestion state, a process is launched which reduces the number of GCHs from PDCHs which do not support EGPRS TBFs. The number of GCHs is reduced according to the O&M parameter Max_GPRS_CS which specifies whether CS3/4 is enabled or not, in the cell: Reduction to one GCH, if Max_GPRS_CS < =2 Reduction to two GCHs, if Max_GPRS_CS > 2.
98 / 262
3 Call Set Up
3 Call Set Up
This chapter provides an overview of how a call is set up between the NSS and the mobile station. It describes the various kinds of calls that can be set up. The type of teleservice and bearer service required are also described.
99 / 262
3 Call Set Up
3.1 Overview
Call set up is required to establish communication between a mobile station and the NSS. The NSS is responsible for establishing the connection with the correspondent. Different types of calls require different teleservices. These teleservices are defined in the GSM specifications. The type of teleservice and bearer service to be used is negotiated before the normal assignment procedure. See Normal Assignment (Section 3.2.3) for more information.
3.1.1 Call Types

The following table shows the three basic types of call: Type of Call Mobility Management Calls Description These calls, e.g., location update, are used by the system to gather mobile station information. The exchanges are protocol messages only; therefore, only a signaling channel is used. Figure 7 illustrates the location update procedure. These calls, e.g., SMS and SS calls, pass small amounts of information. Therefore, only a signaling channel is used. These calls, e.g., speech or data calls to a correspondent, can pass large amounts of information. Therefore they require greater bandwidth than a signaling channel. These calls use traffic channels.
Service Calls
User Traffic Calls
Table 17: Types of Calls

The channels used for calls are the SDCCH for signaling (static SDCCH), for traffic and signaling (dynamic SDCCH), and the traffic channel for user traffic (see The Air Interface (Section 1.7.8) for more information). These channels are associated with FACCH/SACCH. An SDCCH is always assigned for call set up, even if a traffic channel is later required for the call. The role of the BSS in call set up is to assign the correct channel for the call, and to provide and manage a communications path between the mobile station and the MSC.
100 / 262
3 Call Set Up
3.1.2 Call Set Up Phases

The following table shows the phases involved in call set up: Phase Radio and Link Establishment Composition Paging (for mobile-terminated calls only) informs the mobile station that it is being called. If attach_detach_allowed is activated, the mobile station IMSI_detach message can eliminate the need for paging. See IMSI Attach-Detach (Section 3.3.5). The immediate assignment procedure allocates a resource to the mobile station and establishes a Radio Signaling Link between the BSS and the mobile station. A Interface connection, to assign an SCCP signaling channel between the BSC and MSC Assignment of a switching path through the BSC. Authentication and Ciphering Classmark handling. Authentication. Ciphering. Normal assignment Teleservice/bearer service negotiation. Channel allocation. Physical context procedure. Traffic channel assignment, if required. Call connection.
Table 18: Call Set Up Phases

The phases are described in Mobile-Originated Call (Section 3.2) and Mobile-Terminated Call (Section 3.3).
101 / 262
3 Call Set Up
3.2 Mobile-Originated Call

A call initiated by a mobile station can either be a subscriber call, where speech and/or data is passed across the network, or a location update call from a mobile station in idle mode. Location update information is passed on the signaling connection. Therefore, the initial call set up procedure is similar to a subscriber call. The location update does not require allocation of a traffic channel.
3.2.1 Radio and Link Establishment

When a connection with a mobile station is required, the following must happen: A radio channel must be assigned to permit communication between the mobile station and the BSS A terrestrial link must be established in order to signal the presence of the mobile station to the network. The procedure for obtaining these initial connections is called radio and link establishment. The radio and link establishment procedure establishes signaling links between: The BSS and the mobile station via the SDCCH channel The BSS and the MSC via the SCCP link. These links pass the information for call negotiation, and set up a traffic channel, if required. Figure 27 shows radio and link establishment for a mobile-originated call.
3.2.1.1 Channel Request

The mobile station initiates a call by sending a channel_request message, with an REF. The REF includes an establishment cause and a RAND (used for authentication). It is transmitted on the RACH channel. The RACH channel is associated with the CCCH channel which the mobile station is monitoring while in idle mode. The establishment cause field of the REF specifies: An emergency call Call re-establishment Response to paging Mobile station-originating speech call Mobile station-originating data call Location update Service call (SMS, etc.).
102 / 262
3 Call Set Up
The mobile station notes the random number and frame number associated with each channel_request message. These are used by the mobile station to recognize the response sent from the BSS. This response is sent on the AGCH, which can be monitored by many mobile stations. The mobile station decodes all messages sent on this AGCH, and only accepts a message with a random number and frame number matching one of the last three requests sent.
MS
Channel Request (RACH)
Channel Required REF+RFN+ TA
BTS
BSC
MSC
REF
REF stored in MS memory

on Activati Channel r +powe CCH TA+SD
SDCCH Allocation
Channel Activati on Ack
MS compares message with REF in memory

Switch to SDCCH
GCH) ment (A e assign Immediat DCCH +TA+S FN REF+R
command e assign Immediat REF +RFN+ wer CH+po A+SDC
SABM + cm + Se rvice Requ est

UA
Request Service
Establish Indication cm + Serv ice Reques t
SCCP Conn ection Re quest cm + Serv ice Reques t

Confirm nnection SCCP Co
Service Request must match original sent by MS in the SABM

cm ID power REF RFN SDCCH Service Request TA UA : Classmark : Mobile Station identity : Mobile Station power or BTS power : Random access information value : Reduced frame number
: Description of the allocated SDCCH (Standalone Dedicated Control Channel) : Initial Layer 3 message : Timing advance : Unnumbered acknowledgment
Figure 27: Radio and Link Establishment for Mobile-Originated Call

The mobile station continues to transmit channel_request messages until it receives a response. If no response is received before the mobile station has transmitted a predefined number of retries, the mobile station: Displays a network error message for all calls except location updates Performs automatic reselection for location update calls. This means that the mobile station attempts random access on a different cell.
103 / 262
3 Call Set Up
On receipt of the channel_request message from the mobile station, the BTS sends a channel_required message to the BSC. This message contains the random number sent by the mobile station, and the timing advance measured by the BTS.
Note:
Under peak load conditions, resources may be over allocated due to this process. See below for details on how the Immediate Assignment Extended feature works to alleviate this problem.
3.2.1.2 SDCCH Channel Activation

The BSC checks the channel_required message to ensure it can accept the request. It allocates an SDCCH channel if one is available. The resource management software of the BSC allocates the SDCCH on the basis of which traffic channel has the most available SDCCHs. This ensures the load is spread between the traffic channels. The BSC then sends a channel_activation message to the BTS. It also sets a timer to wait for an acknowledgment from the BTS, indicating that it is ready to activate the channel. The channel_activation message contains: A description of the SDCCH to be used The timing advance Mobile station and BTS power commands. The mobile station and BTS power are set to the maximum allowed in the cell. The BTS initiates the physical layer resources for the channel and sets the LAPDm contention resolution ready for the first mobile station message on the SDCCH. It then sends a channel_activation_acknowledgment message to the BSC. The BSC stops its guard timer.
Note:
Contention resolution prevents two mobile stations connecting to the same SDCCH. The following figure shows the Channel Activation procedure.
MS BTS BSC SDCCH Allocation
wer H+po DCC TA+S
Chann el Activ
MSC
Chann
el Acti
vation
ation A
ck
power SDCCH TA
: Mobile Station power or BTS power : Description of the allocated SDCCH (Standalone Dedicated Control Channel) : Timing advance
Figure 28: SDCCH Channel Activation
104 / 262
3 Call Set Up
3.2.1.3 Immediate Assignment

The BSC builds and sends an immediate_assign_command message repeating the information given in the channel_activation message. This message also includes the random number and frame number of the original mobile station request to which the BSC is replying. It also instructs the BTS to inform the mobile station of the SDCCH channel assignment. The BSC starts a guard timer for the mobile station to respond. The following figure shows the Immediate Assignment procedure.
MS BTS BSC MSC
dia Imme
Switch to SDCCH
DCCH TA+S RFN+ REF+
te ass
ignme
nt (AG
CH)
and comm ssign diate a RFN Imme REF+ wer+ H+po DCC TA+S
REF RFN SDCCH TA
: Random access information value : Reduced frame number : Description of the allocated SDCCH (Standalone Dedicated Control Channel) : Timing advance
Figure 29: Immediate Assignment

The BTS sends the immediate_assignment message to the mobile station on the AGCH. The mobile station checks the random number and frame number in the immediate_assignment message. If it matches those from one of its last three channel_request messages, the mobile station switches to the indicated SDCCH and sets its timing advance to the value indicated in the immediate_assignment message.
3.2.1.4 Immediate Assignment Reject

When there is congestion on the SDCCH, the mobile station could retry repeatedly without success to access a channel. This produces the following undesired effects: Undesirable messages on the mobile station screen The subscriber has to restart his call attempt manually Repeated futile attempts to connect overload the RACH and Abis Interface "Ping-pong" cell reselection by the mobile station.
105 / 262
3 Call Set Up
Therefore, the system implements a special immediate_assignment_reject message when the following conditions are met: The BSC flag EN_IM_ASS_REJ is set to true. This flag is set on a BSC basis, and can be viewed but not modified from the OMC-R All SDCCHs in the cell are busy. The BSC receives a channel_required message from the BTS with one of the following establishment causes: Emergency call Call re-establishment Mobile station-originating call Location update Service Calls. The immediate_assignment_reject message is contained in the information element of the immediate_assign_command message. This message starts a timer in the mobile station which causes it to wait in idle mode until the timer expires, before sending new channel_request messages. The length of the timer is dependent upon the establishment cause, and can be set by the user. If an immediate_assign_command message is received before expiration of the timer, it has priority and the mobile station will respond to it, thus connecting the call.
Note:
This message cannot be used when the mobile station is responding to paging, i.e., in the case of a mobile-terminated call.
3.2.1.5 Immediate Assignment Extended

Under peak load conditions, it is likely that the mobile station will send several channel_request messages before receiving an immediate_assignment message indicating that a channel has been allocated to it. At this stage, the BSC is unable to identify the mobile station which sent a given channel_request and so it will grant several SDCCHs to the same mobile station, thus wasting resources and reducing throughput on the AGCH. If several immediate_assignment messages are queued on the AGCH, the BTS will try to build an immediate_assignment_extended message, passed to the mobile station on the Air Interface, constructed from pieces of two immediate_assignment messages as follows: The first immediate_assignment message in the queue (i.e., the oldest) The first of the remaining immediate_assignment messages in the queue, which are able to be merged according to one of the following criteria: At least one of the two allocated channels is non-hopping If both allocated channels are hopping, they share the same Mobile Allocation (see Baseband Frequency Hopping (Section 4.3.1) for more information about Mobile Allocation). If there are several immediate_assignment messages in the AGCH queue, but the first one cannot be merged with any other in the queue (using the above criteria), a "classic" immediate_assignment message is sent on the Air Interface.
106 / 262
3 Call Set Up
3.2.1.6 Set Asynchronous Balanced Mode

The first Layer 2 frame sent on the SDCCH is a standard LAPDm type frame, known as the Set Asynchronous Balanced Mode. This is equivalent to the Set Asynchronous Balanced Mode Extended frame in the LAPD. On the Air Interface, it establishes the LAPDm connection with the BTS. This frame can also contain Layer 3 messages.
3.2.1.7 Contention Resolution

The mobile station starts its LAPDm connection and sends a Layer 3 message in its first frame. The BTS uses this message for contention resolution. The BTS sends an acknowledgment to the mobile station containing the same Layer 3 message. Therefore, only the mobile station that sent the message can accept the acknowledgment from the BTS and consider itself connected. The following figure shows the establishment of the connection for a mobile originated call.
MS
SABM + cm + Se rvice Requ est
UA
Request Service
BTS
BSC
MSC
Establish Indication cm + Serv ice Reques t
SCCP Co nnection Request cm + Serv ice Reques t
nnecti SCCP Co
irm on Conf
cm Service Request UA
: Classmark : Initial Layer 3 message including the mobile station identity and classmark : Unnumbered acknowledgment
Figure 30: Connection for Mobile-Originated Call

For a mobile-originated call, the Layer 3 message from the mobile station contains: An Information Element indicating: CM service request (speech/data, SMS, emergency call) Location updating request (location updating procedure) CM re-establishment request (after a failure) IMSI detach indication (mobile station power off - see IMSI Attach-Detach (Section 3.3.5) for more information). The mobile station identity (see Authentication (Section 3.7) for more information) The mobile station classmark (see Classmark Handling (Section 3.6) for more information). The network uses this message to decide which call negotiation procedures are required and whether to assign a traffic channel.
107 / 262
3 Call Set Up
3.2.1.8 Establish Indication

The BTS sends an establish_indication message to the BSC to indicate that the mobile station has connected. The BSC stops the guard timer, extracts the classmark information, and initiates an SCCP connection with the MSC.
3.2.1.9 SCCP Connection

The BSC sends an SCCP_connection_request message to the MSC. The MSC replies with an SCCP_connection_confirm message. This message can contain a classmark request or a cipher mode command. The signaling link is established between the mobile station and the MSC.
3.2.2 Authentication and Ciphering

The content of the classmark IE sent during radio and link establishment depends on the type of mobile station. The classmark information is used for mobile station power control and to set ciphering. The MSC can request a classmark update to ensure that it has the correct information. Classmark procedures are described in Classmark Handling (Section 3.6). The authentication procedure: Authenticates the mobile station identity Checks the mobile station has the correct Individual Subscriber Authentication Key value on the SIM for the ciphering procedure Sends the Random Number for the ciphering and authentication procedures. This procedure is described in Authentication (Section 3.7). Information passed on the Air Interface must be protected. The MSC can request that the BSS set the ciphering mode before information is passed on the SDCCH. Ciphering is described in Ciphering (Section 3.8).
108 / 262
3 Call Set Up
3.2.3 Normal Assignment

Figure 31 shows the normal assignment process for a mobile originated call. Once the Radio and Link Establishment procedure has been successfully completed, the mobile station has a signaling link with the network. If the call requires a traffic channel to communicate with a called party, the mobile station sends a setup message. This indicates the teleservice and bearer service required, and the called party number. The information is sent transparently through the BSS. This message can contain more than one bearer service element, and a parameter indicating that the subscriber may request a change of service (In-Call Modification) during the call. See In-Call Modification (Section 4.2) for more information. The MSC sends a call_proceeding message to the mobile station. This indicates that the call parameters have been received, and that attempts to establish communication with the called party are under way.
3.2.3.1 Channel Request

The MSC initiates the assignment of the traffic channel by sending the assignment_request message and sets a timer to supervise the response from the BSC. The BSC checks the message which must contain a channel type (for a traffic channel this is speech or data plus data rate). This message also contains the mobile station classmark which the BSC uses if it has not received the classmark from the mobile station. The assignment_request message may contain a codec list, giving, in order of preferences, the type of codec it prefers to use (for example, one that supports enhanced full-rate speech). In this case, the BSC checks the list against those supported by the cell, and chooses the preferred codec type that can be used by both the BTS and by the mobile station.
109 / 262
3 Call Set Up
If the BSC finds an error in the assignment_request message, it sends an assignment_failure message. If no error is detected, it starts the normal assignment procedure towards the mobile station.
MS
set up
BTS
(SDCCH) layer 3 CC
BSC
layer 3 CC
layer 3 CC
MSC
tele/bearer ser vice called party no.

layer 3 CC
call proceeding
TCH allocation
request context physical
est nt requ assignme +cm l type channe
physical context co nfirm power + TA
(SACCH
pdates ower u 6 TA + p fo 5 e + sys in
on activati channel pher i TA + c r TCH + + powe + DTX channel activati on acknow ledge d comman ment assign
assign
mman ment co
CH d (SDC
release SDCCH
SABM ( FACCH) establis CH) UA (FAC h indica tion
Set transcoder
assignme nt comp lete (F ACCH)
Set switching path
assignme
nt comp lete
layer 3 CC
layer 3 CC
initiate SDCCH release alerting

connect
layer 3 CC
layer 3 CC
connect acknowledgement
layer 3 CC
cipher cm DTX TA
: Encryption algorithm + ciphering key : Classmark : Discontinuous transmission flags : Timing advance
Figure 31: Normal Assignment for Mobile-Originated Call
110 / 262
3 Call Set Up
3.2.3.2 Traffic Channel Allocation

The BSC ensures that it is not running any other procedures for the mobile station and then allocates resources for the traffic channel. The resources allocated are calculated using an algorithm in the BSC. The BSC can receive an assignment_request message in various situations. Therefore, it has traffic channel resource allocation algorithms for: Normal assignment In-call modification Intercell handover Intracell handover Directed retry Concentric cells Microcells. In normal conditions (mobile-originated call, normal assignment), the normal assignment algorithm is used. The BSC keeps a table of idle channels in which the channels are classified by their interference level (1 = low, 5 = high). The interference level of all free channels is monitored by the BTS. This information is periodically sent to the BSC in the RF_resource_indication message. The BSC does not automatically allocate a channel from the lowest interference level, as a number of channels can be reserved for handover. After all reserved channels are accounted for, the channel allocated is from the lowest interference level. If the number of reserved channels exceeds the number of free channels, then the BSC allocates a channel from the highest interference level. If no channels are available, the BSC sends an assignment_failure message to the MSC indicating the cause of the failure.
111 / 262
3 Call Set Up
3.2.3.3 Traffic Channel Activation

The BSC sends a physical_context_request message to the BTS, to find out the current power and timing advance being used by the mobile station on the SDCCH. The BTS responds with a physical_context_confirm message, containing the relevant information. If no channel is available, and queuing is enabled, the call is placed in the queue. Refer to Congestion (Section 3.5) for more about queuing. The following figure shows the channel activation process for the traffic channel.
MS
BTS
BSC
TCH allocation
MSC
physical co ntext conf irm

power + TA
channel
) (SACCH
activati
on
pher TA + ci TCH + r + powe + DTX
dates wer up TA + po 5&6 sys info +
channel
activati
on acknow le
dge
and nt comm assignme

and nt comm (SDCCH)
assignme
cipher DTX MS TA TCH
: Encryption algorithm + ciphering key : Discontinuous transmission flags : Mobile Station : Timing advance : Traffic Channel
Figure 32: Channel Activation Process for the Traffic Channel

The BSC sends a channel_activation message to the BTS. This contains: A description of the traffic channel to be used The mobile station timing advance to be applied The encryption algorithm and ciphering key (same as for SDCCH assignment) A Discontinuous Transmission indicator for uplink (not used) and downlink (see Speech Transmission (Section 4.4) for more information) The mobile station power to be used (see Radio Power Control (Section 4.5) for more information) The BTS power to be used. The BSC starts a timer, and waits for the BTS to acknowledge that it has activated the channel.
112 / 262
3 Call Set Up
The BTS initializes its resources for the traffic channel, sets the ciphering mode, sends timing advance and power information to the mobile station on the SACCH associated with the traffic channel, which is constantly monitored by the mobile station. At the same time, the BTS sends a channel_activation_acknowledgment message to the BSC. The BSC stops its timer and sends an assignment_command message on the SDCCH to the mobile station. This instructs the mobile station to change to the traffic channel. When the mobile station receives the assignment_command message, it disconnects the physical layer, and performs a local release to free the LAPDm connection of the SDCCH.
3.2.3.4 Traffic Channel Assignment

The following figure shows the channel assignment process for the traffic channel. MS BTS BSC MSC
release SDCCH
SABM (F ACCH)
establis h indica ti
CCH) UA (FA
assignme nt comp lete (F ACCH)
Set transcoder
on
Set switching path
assignme
nt comp lete
FACCH MS SABM UA
: Fast Associated Control Channel : Mobile Station : Set Asynchronous Balanced Mode : Unnumbered Acknowledgment
Figure 33: Channel Assignment Process for the Traffic Channel

The mobile station then establishes the LAPDm connection (via the SABM on the FACCH) for the traffic channel. The BTS sends an establish_indication message to the BSC. It also sets the Transcoder and its radio link failure detection algorithm. The BTS sends a Layer 2 acknowledgment to the mobile station. The mobile station sends an assignment_complete message to the BSC. When the BSC receives the establish_indication message, it establishes a switching path between the allocated Abis and A Interface resources. When it receives the assignment_complete message, it sends an assignment_complete message to the MSC and initiates release of the SDCCH (see Call Handlingfor more information).
113 / 262
3 Call Set Up
3.2.3.5 Connecting the Call

Once communication with the called party is established (but before the call is answered), the MSC sends an alerting message to the mobile station. The mobile station generates a ring tone. When the called party answers, the MSC sends a connect message to the mobile station. The mobile station responds with a connect_acknowledgment message. The call is established. The following figure shows the call connection process for a mobile originated call.
MS BTS BSC initiate SDCCH release MSC
layer 3 CC
layer 3 CC
alerting
layer 3 CC
layer 3 CC
connect
connect acknowledgement
layer 3 CC
MS SDCCH
: Mobile Station : Standalone Dedicated Control Channel
Figure 34: Call Connection for Mobile-Originated Call
3.2.3.6 Off Air Call Set Up

OACSU is a method available in the BSS where the network assigns a traffic channel only when the called party has answered the call. This improves the efficiency of traffic channel allocation as unsuccessful calls will not take up any traffic channel resources. This feature is controlled by the MSC. Practically speaking, the way this happens is the Layer 3 alerting message is sent by the MSC just after the call_proceeding message. The mobile station then enters the ringing phase. The assignment_request message is not sent by the MSC until the called party answers. The rest of the Layer 3 exchanges between MSC and BSC take place after the mobile station sends the assignment_complete message to the MSC. When OACSU is in use, the mobile station may provide internally generated tones to the user (in a Mobile-Originated call) during the ringing phase, as the traffic channel is not yet available for tones or in-band announcements to be sent. This feature increases the probability of an internal (SDCCH-to-SDCCH) handover being initiated by the BSS while the Normal Assignment procedure is being initiated by the MSC.
114 / 262
3 Call Set Up
3.3 Mobile-Terminated Call

A call from the NSS to a mobile station can be either a call routed through the NSS from a calling party, or it can be initiated by the NSS for mobility management. A mobile-terminated call set up follows the same basic procedures as a mobile-originated call. This section describes only those procedures which are different. The following figure shows radio and link establishment for a mobile-terminated call.
MS
BTS
BSC
paging
TMSI/IMS list I + cell
MSC
request paging I TMSI/IMS
(PCH)
group + I paging TMSI/IMS nel number chan
comman paging
channel request
(RACH)
channel
required
IMSI MS PCH RACH TMSI
: International Mobile Subscriber Identity : Mobile Station : Paging Channel : Random Access Channel : Temporary Mobile Subscriber Identity
Figure 35: Radio and Link Establishment for Mobile-Terminated Call
115 / 262
3 Call Set Up
3.3.1 Radio and Link Establishment

Before the BSS sets up a signaling link, the mobile station has to be paged. This procedure is initiated by the MSC. It sends a paging message to the BSC controlling the location area from which the mobile station last performed a location update. This message is sent in connectionless mode and contains: The mobile station identity (TMSI or IMSI of the mobile station to be paged) A cell identifier list which identifies the cells where the paging request is to be sent. This could be all cells or a group of cells. The MSC sets a timer to wait for a paging_response message from the mobile station. The BSC checks the paging message and, if valid, calculates the mobile station paging group and the CCCH time slot for the paging group. The BSC sends a paging_command message to each BTS, indicating the TMSI or IMSI, the paging group and the channel number. Each BTS formats the information and broadcasts a paging_request message on the Paging Channel. The mobile station listens to messages sent to its paging group. When it receives a paging message with its mobile station identity, it sends a channel_request message on the RACH to the BTS, indicating that the request is in response to a paging_request message. The BSS then performs the radio and link establishment procedure described in Mobile-Originated Call (Section 3.2).
Note:
When the mobile station sends the SABM, it indicates that the connection is in response to a paging request. For more information about paging, see Paging (Section 3.4).
3.3.2 Authentication and Ciphering

The system handles authentication and ciphering for a mobile-terminated call in the same manner as a mobile-originated call. Refer to Authentication and Ciphering (Section 3.2.2). Refer to Classmark Handling (Section 3.6) for more information about the classmark, Authentication (Section 3.7) for more information about authentication, and Ciphering (Section 3.8) for more information about ciphering procedures.
116 / 262
3 Call Set Up
3.3.3 Normal Assignment

The normal assignment procedure for a mobile-terminated call is initiated by the MSC. This is shown in the figure below. The MSC sends a Layer 3 Call Control set_up message to the mobile station, indicating the bearer service and teleservice to be used for the call. The MSC can indicate more than one bearer service. The mobile station checks this message. If it can accept the call, it sends a call_confirmation message which can contain a bearer capability parameter indicating which bearer service is preferred. The BSS performs the physical context and channel assignment. This is described in Normal Assignment (Section 3.2.3). Once the traffic channel is assigned, the mobile station alerts the user and sends an alerting message to the MSC. When the mobile station user answers, the mobile station sends a connection message to the MSC. The MSC sends a connection_acknowledgment message to the mobile station and connects the call. All these messages are Layer 3 Call Control messages, and are transparent to the BSS.
MS SDCCH
Figure 36: Normal Assignment for Mobile-Terminated Call
117 / 262
3 Call Set Up
3.3.4 Off Air Call Set Up

If OACSU is in use, it is possible that at one moment the called party may have answered the call, but the traffic channel is still not assigned by the network (for example, the call is queued). In this case the mobile station may supply tones to the answering user, so that the user does not hang up before the Normal Assignment procedure completes.
3.3.5 IMSI Attach-Detach

IMSI Attach-Detach is a mobility feature which primarily concerns the MSC and the mobile station. Used together with the periodic location update procedure, IMSI Attach-Detach allows the network to provide more efficient control and use of resources. For example, if a mobile-terminated call arrives for a mobile station which is "detached", the MSC knows that the mobile station is not active and does not need to start a paging request. For the BSS, this can reduce load on the PCH. Initiation of the IMSI Attach-Detach procedure is controlled by a parameter in the BSS, attach_detach_allowed. When this parameter is set, the BSS broadcasts system information on all cells indicating that the network supports IMSI Attach-Detach. Mobile stations which have successfully connected and logged themselves onto the network are then obliged to perform IMSI Attach-Detach procedures. Refer to documentation supplied with mobile stations which support this function. For more information about the attach_detach_allowed parameter, see the A1353-RA Configuration Handbook. IMSI Attach-Detach is also used for other functions at the MSC. Refer to documentation for your networks MSC equipment.
118 / 262
3 Call Set Up
3.4 Paging
Paging is the procedure by which the network contacts a mobile station. For example, if the network needs to inform the mobile station of an incoming call, it pages the mobile station to prompt it to request a channel. After the immediate assignment procedure, the service_request message from the mobile station indicates that the connection is in response to a paging message. Paging messages are sent on the CCCH. The downlink CCCH carries the AGCH and the PCH. The PCH is divided into sub-channels, each corresponding to a paging group. To save the mobile station from monitoring every occurrence of the PCH, each mobile station is assigned a paging group calculated from the IMSI. Each mobile station calculates its paging group and monitors only that PCH sub-channel. This saves mobile station battery power. The number of paging groups and the CCCH organization varies for each configuration. The mobile station knows the CCCH organization from the information passed on the BCCH (sys_info 3). The AGCH sends the immediate_assignment message to the mobile station. A number of blocks can be reserved for the AGCH using the BS_AG_BLKS_RES parameter. If this parameter is set to 0, then the immediate_assignment message is sent on the PCH. The following figure shows a TDMA frame with nine CCCH blocks, three of which are reserved for the AGCH and the rest for the PCH. The parameter to reserve these blocks is set to BS_AG_BLKS_RES = 3.
TDMA Frame Cycle
CCCH0
CCCH1
CCCH2
CCCH3
CCCH4
CCCH5
CCCH6
CCCH7
CCCH8
Reserved for AGCH
Available for PCH channels
AGCH CCCH PCH TDMA
: Access Grant Channel : Common Control Channel : Paging Channel : Time Division Multiple Access
Figure 37: CCCH with Three Blocks Reserved for AGCH
119 / 262
3 Call Set Up
In the example shown in the figure above, BS_AG_BLKS_RES is set to three. Every occurrence of the TDMA frame cycle carrying the CCCH has three AGCHs and six PCHs. However, more than six paging groups can be defined by assigning a different group of six PCHs to a number of TDMA multiframe cycles. This is specified using the parameter BS_PA_MFRMS, as shown in the following figure.
First TDMA Frame cycle
AGCH
AGCH
AGCH
PGR0
PGR1
PGR2
PGR3
PGR4
PGR5
Second TDMA Frame cycle
AGCH
AGCH
AGCH
PGR6
PGR7
PGR8
PGR9
PGR10
PGR11
Third TDMA Frame cycle
AGCH
AGCH
AGCH
PGR12
PGR13
PGR14
PGR15
PGR16
PGR17
Fourth/1 TDMA Frame cycle
AGCH
AGCH
AGCH
PGR18
PGR19
PGR20
PGR21
PGR22
PGR23
These four TDMA frames represent 24 PCHs. The parameter to reserve these is BS_PA_MFRMS =4
AGCH PGR PCH TDMA
: Access Grant Channel : Paging Group : Paging Channel : Time Division Multiple Access
Figure 38: Four TDMA Frame Cycles Providing 24 Paging Sub-channels
120 / 262
3 Call Set Up
3.4.1 Paging Control

The MSC has to initiate the paging procedure, as it holds the information on the last mobile station location update. The MSC sends the paging message to the BSC(s) and sets a timer for the paging_response from the mobile station, which is sent as part of the service_request message after the immediate assign procedure. The paging message from the MDC contains a cell list identifier IE, identifying the cells in which the paging message is to be transmitted. The BSC checks the cell identifier list and builds a paging_command message for the relevant BTSs. The following table shows the different cell identification lists and the paging performed by the BSC. Cell List Identifier No IE present Paging Performance Paging performed in all cells controlled by BSC Paging performed in all cells controlled by BSC Paging performed in all cells controlled by BSC Paging performed only in those cells specified Paging performed in all cells of each location area specified
IE indicates all cells
Error in IE
IE indicated specific cell(s)
IE indicates specific location area(s)
Table 19: Cell List Identifier and Paging Performed

The BSC calculates the paging group of the mobile station for each cell and the CCCH time slot. It then sends a paging_command message to each BTS, indicating the CCCH time slot number, mobile station paging group and the mobile station identity (IMSI/TMSI). The BTS builds a paging_request_type_x message to send to the mobile station. There are three types of paging request messages, as the BTS can page more than one mobile station at a time. The following table shows the relationship between the paging message type, the number of mobile stations to be paged and the mobile station ID used. Paging Request Message Type_1, identifying up to two mobile stations.
Mobile Station Identification IMSI or TMSI (for one mobile station) IMSI, IMSI or TMSI, TMSI or IMSI, TMSI (for two mobile stations)
121 / 262
3 Call Set Up
Paging Request Message Type_2, identifying three mobile stations. Type_3, identifying four mobile stations.
Mobile Station Identification TMSI, TMSI, TMSI or TMSI, TMSI, IMSI TMSI, TMSI, TMSI, TMSI
Table 20: Paging Request Message and Mobile Station Identification

By using a combination of paging message types, several mobile stations can be simultaneously paged. This is done even if some mobile stations are paged using the IMSI and others are paged using the TMSI. The paging_request messages are stored in a buffer, while waiting to be sent on the relevant PCH sub-channel. If this buffer becomes full, the next paging_command message is discarded. When the mobile station receives the paging_request message, it sends a channel_request message to initiate the immediate assign procedure. The service request message following the immediate assign procedure indicates that the channel_request is in response to a paging request message. This is shown in the following figure.
MS BTS BSC MSC
st reque paging SI TMSI/IM

chan nel r eque
slot H time + CCC g group in + pag
paging
comm
and
paging t IE cell lis
st
chan
REF
SABM + serv ice req ue (pagin g resp st onse)
nel re
+ RF
quire
A
N+T
establi
sh indic
ation
CCCH IE IMSI MS REF RFN SABM TA TMSI
: Common Control Channel : Information Element : International Mobile Subscriber Identity : Mobile Station : Random access information value : Reduced frame number : Set Asynchronous Balanced Mode : Timing advance : Temporary Mobile Subscriber Identity
Figure 39: Paging Message Sequence
122 / 262
3 Call Set Up
3.4.2 Discontinuous Reception

Discontinuous Reception adds to the power-saving abilities of the system, extending mobile station autonomy under battery operation. The DRX feature implements a receiver off/on ratio of 98 to 2. When the mobile station is in idle mode, DRX allows the mobile station to switch off its receiver and data processing. Instead of the mobile station listening continually on the Paging Channel sub-channel of the CCCH for a paging message, it only listens to that part of the PCH which corresponds to its paging group. The PCH is split into a number of paging sub-channels, each of which serves the mobile stations of a particular paging group. The mobile station calculates its paging group and the part of the PCH it has to monitor. It gets the information from its IMSI, and from the Control Channel description sent on the BCCH (sys_info 3). The paging information is transmitted at predefined regular intervals. The mobile station only turns on its receiver to listen to its paging group and then turns itself off again. This occurs cyclically, between 0.95 seconds and 4.25 seconds, depending on the configuration of the cell. Apart from listening to the PCH, the mobile station monitors the home cells BCCH up to once every 30 seconds, and the top six neighboring cells up to once every five minutes. For more information about Paging, refer to Paging (Section 3.4).
123 / 262
3 Call Set Up
3.5 Congestion
To prevent an assignment_request or an external handover_request message being rejected, the BSS allows queueing of traffic channel requests. Congestion occurs when all traffic channels are busy for a particular cell and the message arrives at the BSC. Queueing is allowed if indicated by the MSC in the request message.
3.5.1 Queueing
Queueing is used to achieve a higher rate of successful call set up and external handover completion in cases of traffic channel congestion. This is achieved by queueing the request for a defined period of time. During this time a traffic channel can become available and the traffic channel assignment can then be completed. When all traffic channels of a cell are busy, assignment and external handover requests for traffic channel allocation can be queued, if: Requested by the MSC If the MSC allows queueing, this information and the priority of the request for queueing are sent in the Priority Information Element of the request. Configured in the BSC. The BTS can perform queueing if specified in the BSC configuration. BTS queueing can be enabled/disabled by an operator command through the OMC-R. Setting the BTS_Queue_Length parameter to 0 disables queueing. If either the MSC or BSC does not allow the request to be queued, the request is immediately rejected and an assignment_failure message is sent to the MSC.
124 / 262
3 Call Set Up
3.5.2 In-queue
If queueing is allowed, the request cannot be queued if one of the two queue limits is exceeded. These limits are: The maximum number of requests that can be queued per BTS if defined by the O&M parameter BTS_Queue_Length. The range is from 1 to 64. This can be individually set for each BTS The global limit of 64 queued requests in the BSS. The sum of all BTS queue lengths cannot exceed 64. When one of the queue limits is exceeded, the request may still be queued if there is a lower priority request in the queue. If the priority of the incoming request is higher than the lowest in the queue, the incoming request is queued and the oldest lowest priority request is then rejected. Once a request is queued, the BSC informs the MSC by sending a queueing_indication message. A timer is activated when the request is queued. If the timer expires or the request is preempted by a higher priority request, the request is rejected. Once in the queue, the request waits to be either accepted or rejected due to one of the following events: traffic channel availability or Forced Directed Retry.
3.5.2.1 Traffic Channel Availability

If another traffic channel disconnects within the cell, the request at the top of the queue is assigned to the newly available traffic channel. The request is removed from the queue. An assignment_complete message is sent to the MSC notifying it of the successful assignment of a traffic channel.
3.5.2.2 Forced Directed Retry

The BSC detects that the call can be supported on another cell, and implements Forced Directed Retry. If the BSC detects the possibility of a handover for the queued request, it generates an internal or external handover alarm and initiates the appropriate handover procedure. A handover from an SDCCH in the serving cell to a traffic channel in a target cell is known as directed retry. On detection of the handover alarm, the BSC cancels the queued request, stops the timer, and selects a neighbor cell in the target cell list. The target cell must be able to support the ciphering requirements of the call. Once a cell is selected, a traffic channel is chosen and a handover is attempted (SDCCH to traffic channel). If the handover fails, another cell is chosen from the target cell list. This procedure continues until a successful handover or the handover limit (number of handover attempts allowed) is exceeded. The MSC is notified of a successful handover by an assignment_complete message. The direct retry finishes if the number of handover attempts is exceeded, or there are no more cells left in the target cell list. Finally an assignment_failure message is sent to the MSC indicating that there are no radio resources available.
125 / 262
3 Call Set Up
3.5.2.3 Queue Pre-emption

If a higher priority request arrives in the queue, Queue Pre-emption is implemented. If one of the queue limits is exceeded and the request is the oldest of the lowest priority requests in the queue, the request is rejected. An assignment_reject message is sent to the MSC indicating that there are no radio resources available.
3.5.2.4 Timer Expires

If the timer expires, the request is de-queued and rejected. An assignment_reject message is sent to the MSC indicating that there are no radio resources available.
3.5.2.5 Fast Traffic Handover

Another possibility to save resources in case of traffic peaks is to force handovers toward neighbor cells which have less traffic. The fast traffic handover searches in the whole cell for a mobile which can perform a handover to a neighbor cell with less traffic if the received signal level of the BCCH is good enough. It is much more efficient than the forced directed retry when the overlap of adjacent cells is reduced, e.g., in the case of single layer networks, or for deep indoor coverage (if the umbrella cell does not overlap totally the microcells). Fast traffic handover is enabled on a per cell basis, by setting the EN_FAST_TRAFFIC_HO parameter to TRUE. Setting the EN_FAST_TRAFFIC_HO parameter to FALSE disables fast traffic handover for that cell. Fast traffic handover is enabled when all of the following conditions are met: A request is queued at the top of the queue. The request is of full-rate type for assignment or emergency external incoming handover, and is not in the HOLD state The parameter EN_FAST_TRAFFIC_HO is set to TRUE. The queued request is an assignment. If it is an external incoming handover, it is an emergency handover to trigger the algorithm; otherwise the algorithm is not triggered.
126 / 262
3 Call Set Up
3.5.3 Pre-emption
Pre-emption is an optional feature and is initiated during congestion periods. The feature allows radio resources in a cell to be allocated to those calls which are deemed to be the most important. The importance of the connection is given by the MSC to the BSC via signaling on the A Interface. During congestion periods, the BSC ensures that high priority transactions obtain the resources they require. The BSC performs a release of radio resources in order to obtain the radio resource for the higher priority call. For Phase 1 and Phase 2 GSM, the signaling for priority and pre-emption exists on the A Interface. The setting of this data on the A Interface is controlled by the MSC. The conditions under which the information is set is up to operator choices. For Phase 2+ GSM, the priority and pre-emption information is based on subscription data which is stored in the HLR and downloaded to the VLR via MAP protocols. This information can also be used by the MSC when setting the priority level and pre-emption attributes for the call. The pre-emption attributes of a call are defined by three bits: pci: The pre-emption capability indication indicates if the transaction can pre-empt another transaction pvi: The pre-emption vulnerability indication indicates if the transaction can be pre-empted prec: The pre-emption recommendation. This is needed in order to defer pre-emption until a suitable non-congested cell is found in the preferred cell list. The pre-emption recommendation is used when the old BSS recommends that another connection be pre-empted. Pre-emption is applied to the TCH only. The pre-emption feature is optional and controlled by the O&M parameter (EN_TCH_PREEMPT) on a per-BSC basis. The BSC provides pre-emption of TCH radio resources. This takes into account the priority of the call. The lowest lower priority call with the pvi bit set is pre-empted and thus released. Directed retry and/or forced handover in order to avoid pre-emption is not supported.
3.5.3.1 eMLPP
Enhanced Multi Level Priority and Pre-emption (eMLPP) is a supplementary service that allows a subscriber in the fixed or mobile network to initiate calls that have a priority and pre-emption attribute known to all the network elements. The eMLPP standardization provides the transportation of the subscription information for priority and pre-emption on MAP. This subscription information is stored in the HLR and the GCR and is transported to the VLR. This information is used for the following procedures: Paging TCH Assignment TCH Handover. Only TCH pre-emption is supported (i.e., only for circuit-switched services).
127 / 262
3 Call Set Up
3.5.3.2 Pre-emption Rules

An Assignment Request message with pci=1 and priority level=p1 will pre-empt an on-going call with pvi=1 and priority level=p2 (p2 is lower than p1). A Handover Request message with pci=1 and priority level=p1 will pre-empt an on-going call with pvi=1 and priority level=p2, except if the prec bit is present and set to 0 (i.e., the old BSS does not recommend the pre-emption of an on-going call to be performed by the target BSS). In both cases, the call with the lowest priority level=p2 value is selected first, and if several calls have the same lowest priority level=p2 value, one of them with the pci bit set to 0 is preferred.
3.6 Classmark Handling

The mobile station classmark contains information about the mobile station type and capabilities. This information is used by the BSS when implementing procedures that affect a mobile station, such as: Handover Power Control Ciphering Overload Control Location Updating. Mobile stations of different types have different capabilities within the network. It is essential that the network recognizes the mobile station classmark when initiating procedures for a specific mobile station. There are three entities that provide classmark handling as shown in the following table. Entity BSS Classmark Handling Performed by the BSC, which is responsible for collecting the classmark data needed to perform procedures on the mobile station. Indicates the mobile station classmark data to the BSC for MSC-initiated procedures. The BSS is informed of any classmark changes and information is sent on request from the BSS.
MSC
Mobile station
Table 21: Classmark Handling
Note:
The BSS can receive mobile station classmark information from both the MSC and the mobile station. The information from the mobile station overrides information from the MSC.
128 / 262
3 Call Set Up
3.6.1 Classmark IE
The Alcatel 900/1800 BSS supports classmark 1, classmark 2 and classmark 3 IEs. Classmark 1 IE is always sent to the BSS when the mobile station tries to establish communication. Classmark 1 The Classmark 1 IE contains: The revision Level The RF Power Level Support of A5/1 Encryption. Classmark 2 The Classmark 2 IE is defined in GSM to allow the coding of phase 2 capabilities such as the A5/2 ciphering algorithm. The classmark contains the same elements as Classmark 1 IE, plus support of A5/2 encryption. Classmark 3 The Classmark 3 IE is defined in GSM to allow multiband mobile stations to indicate their capabilities. The classmark specifies the supported bands and the respective power classes.
3.6.1.1 Classmark IE Fields

The fields contained in a classmark IE are described in the following table. This field... Revision Level Indicates... either a phase 1 or phase 2 mobile station. It does not distinguish between phase 1 and phase 1 extended mobile stations. If there is an error in this field, then a default phase 1 is assumed.
129 / 262
3 Call Set Up
This field... RF Power Level
Indicates... the mobile station power capability. For Alcatel 900: Class 1 = 20 W Class 2 = 8 W Class 3 = 5 W Class 4 = 2 W Class 5 = 0.8 W For Alcatel 1800: Class 1 = 1 W Class 2 = 0.25 W The value is not permitted if there is an error in this field. The result of this is that the mobile station power capability is assumed to be the same as the maximum transmit power allowed in the cell.
Support of A5/1 Encryption
whether the mobile station supports the A5/1 encryption algorithm. If the A5/1 encryption algorithm is not supported, there is no indication of other algorithms being supported. whether the mobile station supports the A5/2 encryption algorithm. If the A5/2 encryption algorithm is not supported, there is no indication of other algorithms being supported.
Support of A5/2 Encryption
Table 22: Classmark IE Field Description
130 / 262
3 Call Set Up
3.6.1.2 Impact on BSS and MSC

The main difference between classmarks 1 and 2 for the BSS or MSC is the support of the encryption algorithm. For procedures that require ciphering, the BSS and MSC cannot recognize the mobile station ciphering capability if only Classmark 1 IE was received. Therefore, there is a classmark updating procedure. Similarly, for classmark 3, the BSS and MSC do not recognize the mobile stations multiband capabilities if only a Classmark 1 IE was received. Therefore, a classmark updating procedure is required.
3.6.2 Classmark Updating

Further classmark information may be required by the BSS or MSC when initiating a procedure which needs to encrypt information. The mobile station can also send updated information if, for example, its power capability changes. Therefore, updating of classmark information can be initiated from the: Mobile station by sending a classmark_change message to the BSC which sends a classmark_update message to the MSC. BSC by sending a classmark_enquiry message through the BTS to the mobile station. The mobile station responds with a classmark_change message. MSC by sending a classmark_request message to the BSC. This prompts the BSC to send a classmark_enquiry message to the mobile station which responds with a classmark_change message. The classmark_change message from the mobile station is passed through the BTS to the BSC. The BSC stores the information for its own use and forwards the information to the MSC. Depending on the network type and configuration, the classmark update is not always required. Therefore, the BSS has a parameter in the BSC (parameter Send_CM_Enquiry) which can be configured. The following table shows the possible configurations. Parameter Value 0
Action The classmark_enquiry message is never initiated by the BSC. The BSC always initiates a classmark update when it receives a location update request. The BSC only initiates a classmark update on reception of a location update request if A5/1 is not available. This is worked out from the classmark 1 IE.
Table 23: Classmark Configuration

If the system requests a classmark update to a phase 1 mobile station, the mobile station is not able to respond. It considers the message an error and sends an RR_status message. This message is ignored by the BSS and is not passed to the MSC.
131 / 262
3 Call Set Up
3.6.3 Location Updating with Classmark Procedure

If the mobile station is a phase 1 extended or phase 2 mobile station, it can send classmark update information on request from the BSS or MSC. Because the BSS does not know the mobile station ciphering capability from the classmark 1 IE, updating is required. This is received when the mobile station establishes the LAPDm connection, as shown in the following figure.
MS
channel req uest
(RACH) channel req uired
BTS
BSC
MSC
switch to SDCCH
SABM + rn + fn + cm
establish ind ication
SCCP connec tion
(FACCH/S
ACCH)
y k enquir classmar
nnecti SCCP co
on
6 info 5 & TA + sys power +
confirm
classmark change
classmark 2IE
classmark update
classmark 2IE
location update
(SDCCH)
cm FACCH IE MS RACH SABM SACCH SCCP SDCCH TA
: Classmark : Fast Associated Control Channel : Information Element : Mobile Station : Random Access Channel : Set Asynchronous Balanced Mode : Slow Associated Control Channel : Signal Connection Control Part : Standalone Dedicated Control Channel : Timing advance
Figure 40: Location Update with Classmark Update

1. The mobile station initiates a location update procedure by sending a channel_request message on the RACH. 2. The BSS performs the immediate assign procedure, as described in Mobile-Originated Call (Section 3.2). 3. The mobile station establishes the LAPDm link and sends the location update request and classmark 1 IE. The BTS sends an establish_indication message to the BSC, containing the location update request and classmark 1 IE. 4. The BSC uses the classmark to send mobile station power control information to the BTS to start power control. It stores the classmark information and requests an SCCP connection with the MSC. 5. When the BSC receives an SCCP_connection_confirm message, it sends a classmark_enquiry message to the mobile station.
132 / 262
3 Call Set Up
6. The mobile station responds with a classmark_change message containing the classmark 2 IE. This information is passed to the MSC in a classmark_updating message. If the mobile station is a phase 1 mobile station, it responds with an RR_status message which is ignored by the BSS. In this case, the BSS sets ciphering with the information available from the classmark 1 IE. 7. The MSC initiates the authentication procedure and on receipt of the authentication response message, initiates the ciphering procedure. Refer to Ciphering (Section 3.8) for more information about ciphering. 8. When ciphering is set, the MSC can accept the location update.
3.7 Authentication
The authentication procedure ensures that the subscriber identification (IMSI, TMSI) and the IMEI are valid. The system behavior for non-valid identifications is at the discretion of the Network Operator. The procedure also validates the Ki value in the mobile station, and sends the RAND which is used to calculate the ciphering key.
3.7.1 IMSI/TMSI
When the subscriber accesses the network for the first time, the subscription is identified by the IMSI sent in the location_updating_request message. When the NSS has performed authentication and set the ciphering mode, the VLR assigns a TMSI, in an encrypted format over the Air Interface. The next time the subscriber connects to the system, it uses the TMSI as its identification. If the mobile station has changed location area, it includes the old Location Area Identity. The new VLR interrogates the old VLR for the authentication information (IMSI and Ki value). The new VLR then assigns a new TMSI. This is shown in the figure below. New TMSIs can be assigned by the serving VLR at any time. The subscriber identity is secure because the TMSI is always ciphered and changed regularly.
BTS Mobile Station
BSC
MSC
VLR
Mobile Station moving and connecting in a new location area
info request
IMSI + Ki
service request + TMSI + old LAI new TMSI BTS Mobile Station BSC
MSC
VLR
IMSI Ki LAI TMSI VLR
: International Mobile Subscriber Identity : Individual Subscriber Authentication Key : Location Area Identity : Temporary Mobile Subscriber Identity : Visitor Location Register
Figure 41: Location Update with Mobile Station Sending Location Area Identity of Previous VLR
133 / 262
3 Call Set Up
3.7.2 Authentication Procedure

1. The authentication procedure is initiated by the NSS. It sends an authentication_request message to the mobile station and sets a guard timer.This message contains: Parameters for the mobile station to calculate the response A ciphering key sequence number. The ciphering key is calculated from the authentication Key value assigned to the IMSI or TMSI and the value RAND. 2. The mobile station responds using the RAND and the value authentication Key assigned to its TMSI or IMSI.For mobile-originated calls, the mobile station uses: The TMSI, if available The IMSI, if no TMSI is assigned. For mobile-terminated calls, the mobile station uses the TMSI or IMSI as requested in the paging message from the network.For emergency calls, the mobile station uses: The TMSI, if available The IMSI, if no TMSI is assigned The IMEI, if there is no TMSI or IMSI. This can happen when there is no SIM in the mobile station. 3. When the mobile station sends the authentication_response message, the NSS stops its guard timer and validates the response.If the mobile station response is not valid, the network response depends on whether the TMSI or IMSI was used: If the TMSI was used, the network can request that the mobile station sends its IMSI If this is a valid IMSI, but is different from the IMSI that the network associated with the TMSI, the authentication procedure is restarted with the correct parameters If the IMSI is invalid, the network sends an authentication_reject message to the mobile station.
3.8 Ciphering
Ciphering is supported in the Alcatel 900/1800 BSS to protect information transmitted on the Air Interface. This includes: Subscriber information such as the IMSI User data SMS and SS data Information such as called and calling party numbers.
134 / 262
3 Call Set Up
Ciphering protects the information by using encryption. There are three different ciphering modes, the use of which depends on the mobile station classmark and the capability of the BTS. These modes are: Encryption using algorithm A5/1 Encryption using algorithm A5/2 No encryption. The two encryption algorithms are defined in GSM. If either is to be used, both the mobile station and BTS must have the same encryption capability.
3.8.1 Mobile Station Ciphering Capability

The mobile station ciphering capability depends on whether it is a phase 1 mobile station, a phase 1 extended mobile station, or a phase 2 mobile station. The following table shows the different mobile station ciphering capabilities. Mobile Station Type Phase 1 Phase 1 Extended Phase 2 Capability No encryption and A5/1 No encryption and A5/1 and A5/2 No encryption No encryption and A5/1 No encryption and A5/2 No encryption and A5/1 and A5/2
Table 24: Mobile Station Ciphering Capabilities

Only phase 2 mobile stations can turn off ciphering or change the ciphering mode during a channel change procedure such as a handover. The ciphering capability of a mobile station is signalled to the BSS in the mobile station classmark.
3.8.2 BSS Ciphering Capability

The Alcatel 900/1800 BSS supports both uniform ciphering network configurations and mixed ciphering network configurations. A cell can be configured to support one of the following: No encryption No encryption and the A5/1 algorithm No encryption and the A5/2 algorithm. A uniform ciphering network configuration is where all cells have the same ciphering capability. A mixed ciphering network configuration is where the cells have different ciphering capabilities.
135 / 262
3 Call Set Up
3.8.3 Ciphering Keys

The encryption used on the Air Interface is provided by the physical layer hardware. This means that it does not distinguish between signaling and user traffic; therefore, the entire bit stream is encrypted. The encryption pattern added to the bit stream is calculated by the algorithm A5/1 or A5/2, using a ciphering key. For maximum security, the value of the Ciphering Key is not a fixed value. It is calculated separately by the HLR, BSC and the mobile station for each call. This means that the value Kc is never transmitted on the Air Interface. The value Kc must be the same in the HLR, BSC and the mobile station. It is calculated using: A value Ki, which is assigned to the IMSI when the user subscribed to the service A RAND, sent from the MSC during the authentication procedure. The resulting value Kc is used to decipher the encrypted bit stream on the downlink, by the mobile station, and on the uplink, by the BTS.
3.8.4 Ciphering Process

3.8.4.1 Choosing the Ciphering Mode
The ciphering chosen by the BSC for a call depends on: The algorithms that the Network Operator allows in the network. This information is sent in the permitted_algorithm message from the MSC during ciphering or external handover procedures. The ciphering capability of the mobile station. This information is sent to the BSC in the mobile station classmark The ciphering capability of the BTS being used to set up the call. If the mobile station capability is not compatible with that of the BTS or is not allowed by the Network Operator, then the BSC sets ciphering with no encryption.
3.8.4.2 Setting the Ciphering Mode

The ciphering mode is set as follows: 1. Ciphering is initiated by the MSC by sending a cipher_mode command to the BSC. This command contains the permitted_algorithms message. 2. The BSC compares the permitted algorithms with the mobile station classmark and the BTS capability. If they match, the BSC sends an encryption_command message to the BTS containing the value Kc and the algorithm to be used. If there is no match and no encryption is permitted, the BSC sends the encryption_command to the BTS indicating no encryption. 3. If the BTS and mobile station capabilities are not compatible and the MSC does not allow the no encryption option, then the BSC sends a cipher_mode_reject message to the MSC.
136 / 262
3 Call Set Up
4. The BTS sends the ciphering_mode command on the SDCCH to the mobile station indicating the algorithm or no encryption. If encryption is to be used the BTS sets its decryption mode ready to receive encrypted frames from the mobile station. 5. The mobile station either: Starts the encryption and sends an encrypted Layer 2 acknowledgment message to the BTS. This prompts the BTS to start encryption mode for frames sent to the mobile station Sends an unencrypted level 2 acknowledgment to the BTS. 6. The mobile station sends a ciphering_mode_complete message to the BTS which is passed transparently to the BSC. The BSC sends a cipher_mode_complete message to the MSC. This process is shown in the following figure.
MS BTS BSC
e com man d
MSC
ciphe
od ing m
ciphe
od ing m
e com
man
m tion co encryp Kc or hm + lgoritncryption a no e
mand
perm
lgorit itted a
hms +
Kc
(SDCC
H)
algorithm or no encryption
cipher ing mo de com plete
cipher
mode
comple
te
MS SDCCH
Figure 42: Ciphering Process
3.8.4.3 Ciphering During Handover

Only phase 2 mobile stations can change ciphering mode during a handover. If a phase 2 mobile station using the A5/1 algorithm is handed over to a cell which supports A5/2 and no encryption, the BSC instructs the target BTS to set the new ciphering algorithm and sends the value Kc. If a phase 1 mobile station using the A5/1 algorithm needs to be handed over, the target cell must support A5/1, as the phase 1 mobile station cannot change ciphering mode. For mixed ciphering networks, it is normal that the initial cipher_mode command from the MSC only allows a phase 1 mobile station to use the no encryption option, as this is supported by all cells.
137 / 262
3 Call Set Up
3.9 Tandem Free Operation

Tandem Free Operation (TFO) provides better voice quality by avoiding unnecessary successive coding and decoding operations in the case of mobile-to-mobile calls. The importance of TFO is always increasing, as the percentage of mobile-to-mobile calls increases with the number of subscribers. Take the example of a call involving two mobile stations, MS 1 and MS 2. With the TFO feature, the same codec will be used on both BSS. This improves the speech quality of mobile-to-mobile calls, and particularly when using the half-rate codec. Without TFO One GSM coding and decoding scheme (codec), is used between MS 1 and Transcoder 1, then A/ law coding is used (at 64 kbit/s) between the two Transcoders and finally one GSM codec is used between Transcoder 2 and MS 2. This means a loss of quality for the speech call. With TFO. The intermediate transcoding realized by the two involved Transcoders is avoided. The same codec is used on both BSS. This improves the speech quality of mobile-to-mobile calls, particularly when using the half-rate codec. This allows a wide use of the half-rate codec, with a good level of speech quality, in order to save resources in BSS.
138 / 262
3 Call Set Up
3.9.1 TFO Process

TFO can be applied whenever the two mobile stations use the same codec. To satisfy this condition, after TCH allocation, the two BSS negotiate at each side a common codec (full-rate, half-rate or enhanced full-rate), by using an in-band protocol in the speech frame. The following figure shows an example of TFO call establishment.
BTS A
Channel activation TFO enabled TRAU frames CON_REQ DL_ACK TRAU frames TFO_REQ TFO_REQ TRAU frames
BSC A
TC A PCM samples
TC B
BSC B
Channel activation TFO enabled TRAU frames CON_REQ DL_ACK
BTS B
1 2 3 4
TFO_ACK
TFO_ACK
Codecs match
TFO_ON
TFO frames
TFO_ON
5
TFO REPORT (TFO STATUS= ON) TFO REPORT (TFO STATUS= ON)
PCM TC TFO TRAU
: Pulse Code Modulation : Transcoder : Tandem Free Operation : Transcoder Rate Adaptation Unit
Figure 43: Example of TFO Establishment

Referring to the figure above, the call establishment is as follows: 1. At call establishment, the BSC sends the channel activation message to the BTS, containing information related to TFO. 2. TRAU frames are exchanged between the BTS and the Transcoder. PCM samples are exchanged between the TRAUs. One TRAU frame is stolen from the BTS by the Transcoder, to send TFO configuration information (in the con_req message). 3. As soon as the TRAUs receive the information that TFO is enabled in the con_req message, (and also the TFO configuration information), they send the tfo_req message, within PCM speech samples, to indicate that the TRAUs are TFO-capable. Meanwhile, the TRAUs acknowledge the con_req message to the BTS with the dl_ack indication. 4. The TRAUs acknowledge that the tfo_req message has been received by sending a tfo_ack indication. 5. The same codecs are then used on both sides. The TRAUs can exchange TFO frames.
139 / 262
3 Call Set Up
6. The BTS are made aware of the exchange of TFO frames by tfo_on. The BSC is informed via a tfo_report message on the Abis Interface. The Alcatel TFO implementation is fully compliant with the GSM standard and additionally provides: As an operator choice, the Alcatel BSS is able to force the distant BSS (Alcatel or not) to overcome ETSI codec choice rules, in order to optimize voice quality and load management. This mechanism is patented by Alcatel Codec optimization, to take into account that the two mobile stations may use the same codec, but a better codec is available on both parts.
3.9.2 TFO Functional Architecture

The TFO procedure is defined between two TRAUs. When TFO is possible between two mobile stations, TFO frames (similar to TRAU frames) are transferred between the two TRAUs on the A Interface. These frames contain coded speech streams, and may also contain embedded TFO messages. They are supported by a 0.5 kbit/s signaling channel between two Transcoders, emulated during the TFO negotiation phase. This channel uses one bit (Least Significant Bit) every 16 PCM samples, regularly stolen on the 64 kbit/s circuit. Note that when TFO frames are transmitted, speech is nevertheless coded to G.711 law and sent to the A Interface on the remaining MSB bits of the PCM samples. This allows a faster reversion to normal operation mode if required. Moreover, lawful interception in the MSCs is still possible. The Alcatel solution avoids any Ater supplementary links, because the BSC-Transcoder TFO messages are exchanged through the BTS and the Abis Layer 3 protocol. When the same codec is used on both sides, no TFO negotiation is needed between the TRAUs. When the same codec is not used on both sides, TFO negotiation is needed between the TRAUs. In this case, TFO communication is possible between the two BSS, but the TRAUs do not use the same speech codec. TFO negotiation and resolution by the BSS are needed. When detecting the mismatch, each TRAU sends to the other (using TFO messages) the codec locally used, and the list of possible codecs. At each side, the BSS determines the matching codec. On each BSS, the same algorithm is implemented. This algorithm attempts to find a matching codec using the information given by the TRAU. If a common codec can be found, an internal intracell handover is performed to change the speech codec used locally, and TFO exchange of the speech stream begins. A logical parameter, configurable at the OMC-R, allows the BSC to ignore the load in the cell and to force the handover in order to solve codec mismatch situations. If no common codec can be found, or internal intracell handover is not possible, TFO mode is given up, and the system reverts to normal mode.
140 / 262
3 Call Set Up
3.9.3 TFO Optimization and Management

TFO is managed by the OMC-R operator, on a per cell basis. Several functions have been introduced to provide full control of TFO optimization, load regulation, speech quality, or Adaptive Multi-Rate (see Adaptive Multiple Rate (Section 6.2.8)) codec support.
3.9.3.1 TFO Optimization

For a better speech quality, TFO optimization allows a new TFO negotiation on an on-going TFO mobile-to-mobile call, to find a better common codec, in terms of speech quality. Therefore, enhanced full-rate coding is considered better than full-rate coding which is considered to be better than half-rate coding. The Enable TFO Optimization feature can be enabled or disabled per cell at the OMC-R. In some cases, both sides may use the same codec, but a better codec is available at each side and may be used (e.g., half-rate is used at both sides, but full-rate is possible). The procedure is then the same as the modification of speech codec in mismatch status, except that it takes place only when TFO frames are already exchanged. The TFO messages exchanged between both TRAUs are then embedded in TFO frames.
3.9.3.2 TFO Negotiation Control

For better traffic load regulation, Alcatel defined the function "Force TFO half-rate when loaded" to give control of load regulation precedence over TFO to the operator. This function can be enabled or disabled, per cell, at the OMC-R, and allows the BSC to take into account the load in the cell while building the list of supported codec types. If the cell is loaded, only half-rate (if possible) will be included in the list. If the distant BSS supports TFO but not half-rate, the function "Force TFO half-rate when loaded" allows the BSC in this case to recompute the list of supported codec types by inserting full-rate and enhanced full-rate in the list. Therefore, the function "Force TFO half-rate when loaded" leads to three different behaviors, depending on three possible values of the corresponding flag: TFO half-rate not forced. No filtering on the load is done. The load is not tested and all the codec types supported by the call and by the cell are listed in the supported codec type list TFO half-rate only. Filtering is done on the load, half-rate is forced if the cell is loaded and the mobile station supports half-rate, and if this codec type is authorized in the cell. The list of supported codec types is restricted to the half-rate codec type. As a consequence, if the distant side supports half-rate, then the distant side will do an intracell handover to use half-rate, and TFO will go on with half-rate. If the distant side does not support half-rate, TFO will not be possible TFO half-rate preferred. Filtering is done on the load, but TFO is preferred to half-rate. In the case of a load situation, only half-rate is sent in the list of preferred codecs. But if the distant BSS does not support half-rate, a new list is computed, without taking into account the load in the cell.
141 / 262
3 Call Set Up
142 / 262
4 Call Handling
4 Call Handling
This chapter provides an overview of Call Handling and describes the supervision of a call in progress.
143 / 262
4 Call Handling
4.1 Overview
An obvious requirement for the effective management of calls in the BSS is to provide the following: Maximum perceived signal quality with minimum perceived interference Call continuity regardless of changes in propagation conditions or change of location of the mobile station. Given that spectrum is limited, this must be accomplished with maximum resource reuse. Another important factor for the customer (and the operator as well) is power efficiency to reduce overall power consumption and prolong the autonomy of the mobile station under battery operation. The supervision of calls in progress is provided by the Call Handling function. Call Handling, with associated features, implements needed changes in the required teleservice to maintain call quality and continuity. Call Handling functions and features include: In-Call Modification Frequency Hopping Discontinuous Transmission Radio Power Control Handover Overload Control Call re-establishment by the mobile station.
4.2 In-Call Modification

In-call modification allows the teleservice to be changed during a call. This means that a call does not have to be cleared, and a new call established, if more than one teleservice is to be used. The different types of in-call modification are: Alternate between speech and a transparent data service Alternate between speech and a non-transparent data service Change from speech to a transparent data service Change from speech to a non-transparent data service Alternate between speech and transparent fax group 3 Alternate between speech and non-transparent fax group 3 Data rate change for transparent fax group 3 Data rate change for non-transparent fax group 3.
144 / 262
4 Call Handling
Calls requiring a change of service have to negotiate a dual-service before the normal assignment procedure. This is indicated in the set_up message, which is described in Call Set Up (Section 3).
Note:
Changing the data rate of a fax call is not a true in-call modification procedure, as the teleservice is not changed (no dual-service negotiation). The main difference between the in-call modification procedure and a change of data rate for fax are as follows: The in-call modification procedure is triggered by a message from the mobile station The data rate change for fax is triggered by in-band signaling from the fax machine to the MSC. Both procedures use existing resources, therefore no new resources need to be allocated. All full-rate traffic channels can be used for speech or data at any of the defined data rates. Both procedures use the mode modify procedure to change the transmission mode. This is basically a normal assignment procedure but instead of a new channel being assigned, a new mode is assigned.
4.2.1 In-Call Modification Procedure

In-call modification is initiated from a mobile station. This can occur during a call to a correspondent on the public telephone network or to a mobile station. For a mobile-station-to-mobile station call, both mobile stations must negotiate a dual service during call establishment. 1. The mobile station initiates the procedure by sending a Layer 3 Call Control modify message to the MSC, indicating the new mode. If the data call direction is different from the original call set up, then this message contains an indicator to reverse the call direction. The mobile station starts a guard timer for the procedure. 2. The MSC checks the modify message. If it can accept the mode change, it starts the normal assignment procedure by sending an assignment_request message and starting a guard timer. This message contains a channel type (speech or data plus data rate). 3. The BSS handles the normal assignment procedure as if assigning a traffic channel during call set up (described in Call Set Up (Section 3)), with the following exceptions: When the BSC has checked and accepted the assignment_request message, it does not assign a new traffic channel. This is because it already has a traffic channel assigned for the transaction. The transaction is identified by the SCCP connection on which the assignment_request message was received The channel_activation and channel_activation_acknowledge messages are replaced by the mode_modify and mode_modify acknowledge messages.
145 / 262
4 Call Handling
4. When the MSC receives the assignment_complete message from the BSC, it sends a Layer 3 CC modify_complete message to the mobile station. This informs the mobile station that the procedure is successfully completed, and the mobile station can start transmitting in the new mode.
4.2.2 Circuit-Switched Group 3 Fax Data Rate Change

Group 3 facsimile equipment can change the data transmission speed to reduce the error rate. Fax data rates can be: 9600 bit/s 4800 bit/s 2400 bit/s 1200 bit/s. The Alcatel 900/1800 BSS supports both transparent and non-transparent fax transmission. The BSS supports the Group 3 fax data rate change by: In-band signaling for non-transparent fax For non-transparent fax transmission, the data rate change is handled within the BSS, using in-band signaling. This means that the frame size is signalled in the frame by a "frame delimiter" field. The Radio Link Protocol in the BTS uses this information to control the data flow on the Air Interface. The BSS does not need to change the channel mode The mode modify procedure for transparent fax. Transparent fax frames are passed transparently through the BSS. Therefore, in-band signaling cannot be used within the BSS. The Group 3 fax equipment informs the MSC of a data rate change using in-band signaling. The MSC then initiates a mode modify procedure using the assignment_request message. This procedure is the same as the mode modify procedure for in-call modification, except that the MSC does not send a Layer 3 Call Control mode_modify_complete message. This is because the procedure was not triggered by a Layer 3 CC modify message from the mobile station. When the MSC receives the assignment_complete message from the BSC, it sets the new data rate to the correspondent.
4.2.3 Error Handling

The Alcatel 900/1800 BSS tries to provide the highest level of service at all times. In general, if errors occur during an in-call modification, the BSS tries to revert to the old mode to keep the call active. For example, if the mobile station does not reply to the channel_mode_modify message from the BSC, it is assumed that it is still active but in the old mode. The BTS, however, has set the new mode. The BSC sends a mode_modify message to the BTS indicating the old mode. If the BTS acknowledges that it has reverted to the old mode, the call is kept active.
146 / 262
4 Call Handling
4.3 Frequency Hopping

Frequency Hopping is a method to increase frequency reuse and improve the systems ability to cope with adjacent channel interference. The Frequency Hopping algorithm can be either random or cyclic. Associated (i.e., paired) uplink and downlink frequencies are always +/-45 MHz. There are two major types of frequency hopping:
Baseband Frequency Hopping Synthesized Frequency Hopping.

Frequency Hopping improves BSS-mobile station performance by providing two types of diversity: Frequency diversity Frequency diversity averages the effects of signal fading by using several frequencies to improve transmission performance. Obstacles such as buildings produce fading by reflecting the signal out of phase with the main signal. Each frequency is affected differently by fading. After error correction information is added to the data, it is encoded so that the data is split into packets and the information is repeated. This creates redundant information which is transmitted in bursts on the Air Interface. With Frequency Hopping, each redundant information burst is transmitted on a different frequency. This enables the original data to be reconstructed from the received flow, even if errors occur due to fading. In this way Frequency Hopping improves transmission performance. Interference diversity. Interference diversity spreads the co-channel interference between several mobile stations. In high traffic areas, the capacity of a cellular system is limited by its own interference; that is, the interference caused by frequency reuse. Interference Diversity minimizes the time during which a given user on a given mobile station will experience the effects of such interference.
147 / 262
4 Call Handling
4.3.1 Baseband Frequency Hopping

A Mobile Allocation is a set of all the frequencies available for frequency hopping. When the Frequency Hopping procedure is implemented, a group of mobile stations is assigned to a Mobile Allocation. When a traffic channel is set up in a cell where Frequency Hopping is active, the traffic channel is assigned: A particular time slot An FHS. An FHS is defined as the subset of frequencies within the MA to be used by a given cell for Frequency Hopping A MAIO. The MAIO indicates the initial hopping frequency of the traffic channel within the FHS. Use of the MAIO ensures that each traffic channel is assigned a different frequency during hopping An HSN. The HSN supplies the identifying number of an algorithm which is used to calculate the next frequency in the FHS on which the traffic channel transmits. There can be up to 63 different HSN algorithms, all of which are pseudo random. Within a given FHS, only one algorithm is used to avoid collisions. An HSN of zero means a cyclic use of the frequencies. An example of Frequency Hopping is shown in the figure below. Because HSN = 0, hopping occurs in a sequential manner. With a non-zero HSN, each of the three traffic channels would hop in a random fashion determined by the algorithm corresponding to the HSN.
Within this FHS the HSN=0
Frame n Frame n+1 Frame n+2 Frame n+3
Assignment for TCH 1: TS=1 MAIO=0 HSN=0
TCH1 on TS1 MAIO=0
f1
f2
f3
f1
TCH2 on TS2 MAIO=1
f2
f3
f1
f2
TCH3 on TS3 MAIO=2
f3
f1
f2
f3
f FHS TCH MAIO HSN TS
: Frequency : Frequency Hopping System : Traffic Channel : Mobile Allocation Index Offset : Hopping Sequence Number : Time slot
Figure 44: Frequency Hopping within an FHS
148 / 262
4 Call Handling
4.3.2 Synthesized Frequency Hopping

Synthesized Frequency Hopping functions in a similar fashion to Baseband Frequency Hopping, but is performed at a different location. Instead of switching each time slot between traffic channels, the channel assigned to a time slot is assigned to a fixed Carrier Unit (or TRE). The Carrier Unit/TRE changes frequency with each TDMA frame in accordance with the HSN algorithm selected, in the same manner as above. Thus, instead of the channel hopping from one fixed transceiver to another, the transceiver itself hops from one frequency to another, in both cases, according to the algorithm and parameters selected. Synthesized Frequency Hopping has the advantage of allowing an FHS to contain one more frequency than the number of Carrier Units/TREs in the system. This is particularly useful in some microcellular applications where only one transceiver is available for Frequency Hopping.
Note:
Normally, in both Frequency Hopping schemes (Baseband and Synthesized), time slot 0 (TS0) is not available for Frequency Hopping. This is because it carries the BCCH, which must always be at maximum power and on a frequency known to mobile stations in Idle mode in the cell.
149 / 262
4 Call Handling
4.4 Speech Transmission

Speech is transmitted over the air in the following ways: Continuous transmission Discontinuous transmission. The system also uses Voice Activity Detection (VAD) when transmitting. The two transmission types and VAD are described separately. In addition, discontinuous transmission from the BSS to the MS and from the MS to the BSS is explained in detail.
4.4.1 Continuous Transmission

Sound is continuously encoded into digital information even when no one is talking. In normal conversation, only one participant at a time talks. This is used by the system to its advantage, by transmitting only when someone is speaking.
4.4.2 Discontinuous Transmission

Discontinuous Transmission and VAD work together to decrease the average transmission time on a channel. By transmitting only when actual speech is present, the system reduces the interference level generated by the network in both the uplink and downlink directions and saves power. In tandem with Frequency Hopping, this improves spectrum efficiency without jeopardizing the quality of the telephony service. Only actual speech is digitally encoded and transmitted. During the non-speech phase (silent periods), noise/comfort mode information is sent once every 480 ms instead of once every 20 ms for speech. In this way the system: Improves spectral interference Increases power savings. By transmitting at a reduced rate of 1 in 24 during the silent phases, the power autonomy of the mobile station improves. Discontinuous Transmission does not occur during half-rate speech or data modes. It can be activated for either the uplink or the downlink or both. The receivers of Discontinuous Transmission information can automatically detect that the transmitter is in Discontinuous Transmission mode by the reception of Silence Indication (SID) messages. During quiet periods SID messages are sent instead of speech bursts. SIDs carry noise information about background noise. This information is used to: Let the receiver know that the link is still open Provide comfort noise. Users of telephones prefer to hear background noise rather than silence. Complete silence disturbs the listener Provide measurements of the link quality and timing advance. If there are no bursts of data over the Air Interface for a particular channel, no power level control and quality can be performed.
150 / 262
4 Call Handling
To eliminate the noise side effects generally known as banjo noise, the operator can ban Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX, without hopping, for all types of BTS. This is achieved using the FORBID_DTXD_NH_BCCH parameter. The parameter can be set to one of two values: 0. This is the default value, and allows Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX 1. This bans Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX.
4.4.3 Voice Activity Detection

VAD is used to detect when there is speech, silence or just background noise. The VAD device is located in the Transcoder. Once the VAD detects speech, it starts transmitting speech bursts. After four bursts of detected silence, the VAD goes back into silent mode, and SID information frames are transmitted (i.e., the comfort noise generation is activated).
4.4.4 BSS Discontinuous Transmission Towards Mobile Station

Downlink Discontinuous Transmission is activated on a per call basis by combining information from the MSC and the OMC-R. The MSC informs the BSC about its downlink Discontinuous Transmission preference. It does this via the Downlink Discontinuous Transmission flag in the assignment_request or handover_request messages on a per call basis. The OMC-R can enable or disable the possibility of downlink Discontinuous Transmission per BSC via the Discontinuous Transmission_DOWNLINK_ENABLE parameter. This is a static parameter which can be set via the CMISE command M_LOGICAL_PARAM_MODIFY. The overall system reaction is shown in the following table. MSC Downlink_ Discontinuous Transmission Flag (per call basis) Allowed Unavailable/not allowed Allowed Unavailable/not allowed Result Discontinuous Transmission Flag ON OFF
OMC-R Discontinuous Transmission_ DOWNLINK_ ENABLE (per BSC basis) True True
False False
OFF OFF
Table 25: Downlink Discontinuous Transmission Status in Channel_activation

The MSC requests no downlink Discontinuous Transmission during mobile station-to-mobile station calls, where double clipping can occur if both ends perform Discontinuous Transmission. This can have a staccato-like effect on speech.
151 / 262
4 Call Handling
The BTS tells the Transcoder to perform Discontinuous Transmission by setting the Discontinuous Transmission bit in the speech frame. In the BSS, the Transcoder is responsible for Discontinuous Transmission operation. In the BTS, the information is processed in the FU in the following way: 1. When the Transcoder detects voice activity it informs the FU, using in-band signaling. The speech signaling flag is set in the speech frame. 2. Every 20 ms the FU receives either speech frames or SID frames containing background noise characteristics. 3. At the end of the speech period (four bursts of detected silence) the FU sends a SID frame over the Air Interface. 4. During speech inactivity, the last received SID frame is sent at regular 480 ms intervals rather than at 20 ms. Otherwise dummy bursts are sent. These dummy bursts are: Transmitted for traffic channels on the BCCH frequency, due to the need for constant transmission on the BCCH frequency Not transmitted for traffic channels on other frequencies.
Note:
The BTS uses the measurement_result message to inform the BSC that Discontinuous Transmission is operating. The BSC compensates for Discontinuous Transmission when calculating power control and handover.
4.4.5 Mobile Station Discontinuous Transmission Towards BSS

The OMC-R operator controls whether a mobile station can perform Discontinuous Transmission towards the BSS per cell. This information is sent in cell options information (sys_info 3, and sys_info 6 on the Air Interface). The following table shows the available operator options. Option Will perform Discontinuous Transmission Description This forces the mobile station to use Discontinuous Transmission. It reduces the call quality but also reduces interference in the cell and saves mobile station battery power. During silent phases only 1 in 24 bursts are sent, which greatly reduces interference.
152 / 262
4 Call Handling
Option Can perform Discontinuous Transmission
Description This allows the mobile station to choose either quality by not using uplink Discontinuous Transmission, or power-saving by using uplink Discontinuous Transmission. The OMC-R operator has decided, due to low interference, to have improved speech and measurement control on the uplink side.
Cannot perform Discontinuous Transmission
Table 26: Operator Discontinuous Transmission Options

The Transcoder detects that the mobile station is in Discontinuous Transmission mode by the reception of SIDs.
Note:
There is a small quality reduction due to the fact that VAD only starts sending speech when a user starts to talk. This can cut the start of each speech activity. Power control and handover are also affected, as the BTS has fewer incoming messages with which to calculate power and interference. The following figure shows the different forms of transmission.
Sound continuously encoded
DTX during Silence in uplink
DTX during Silence in downlink
DTX during Silence in up and downlink
Continuous Transmission Discontinuous Transmission
DTX
: Discontinuous Transmission
Figure 45: Different Forms of Discontinuous Transmission
153 / 262
4 Call Handling
4.5 Radio Power Control

Radio Power Control operates independently, but in a co-ordinated manner with Handover to provide reliable service to the user. Both directions of the radio link between the mobile station and the BTS are subject to continuous power adjustments. The power adjustment of the BTS and the mobile station are under the control of the BSC (see Radio Measurements (Section 4.6.2)). RPC improves spectrum efficiency by limiting intra-system interference. It also increases the autonomy of the mobile station by saving battery power. The reasons for changing the mobile station power level are: Uplink power level too high or too low Uplink link quality too low, or using power resources beyond quality requirements of the call. Similarly, the reasons for changing the BTS power control are: Downlink power level too high or too low Downlink link quality too low, or using power resources beyond quality requirements of the call.
4.5.1 BTS Radio Power Control

The mobile station performs power measurements of radio signals being transmitted by the BTS. The mobile station, via the SACCH, regularly sends a measurement_report message to the BTS indicating the quality and strength of the downlink plus measurements of neighboring cells. This information is combined with uplink measurements taken by the BTS and sent to the BSC in the measurement_result message. The BSC then alters the BTS power, based on the measurement information it receives from the mobile station. The maximum power level is limited by the maximum power of the BTS, and also by the maximum power allowed in the cell.
4.5.2 Mobile Station Radio Power Control

The BTS measures the signal power transmitted by the mobile station. The resulting measurements are combined with the measurement_report message from the mobile station and are sent to the BSC in the measurement_result message. The BSC sends commands to change the power level of the mobile station as needed. The maximum power level is limited by the maximum power of the mobile station, and also by the maximum power allowed in the cell. Power control can be applied to traffic channels and Stand-Alone Dedicated Control Channels.
154 / 262
4 Call Handling
4.5.3 Radio Link Measurements

Due to interference and signal quality problems on the Air Interface, the uplink and the downlink transmissions are constantly measured to maintain maximum efficiency of the air waves. A balance is maintained between the transmission power, which can interfere with other cells using the same frequency, and the quality of the actual link. The following table shows the measurements used to achieve this balance. Measurement Signal strength Description Signal strength is calculated on both active and inactive channels. On active channels, this measurement is used to provide the actual strength of the signal received from the transmitter. Inactive channel strength provides measurement of interference levels. Signal quality The signal quality of a channel is calculated on the average Bit Error Rate on a particular channel. BER is a standard quality calculation in radio transmission. This is estimated by measuring the Time Of Arrival of the received burst at the BTS for each allocated time slot. The TOA is based on transmission distance and not the actual ground distance travelled. The calculation of one bit period (3.69 s) corresponds to 550m.
Absolute mobile station-BS distance
Table 27: Radio Link Measurements

The statistical parameters of signal level and quality are obtained over a measurement period. This period is called the Reporting Period. The reporting period for a traffic channel is 104 TDMA frames (480 ms). The information is transmitted in the SACCH frames.
155 / 262
4 Call Handling
4.5.4 Power Control Decision and Handover

At every measurement interval, the BSC receives: Pre-processed power measurement information (uplink and downlink) Timing advance (distance information) Power level information about neighboring cells (only the best six are transmitted). The BSC uses this information to perform power control by: Lowering the power level in the uplink or downlink, as this has little effect on the quality of the link Increasing the power on the uplink or downlink if the link quality/level is low Producing a handover alarm (refer to Handover Detection (Section 4.6.3) for more information) Taking no action, if the quality/level balance is acceptable. The following figure illustrates the measurements described previously, as well as power-control flow. Figure 47 shows how power control tries and maintains optimum quality and power levels.
MS Interruption of SACCH frames BTS BSC MSC
start counter conn failu ection re in dica tion caus e va lue

nne l rel eas e
clear
a F ch
requ
est
clear
MIE in
and comm e valu use g ca ludin c
MS TX
: Mobile Station : Transmitter
Figure 46: Power Control Flow of Measurement and Decision Action
156 / 262
4 Call Handling
Note:
The signal and quality levels are converted into the ranges Received Signal Level and Received Signal Quality respectively. Each range is classed from 0-63 (Received Signal Level where 63 is high) and 7-0 (Received Signal Quality where 7 is poor).
High Quality
R X Q U A L
Signal level low Increase power output
Desired balance no change
Signal level too high Decrease power output
Quality bad Increase power output
Signal level too high Quality bad Handover desired High Signal Level
Low Quality Low Signal Level
RXLEV
RXQUAL RXLEV
: Received Signal Quality : Received Signal Level
Figure 47: Power Output Balancing Based on Received Quality and Signal Levels
4.5.5 Change Power Levels

The BSC controls the power levels of the BTS and the mobile station. The BTS power level can be altered down from its maximum power. This is done in 2 dBm steps to a minimum of -30 dBm from the maximum level. The BSC informs the BTS of the new power level via a BS_power_control message. The mobile station power level can be altered in steps of 2 dBm. The following table shows the maximum and minimum power ranges of mobile stations. Mobile Station Phase GSM 850/900/1800/1900 Mobile station phase 1, GSM 900 Mobile station phase 1, GSM 1800 Mobile station GSM 850 Mobile station phase 2, GSM 900
Max Power 43 dBm (20 W)
Min Power 13 dBm
30 dBm (1 W)
10 dBm
39 dBm (8 W) 39 dBm (8 W)
13 dBm 13 dBm
157 / 262
4 Call Handling
Mobile Station Phase GSM 850/900/1800/1900 Mobile station phase 2, GSM 1800 Mobile station GSM 1900
Max Power 30 dBm (1 W)
Min Power 4 dBm
33 dBm (2 W)
0 dBm
Table 28: Mobile Station Maximum and Minimum Power Ranges

The maximum power setting of a mobile station is based on two factors: its classmark (its physical maximum power rating), and the maximum mobile station power setting for the cell. Each cell can limit the maximum power level for all mobile stations in the cell. For example, a 20 W mobile station can be limited to 5 W maximum power if that is the maximum mobile station power level allowed in the cell. However, a 1 W mobile station can never exceed 1 W, and can therefore never reach the 5 W maximum allowed in the cell. The BSC informs the BTS of the new power levels via the BS_power_control message. The BTS in turn transmits a power_command to the mobile station over the SACCH. Changing power from one power level to another happens gradually. The power level changes by 2 dB every 60 ms, until the desired level is reached.
158 / 262
4 Call Handling
4.6 Handover
A handover changes an active call from one channel to another channel. The new channel can be in the same cell or another cell. The types of handover are: Internal External Directed retry Incoming emergency Fast traffic UMTS to GSM. Handovers ensure a high level of call quality. They are performed when the BSS detects that the call quality has dropped below a defined level, and the call can be better supported by a different channel. The call quality can drop due to problems in the cell, such as an interface or an equipment problem. Call quality can also be affected simply because the mobile station has moved to an area where the radio coverage from another cell is better. The BSS detects the need for a handover by: Measuring the Air Interface channel quality, mobile station and BTS power outputs and the timing advance Using an algorithm to see if the received information conforms to the criteria for handover Selecting a more suitable channel from a list of target cells and their available channels. If the BSS decides that a handover is required, the exact sequence of events depends on the type of handover to be performed. In all cases: A new channel is assigned, ready to support the call The mobile station moves over to the new channel On successful completion of the handover, the system clears the resources for the old channel.
159 / 262
4 Call Handling
4.6.1 Principal Handover Types

The principal handover types are described below.
4.6.1.1 Internal Handover

Internal handovers take place between cells controlled by the same BSC. This can include channel changes within the same cell. More details about these handover cases is given in Target Cell Evaluation (Section 4.6.4).
4.6.1.2 External Handover

External Handovers take place between cells controlled by different BSCs. These can be under the control of the same MSC or of different MSCs. See Target Cell Evaluation (Section 4.6.4) for more details about these handover cases.
4.6.1.3 Directed Retry Handover

Handovers can also be performed when there is congestion in a cell. If congestion exists, the traffic channel assignment can be queued. For more information about congestion management, refer to Congestion (Section 3.5). If there is no available traffic channel for the normal assignment procedure, a Directed Retry can be performed. A Directed Retry is an attempt to assign a mobile station to a traffic channel in a cell other than the serving cell. There are two types of Directed Retry: An Internal Directed Retry without queueing attempts to hand over the call to a traffic channel of a neighbor cell controlled by the same BSC. An External Directed Retry attempts to hand over the queued call to a traffic channel of a neighbor cell which is controlled by a different BSC.
4.6.1.4 Secured Incoming Handover

The ability to keep free resources in a cell for incoming emergency and power budget handovers is provided on a cell basis. When the resource threshold is reached, assignments and other handover types are handled as if the cell was completely congested. Once such a request is queued, a directed retry can be performed as usual. The free resources can also be accessed in the case of a full-rate to half-rate handover in the case of AMR calls, because it allows half a resource (full-rate to half-rate) to be freed from the cell point of view. The feature improves the quality of service, as it helps to limit the number of lost calls.
4.6.1.5 Fast Traffic Handover

The fast traffic handover searches in the whole cell for a mobile which can perform a handover to a not-loaded neighbor cell if the received signal level of the BCCH is good enough. It is much more efficient than the forced directed retry when the overlap of adjacent cells is reduced, e.g., in the case of single layer networks, or for deep indoor coverage (if the umbrella cell does not totally overlap the microcells).
160 / 262
4 Call Handling
4.6.1.6 UMTS-to-GSM Handover

For circuit-switched services, the BSS supports handover from UMTS to GSM. The handover from GSM to UMTS is not supported in this release of the BSS. A hard handover is performed from the UTRAN to the GSM BSS between a UMTS core network and a 2G MSC. This handover is regarded by the BSS as a GSM inter-BSS handover. The signaling procedures, from the BSS point of view, rely almost on the normal GSM procedures. For packet-switched services, the current 3GPP standard does not allow handover with channel preparation. Therefore, the UMTS mobile station receives the 2G radio resource cell change order Information Element from the UTRAN in the Inter System handover message. The UMTS mobile station then performs an access request in the GPRS cell. From a BSS point of view, the UMTS mobile station is regarded as a 2G mobile station when it indicates that it has selected a GSM cell.
4.6.2 Radio Measurements

The BTS constantly monitors the radio link by: Measuring the received signal strength for active channels Measuring the received signal quality for active and inactive channels Measuring the received signal timing for active channels Collecting signal strength and quality measurements from the mobile station for the active channel Collecting adjacent cell BCCH signal strength measurements from the mobile station (adjacent cell BCCH frequencies are sent to the mobile station in the sys_info 5 message on the SACCH). The mobile station sends its measurements to the BTS in a Layer 3 Radio Resource measurement_report message on the SACCH. The mobile station and BTS measurements are passed to the BSC in a Layer 3 RR measurement_result message. These messages are sent once per multiframe and are processed by the BSC. The BSC uses this information to: Perform power control for the BTS and mobile station Calculate whether a handover is needed Make traffic channel quality tables Make the target cell list Make a handover decision.
4.6.2.1 Power Control

BTS and mobile station power control is described in Power Control Decision and Handover (Section 4.5.4). From a handover point of view, no handover decision is made due to signal quality until the power levels have been set to maximum.
4.6.2.2 Need for Handover

The BSC calculates the need for a handover using an algorithm, the use of which is described in Handover Detection (Section 4.6.3).
161 / 262
4 Call Handling
4.6.2.3 Target Cell List

A target cell list can be made by the BSC using the neighbor cell BCCH measurements sent by the mobile station. This is used to evaluate whether a neighbor cell can provide a better channel than the existing one.
4.6.2.4 Handover Decision

Handover decision is based on averaged measurements and the results are averaged over a period of time. For example, the BSC detects the need for a handover, based on one measurement that may have been caused by freak conditions changing the signal propagation for a short period. This measurement is averaged with other measurements and a handover decision may or may not result, depending on the other measurements.
4.6.2.5 Traffic Channel Quality Tables

The BSC uses the uplink idle channel measurements made by the BTS to make a table of traffic channels, classified by interference levels. This table is used to select a channel for assignment.
4.6.3 Handover Detection

Each time the BSC processes a set of Air Interface measurements, it checks whether a handover is needed. If the need for a handover is detected, it triggers the target cell evaluation process. See Target Cell Evaluation (Section 4.6.4) for more information. If the handover algorithm in the BSC detects the need for a handover, it produces a handover alarm. As the target cell evaluation is handled by the BSC, this alarm is also handled internally by the BSC. The alarm includes a cause value used by the BSC to evaluate which type of handover is required. The basic types of handover are: Quality and level Better zone Better cell (power budget) Distance Mobile velocity dependent Preferred band.
162 / 262
4 Call Handling
4.6.3.1 Quality and Level Handover

These handovers are used to keep an active call connected when the signal quality falls below a defined threshold. If a handover is not performed, a radio link failure may be detected and the call cleared. This type of handover can be caused by the following events: Quality level too low on the uplink or downlink Signal level too low on the uplink or downlink Interference level too high on the uplink or downlink Signal level too low on the uplink or downlink compared to low threshold (microcells only) Signal level too low on the uplink or downlink compared to high threshold (microcells only) Several consecutive bad SACCH frames received (microcells only) Signal level too low on the uplink or downlink inner cell (concentric cells only). Microcell handovers are described in detail in Microcell (Section 7.5.2). Refer to Concentric Cell (Section 7.2) for more information on concentric cells. If the received signal level or the received signal quality is too low, the BSC performs BTS and mobile station power control to try and achieve the optimum level/quality ratio. This is described in Power Control Decision and Handover (Section 4.5.4). The figure below shows a graph of received signal level and received signal quality. The hatched areas show where power control is successful. The solid gray shaded areas show where power control fails to achieve the desired level/quality ratio. These areas are where the BSC detects the need for a handover.
High Quality
Received Signal Quality
123456 123456789 123456 123456789 123456 123456789 123456789 Level 123456Desired Power Power 123456789 Intercell 123456 Quality Increase Decrease to Handover to Conserve 123456and Level 123456789 Improve Balance Resources 123456(no action 123456789 Level and Minimize 123456needed) 123456789 Interference 123456 123456789 123456 123456789 123456 123456789 123456 12345678901234 123456789 123456 Power Increase to 12345678901234 123456 12345678901234 improve quality 123456 12345678901234 123456 12345678901234
Quality Intercell Handover Quality Intracell Handover High Level Low Level
Low Quality
Received Signal Level
Figure 48: Quality and Level Handover
163 / 262
4 Call Handling
4.6.3.2 Level Intercell Handover

The Level Intercell Handover area represents the range of measurements where the received signal quality is acceptable, but the received signal level is too low. If the power output levels are already set to the maximum allowed in the cell, the BSC generates a handover alarm with a cause value indicating the reason for handover. Although the quality of the signal is acceptable (and may be very good), the call is in danger of being lost if the signal level drops rapidly, causing a radio link failure. The handover is an intercell handover, as the serving cell cannot support the call at the required power level. The call is handed over to a channel in a cell which can support the call at the required level and quality.
4.6.3.3 Quality Intercell Handover

The Quality Intercell Handover area represents the range of measurements where both the receive signal quality and the received signal level are too low. If the power output levels are already set to the maximum allowed in the cell, the BSC generates a handover alarm with a cause value indicating the reason for the handover. The handover is an intercell handover, as the serving cell cannot support the call at the required quality and power level. The call is handed over to a channel in a cell which can support the call at the required quality and level.
4.6.3.4 Quality Intracell Handover

The Quality Intracell Handover area represents the range of measurements where the received signal quality is too low, but the received signal level is acceptable. This situation is caused by interference on the channel, so the call is handed over to another channel in the same cell.
164 / 262
4 Call Handling
4.6.3.5 Better Zone Handover

This is used in concentric cell configurations when the mobile station moves into the inner zone. If the inner zone has a free channel, an interzone handover is triggered. This enables the mobile station to be supported on a channel requiring a lower power level, therefore creating less interference in the cell. The detection of this type of handover is performed on signal level measurements only (SACCH of serving cell, BCCH of adjacent cells). This is shown in the following figure. This type of handover can be caused by the signal level being too high on the uplink and downlink outer zone (concentric cells only).
High Power Outer Zone
Low Power Inner Zone MS Handed Over to Low Power Zone

MS : Mobile Station
Figure 49: Better Zone Handover
4.6.3.6 Better Cell Handover

This feature is used to handover the mobile station to a cell that can support the call using lower BTS and mobile station power levels. The algorithm in the BSC calculates the power levels for the current cell, and the power levels required by adjacent cells from the adjacent cell information sent by the mobile station. This is shown in the figure below. This type of handover is often referred to as a power budget handover, as it uses the Power Budget parameter to detect whether an adjacent cell can be used (see also Multiband Power Budget Handover in Multiband Handover (Section 4.6.3.9 )). If the power budget for an adjacent cell gives a better reading for a certain amount of time (a defined number of SACCH frames), then a handover alarm is produced.
165 / 262
4 Call Handling
This type of handover can be caused by the following events: Power budget is greater than handover margin threshold High signal level in neighbor microcell (macrocell to microcell handover).
BSS 1 = Best Cell BSS 2 = Best Cell
Serving Cell BSS 1
Target Cell BSS 2
Zone for Power Budget Handover from BSS 1 to BSS 2
Figure 50: Better Cell Handover (Power Budget)
166 / 262
4 Call Handling
4.6.3.7 Distance Handover

This handover occurs when the propagation delay between the BTS and the mobile station is considered excessive. The mobile station is considered to be too far from the BTS and needs to be served by a closer BTS. This is shown in the figure below. Under normal circumstances, as the mobile station moves away from a BTS, a Quality and Level or Better Cell handover takes place. However, under certain conditions which change the propagation qualities of a signal, a cell can provide a very high quality signal outside of the normal operating range of the serving cell. These propagation qualities are often due to climactic conditions which can change suddenly. If the high quality signal disappears due to a change in the weather, the call would be lost. The distance handover ensures that this does not happen by handing the mobile station over to a closer cell once a distance limit is exceeded. This type of handover is caused by too great a distance between the mobile station and the Base Station .
BSS 1
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789
BSS 2
Area of Normal Cell Boundaries
Distance Handover Area from BSS1 to BSS2
Figure 51: Distance Handover
4.6.3.8 Mobile Velocity Dependent Handover

In a hierarchical cell structure, where mini or microcells are overlaid by an umbrella cell (macrocell), fast moving mobile stations are handled by the upper layer cell. Discrimination of the speed of a mobile station is based on the dwell time of that mobile station in a lower layer cell. Depending on the time elapsed in the serving cell, the call is transferred to the lower layer cell or the umbrella cell. If the dwell time in the serving cell is above the threshold, the mobile station is considered slow moving and is sent to the lower layer cell that triggered the handover. If the dwell time is below the threshold, the mobile station is considered fast moving. To prevent a high number of handovers between the smaller lower layer cells, the call is sent to the umbrella cell. Dwell time is only calculated if there has been a power budget handover from another lower layer cell.
167 / 262
4 Call Handling
This is to avoid sending a call to the umbrella cell in the following cases: A call initiated at the limit of the lower layer cell A call transferred from the umbrella cell to the lower layer cell, just before reaching the limit of that cell After an external handover, when there is no information on the preceding cell and handover cause. Whatever the dwell time, any emergency handover sends the call to the umbrella cell, which acts as the rescue cell. The load on the umbrella cell is taken into consideration when determining the threshold at which handovers are performed. Saturation of the umbrella cell can cause the loss of calls, when a handover is required from another umbrella cell or a lower layer cell. As the load on the umbrella cell increases, the dwell time threshold is increased, keeping some mobile stations in the lower layer cells. When the load on the umbrella cell is very high, speed discrimination is disabled, and priority is given to the load in the umbrella cell. The following figure shows a graph of umbrella cell load and minimum dwell time.
Load in Umbrella Cell Macrocell saturated High load Traffic regulation Low load Max speed discrimination in force Low minimum dwell time Speed discrimination disabled
Macrocell with little traffic Minimum Dwell Time High minimum dwell time
Figure 52: Umbrella Cell Load in Mobile Velocity Dependent Handover
168 / 262
4 Call Handling
4.6.3.9 Multiband Handover

There are two types of multiband handover: Preferred-band handover and Multiband Power Budget handover. They are described below. Preferred-Band Handover Network capacity can be expanded by introducing multiband operation. This means that an existing network (for example, GSM 900) is expanded by adding cells in a different band (for example, GSM 1800). In such a network, the original band (GSM 900) is referred to as the first band. The new band (GSM 1800) is referred to as the preferred band. The existing monoband mobile stations, which use the first band, continue to do so. However, multiband mobile stations are handed over to the preferred band, where possible. This is done to free resources in the first band for use by monoband mobile stations. Normal handovers (for example, better cell handover), hand over multiband mobile stations to the preferred band. A new handover type, called preferred-band handover, hands over multiband mobile stations immediately when a first-band cell reaches a specified congestion threshold. This frees up resources for the monoband mobile stations in the cell. For a preferred-band handover to occur, the following conditions must be met: The first band cells traffic load reaches a high threshold Suitable neighboring cells in the preferred band are available The preferred band handover facility is enabled. Multiband Power Budget Handover In certain networks, two different frequency bands can exist. For example, one frequency band uses the GSM 900 frequencies, the other frequency band uses the GSM 1800 frequencies. In this case, multiband power budget handovers can be enabled between the two frequency bands using the EN_MULTIBAND_PBGT_HO parameter: Setting the EN_MULTIBAND_PBGT_HO parameter to TRUE enables multiband power budget handovers between two frequency bands Setting the EN_MULTIBAND_PBGT_HO parameter to FALSE disables multiband power budget handovers between two frequency bands. This parameter must be defined for each cell where multiband power budget handovers are required.
4.6.4 Target Cell Evaluation

Cell evaluation is performed by the BSC. Once a handover alarm is detected within the BSC, it evaluates the neighbor cells and compiles a list of possible target cells. The serving cell can be on the target cell list. The cells are evaluated and ranked by preference, calculated by one of the two algorithms, ORDER or GRADE. The Network Operator chooses which algorithm is to be used on a cell-by-cell basis. The BSC tries to hand over to the most suitable cell. If this cell is controlled by the BSC, the BSC handles the handover procedure. If the target cell is controlled by another BSC, the serving BSC sends a handover_request message to the MSC.
169 / 262
4 Call Handling
4.6.4.1 Target Cell

The exact calculation performed to choose the target cell depends on the algorithm used and the cause of the handover alarm. The target cell is chosen taking into account the following criteria: Received signal level Power budget Number of free channels Relative load on the traffic channel of the cell Maximum power allowed in cell
HO_MARGIN parameter
Mobile station distance from target BTS Handover cause. The HO_MARGIN parameter is an O&M parameter set by the Network Operator. It is used to prevent a call being continually handed over between two cells. For example, following a power budget handover, the new cell immediately starts power budget calculations for its neighbor cells. It may find that the original cell is giving a better power budget reading and try to hand back immediately. This effect can be caused by slight climactic changes which affect the propagation of signals. It is known as the ping-pong effect. The HO_MARGIN parameter stops a call being handed back to a cell from which it has just been handed over. There is also an O&M parameter, W_PBGT_HO which can be set by the OMC-R operator, to add a weighting for the power budget parameters of cells controlled by another BSC. Refer to the A1353-RA Configuration Handbook for more information. The target cell chosen also depends on the mobile station classmark (see Classmark Handling (Section 3.6)) and its compatibility with the BTSs ciphering capabilities (see Ciphering (Section 3.8)). The procedures initiated to hand over a call depend on which cell has been chosen as the target cell.
4.6.4.2 Target Cell Handovers

Depending on which cell has been chosen as the target cell, one of the following handovers takes place. This handover occurs... Internal: Intracell If the target and serving cell are... the same, the call is handed over to a channel in the same cell. This is an intracell handover. This type of handover is most commonly due to interference in the cell. It is controlled by the BSC not the same but are controlled by the same BSC, this is called an intercell intraBSS handover. This handover is normally controlled by the BSC. However, the Network Operator can specify that this type of handover be controlled by the MSC
Internal (IntraBSS): Intercell
170 / 262
4 Call Handling
This handover occurs... External (InterBSS): IntraMSC
If the target and serving cell are... not controlled by the same BSC, but the two BSC are controlled by the same MSC, this is called an interBSS intraMSC handover. This handover is controlled by the MSC. controlled by different BSCs and the two BSCs are controlled by different MSCs, this is called an interBSS interMSC handover. The control of this handover is shared between the MSCs. Handovers controlled by the BSC are called internal handovers. Handovers controlled by the MSC are called external handovers.
External (InterBSS): InterMSC
Table 29: Target Cell Handover Types
4.6.5 Synchronous and Asynchronous Handover

The handover to the target cell can be synchronous or asynchronous. A synchronous handover can be performed if the master clocks of the serving cell and the target cell are synchronized. This is the case when: The serving cell and the target cell are the same cell The BTSs of the serving cell and the target cell are in a collocated configuration. BTSs in a collocated configuration take the clock pulse from one BTS in the configuration. For a synchronous handover, the mobile station does not have to resynchronize with the target BTS. Therefore, the physical context procedure for power levels and timing advance does not have to be performed after the mobile station accesses the target cell. For an asynchronous handover, the mobile station has to synchronize with the target cell before transmitting any user traffic.
171 / 262
4 Call Handling
4.6.5.1 Asynchronous External Handover - Message Flow

This section describes the message flow for an asynchronous external handover. The example in the figure below is for a handover of a traffic channel between two separate cells controlled by two different BSCs.
MS
measurement reports
Target BTS
(SACCH)
Serving BTS
Target BSC
Serving BSC
MSC
1
measurement results
2 3
channel activation
SACCH/FACCH
HO detect HO alarm over hand

handover request
required
er+cel channel type+ciph
l IDs+DTX+cause+c
channel activation ack
hanover request ack
+ handover command
d handover comman
handover command
handover command
ch+cell+HOref+cipher
release with serving BTS

Synchronization (FCCH + SCH)
access burst (SACC H)
handover detect
5
handover detect
HO ref + TA
handover detect
set up switching path between Abis & A interfaces

physical info physical info
(FACCH)
6
ack
establish indication
(FACCH)
handover complete
handover performed
clear command
DTX FACCH HO MS SABM SACCH TA
: Discontinuous Transmission : Fast Associated Control Channel : Handover : Mobile Station : Set Asynchronous Balanced Mode : Slow Associated Control Channel : Timing advance
Figure 53: Asynchronous External Handover
172 / 262
4 Call Handling
4.6.5.2 Asynchronous External Handover Process

1. The mobile station and BTS take measurements on the Air Interface as described above. The mobile station sends measurement information to the BTS in a measurement_report message. The BTS sends mobile station and BTS measurements to the BSC in a measurement_results message. 2. The BSC detects the need for a handover and creates a handover alarm indicating the reason for the handover. The BSC evaluates possible target cells and creates a candidate cell list. To initiate the external handover procedure, the BSC sends a handover_required message to the MSC including the candidate cell list. It also starts a timer to prevent it sending the same cell list. It can only re-send the cell list when the timer times out, or if it receives a handover_request_reject message from the MSC. The MSC chooses the target cell from the cell list. It sends a handover_request to the target BSC to inform it that a mobile station is going to be handed over.This message contains: Channel type required Cipher mode information Mobile station classmark information Serving cell identification Target cell identification Downlink Discontinuous Transmission flag Handover cause. 3. The target BSC initiates the channel activation for the new channel with the channel_activation message. The target BTS sets its resources to support the new channel, starts sending the SACCH/FACCH and sends a channel_activation_acknowledgment message to the target BSC. 4. The target BSC builds a handover command. This command is sent to the MSC in the handover_request_acknowledgment message.The handover command contains: The new channel and its associated control channel The target cell description A handover reference Any cipher mode information (phase 2 mobile stations can change cipher mode during a handover procedure). The MSC forwards the handover_command message to the serving BSC. The serving BSC sends the handover command message to the mobile station.
173 / 262
4 Call Handling
5. The mobile station releases its connection to the serving BTS. It synchronizes with the target BTS using the FCCH and SCH information. Once synchronized, the mobile station continually sends access burst on the uplink SACCH until it receives the physical_information message on the FACCH from the target BSC. When the target BTS receives an access burst, it checks the handover reference and calculates the timing advance. This is sent to the target BSC in the handover_detect message. The target BSC informs the MSC of the handover detection and establishes a switching path between the allocated Abis and A Interface resources. 6. When the mobile station receives the physical_information message, it sends its first frame on the new channel using the timing advance sent in the physical_information message. The target BTS acknowledges the mobile stations first frame and sends an establish_indication message to the target BSC, and an acknowledgment to the mobile station. On receipt of the acknowledgment, the mobile station sends a handover_complete message on the uplink FACCH to the target BSC. The target BSC informs the MSC that the handover has been performed. The MSC initiates the call clearing procedure towards the serving BSC.
4.6.6 Circuit-Switched Telecom Handovers

To make the regulation of circuit-switched traffic load more effective some specific handovers are triggered as described below. Specific Handover Capture Description
A capture handover refers to a handover triggered only on the signal level received from the neighbor cell, independently of the signal received from the serving cell. A power budget handover refers to a handover triggered on a power budget criterion. The power budget is a measure of the difference between the signal level received from a neighbor cell and the signal level received from the serving cell. The higher is the power budget, the more likely a power budget handover is triggered.
Power Budget
Cause 14
Handover Cause 14 is used in hierarchical networks to unload the umbrella cells by directing slow mobile station towards a lower or indoor layer cell. Mobile station speed is estimated by measuring the residence time of the mobile station in the indoor and lower layer cells. If this residence time is below a certain threshold, the mobile station is deemed to move rapidly. If the residence time is above another threshold, the mobile station is deemed to move slowly.
174 / 262
4 Call Handling
Specific Handover Cause 21
Description
In multiband networks, the operator defines a preferred band where multiband mobile station are directed. Handover Cause 21 is triggered when a mobile station in the non-preferred band receives a good signal level from a neighbor cell where the traffic load is not high and which belongs to the preferred band. Handover Cause 23 reduces the serving cell size when it is high loaded relative to a low loaded neighbor cell. The traffic handover enables better distribution of traffic in the serving cell neighborhood. When the mobile station moves away from the BTS, as the path loss increases, the power budget increases and a traffic handover is triggered sooner. The power budget is used to evaluate the difference between the signal levels received from the neighbor cell and from the serving cell. In hierarchical networks where cells use different frequency bands, a general capture handover Cause 24 is required to manage, on a per cell adjacency basis, the ability of the mobile station to be captured by a neighbor cell. This allows capture from a macrocell to a microcell or from the same macrocell to another cell in the preferred band. This general capture handover takes into account the load in the serving cell and in the target cell.
Cause 23
Cause 24
Table 30: Handovers
4.6.6.1 Traffic Handovers in Multiband Mono-layer Networks

In some multiband networks, the radio coverage is ensured by GSM 1800 cells in one geographical area and by GSM 900 cells in another geographical area. As these cells form a multiband mono-layer network, the capture handovers between cells of different bands are inefficient in regulating circuit-switched traffic load in the serving cell neighborhood. The solution consists of allowing intra-layer traffic handovers (Cause 23) based on a power budget evaluation between cells of different bands.
4.6.6.2 Inhibition of Capture Handovers for "Single Layer" Serving Cell

To avoid the ping-pong effect in multilayer or multiband networks, capture handovers are inhibited. The T_INHIBIT_CPT timer controls the time during which the capture handover Causes 14, 21, and 24 are inhibited. This timer starts when an emergency handover is performed towards the serving cell, and the preceding cell does not belong to the same layer or to the same frequency band as the serving cell. The timer T_INHIBIT_CPT starts if the serving cell is in the upper or lower layer, but not if the serving cell is in the single layer. This improvement extends the capture handover inhibition mechanism.
175 / 262
4 Call Handling
4.7 Overload Control

A lot of telecommunications signaling is required for the BSS to support communication between mobile stations in the cells under its control and the MSC. Telecommunication processors in the BTS or BSC can become overloaded. To avoid a sudden loss of communication when a processor becomes saturated, the BSS controls the load on these processors as follows: 1. Taking local action to reduce the load. 2. Taking global BSS action to further reduce the load.
Note:
The telecommunications processors of the MSC can also become overloaded. However, MSC overload control is not the domain of the BSS.
4.7.1 BTS Overload

The BTS Frame Unit (TRE for a BTS A9100 or BTS A9110) handles all the telecommunications signaling on the Air Interface. If the FU or TRE becomes saturated, this can result in the loss of calls. Therefore, the BTS monitors the load and takes action where appropriate. On initial detection of the overload condition, the BTS takes local action to reduce the load. If the BTS local action does not reduce the load, the BTS sends overload messages to the BSC, which can decide to take global action. The different stages of BTS overload, from detection to resolution, are described below. The BTS monitors the load on the FU or TRE by measuring the free time on the FU or TREs Signaling Control Processor and the free message space on the associated buffers. If either of these passes a set threshold, a counter is incremented. If a threshold is not passed again within a given time, the counter is decremented. The counter has two thresholds. If the first of these is passed, the BTS takes local overload action. If the second of these is passed, the BTS sends overload messages to the BSC. When local action is triggered in the BTS, it discards low priority messages such as the establish_indication message to reduce the load on the SCP.
176 / 262
4 Call Handling
4.7.2 BSC Overload

The BSC has two entities handling telecommunications signaling: The TCU handles telecommunications signaling for the Abis Interface The DTC handles telecommunications signaling for the A Interface. The different stages of BSC overload, from detection to resolution, are described below.
4.7.2.1 BSC Overload Detection

For the BTS, overload is calculated on the processor free time and the free message space of the associated buffers. As the BSC handles more signaling traffic than the BTS, the detection of an overload, and whether to trigger local or global defense actions, is more complicated. The BSC uses an algorithm that takes into account which processors are affected, the level of overload, and which buffers are affected. Each processor has a local overload controller. The BSCs centralized overload controller is responsible for global overload defense actions.
4.7.2.2 BSC Local Overload Action

Local action in the BSC is taken by the local overload controller on each processor. Local actions reduce the load on an individual board. The local actions are: TCU Action The TCU discards a percentage of the measurement_result messages received from the BTS. The percentage of discarded messages is increased and decreased in steps, under the control of the local overload control. This only affects the handover and power control algorithms which still function but with less information. DTC Action When the DTC detects an overload, its state is set to congested on the BSC database. This means that it cannot be selected by the resource management software to provide a new SCCP connection. Also, the DTC cannot send connectionless messages to the MSC. BSC Global Overload Action The BSC controls global actions for the whole BSS. Global action reduces the amount of telecommunications signaling traffic in the BSS by inhibiting new calls. The BSC bars mobile station access classes either in one cell if the global action is requested by a BTS or TCU, or in several cells if a DTC or MSC are overloaded.
177 / 262
4 Call Handling
4.7.2.3 Mobile Station Access Class Barring

When the BSC receives a request for global overload action from a BTS, from the MSC, or from one of its local overload control processors, it checks the message for errors. If it can accept the request, it builds new system information messages (1 to 4). These messages are sent on the BCCH. They bar certain mobile station classes from sending channel_request messages on the RACH. If the overload condition persists, the BSC can change the system information messages to bar more mobile station access classes from using the RACH. When the BTS is barring access classes, its behavior can be modified from the OMC-R by modifying the following parameters:
AUTO_BAR_CELL enables/disables the automatic barring of cells after all access classes have been barred. This forces the mobile station to camp on another cell AUTO_BAR_EC enables/disables the automatic barring of emergency calls. EN_BSS_OVRL_CLASS_BARR enables/disables the ability of the BSC to
perform global action for BTS-to-BSC overload conditions. The number of access classes that can be barred and unbarred in one step can also be configured from the OMC-R.
4.7.2.4 Mobile Station Access Class Unbarring

When an overload message is received from the BTS or when an overload is detected in the BSC, a timer is set. If no overload message is received from the BTS, or no overload detected in the BSC during the period of the timer, the timer expires. When the timer expires, the BSC unbars some access classes according to a defined algorithm.
178 / 262
4 Call Handling
4.8 Call Re-establishment by the Mobile Station

The mobile station initiates call re-establishment when there is already a speech or data call in a stable state (traffic channel path connected) and the mobile station detects a radio link failure. The mobile station waits a predetermined time for a response from the network. If there is no response, the mobile station performs a cell reselection procedure. If the new cell allows the re-establishment procedure to be performed, the mobile station initiates the channel request procedure RACH and awaits the immediate_assignment message. The mobile station then performs the contention resolution procedure using the cm re-establishment request message. The radio and link establishment procedure continues as described in Mobile-Originated Call (Section 3.2). The network can block the mobile station from performing the channel request procedure, due to inhibition of the mobile station access class broadcast in the sys_info 1 to 4 messages. If this is the case, the mobile station radio resource entity reports the failure of the radio and link establishment procedure to the higher layer entities in the mobile station. When the MSC receives the cm re-establishment request message, it initiates the procedures necessary to establish a new radio resource connection and continue the call management connection.
179 / 262
4 Call Handling
180 / 262
5 Call Release
5 Call Release
This chapter provides an overview of Call Release and describes the procedures which ensure resource allocation to a call. This chapter also describes Remote Transcoder Alarms, and the processes used to break a connection and disconnect the resources, depending on the nature of radio transmission.
181 / 262
5 Call Release
5.1 Overview
The Call Release procedures ensure that resources allocated to a call are free for reuse when they are no longer required by the current call. Call Release procedures are required when: A call is finished and either the called or calling party hang up A mobile station is turned off A call is handed over and the resources for the original call are released A call is modified and the resources for the original channel are released There is operator intervention, such as a channel being blocked There is a failure There is a radio link failure The system detects an LAPDm failure. If a call is terminated normally, the Call Release procedures are triggered automatically. If the call is terminated abnormally, the system has to detect that the resources are no longer required and release them. For a complete Call Release, the following resources must be released: A Interface resources Abis Interface resources Air Interface resources MSC resources: Layer 3 for the A Interface SS7 signaling for the A Interface Layer 1 physical resources for the A Interface. BSC: Layer 3 for the A, Abis and Air Interface Layer 2 SS7 for the A Interface and LAPD for the Abis Interface Layer 1 physical resource for the A and Abis Interface. BTS: Layer 3 for the A, Abis and Air Interface Layer 2 LAPD for the Abis Interface and LAPDm for the Air Interface Layer 1 physical resources for the Abis and Air Interface. Mobile station: Layer 3 for the Air Interface Layer 2 LAPDm for the Air Interface Layer 1 for the Air Interface.
182 / 262
5 Call Release
5.2 Call Release Procedures in Normal Service

The Call Release procedures, and the order in which they are triggered, depend on the reason for the release. This section describes the following Call Release scenarios, which occur during normal service: Normal Release (calls terminated by Call Management) Calls terminated following a channel change. Special cases, including detailed behavior of the MSC, BSC, BTS and mobile station are described elsewhere.
5.2.1 Normal Release

Call termination initiated by Call Management is considered to be a normal reason for Call Release. In this type of Call Release, the MSC initiates the release. Before this can happen, the mobile station must inform the MSC that it has disconnected the call. This is done with Layer 3 messages passed transparently through the BSS between the mobile station and MSC, as shown in the following figure.
MS
disconne ct
BSS
(layer 3 CC)
MSC
request release
CC) (layer 3
release
complete
(layer 3 CC)
MS
: Mobile Station
Figure 54: Mobile Station Disconnecting a Call

1. Once the MSC has confirmation that the mobile station wants to disconnect and no longer requires the connection, it initiates the release procedure towards the BSC.This procedure: Releases the circuit (if applicable) Releases the SCCP connection.
183 / 262
5 Call Release
2. The BSC responds to the MSC to clear the connection on the A Interface, and initiates the Call Release procedure toward the BTS and mobile station. This procedure releases the radio resources. 3. This action triggers the mobile station to release the LAPDm connection (disc message) and the BSC to release physical resources allocated to the call. This is shown in the following figure.
MS BTS BSC
clear c
MIE in
MSC
omma nd
lue use va
g ca cludin
chann
el rele
ase
tiva te S AC
CH
release of A interface resources Timer start (SCCP release) clear c om

plete
ed
c dea
(to re
disc lease LAP
disable remote TC alarm detect

Dm)
Timer start (release indication)

se in
SCCP releas
UA
relea
dicati
on
physic
al c
reque ontext
st
SCCP release comple te
Timer physic al con text co nfirm

releas e
RF ch
annel
RF ch
annel
Timer
releas e ack
LAPDm MIE MS SACCH SCCP TC UA
: Link Access Protocol on the Dm Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Signal Connection Control Part : Transcoder : Unnumbered Acknowledgment
Figure 55: Normal Call Release
184 / 262
5 Call Release
5.2.1.1 MSC Actions

The MSC initiates Call Release at the end of the mobile station transaction. The MSC can be informed of the end of the mobile station transaction: By a level 3 disconnection message from the mobile station (Figure 54) By a disconnection message from the Network Operator if the correspondent terminates the call At the end of a service call (i.e., SMS or location updating). The normal release procedure of the MSC releases both the A Interface resources used for the call, if any, and the SCCP connection used for the signaling which controls the connection.
MS
BTS
BSC
MSC
1
clear
udin MIE incl
command
value g cause
release channel
CH SAC ate tiv eac d
release of A interface resources Timer start (SCCP release)
clear co mplete
2 3
Timer start (release indication)

leased SCCP re
SCCP rele ase
complete
MIE MS SACCH SCCP
: Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Signal Connection Control Part
Figure 56: Initiation of Normal Release by MSC

1. The MSC initiates the release procedure by sending a clear_command message to the BSC. This command can include a cause value in the Mandatory Information Element. 2. The BSC accepts the command even if no cause value is included. It immediately releases the A Interface resources for the call and replies to the MSC with a clear_complete message. 3. The BSC initiates the release of the Abis and Air Interface resources. It also sets a timer to ensure that the MSC releases the SCCP signaling resources. On receipt of the clear_complete message from the BSC, the MSC releases the resources associated with the A Interface and initiates the release of the SCCP signaling resources by sending the SCCP_released message to the BSC. 4. The BSC stops its timer and sends the SCCP_release_complete message. The SCCP resources are now released and can be used for another call. If the BSC timer expires before the SCCP_released message is received, then the BSC force releases the SCCP connection.
185 / 262
5 Call Release
5.2.1.2 BSC/BTS/Mobile Station Interactions

The normal Call Release procedure towards the mobile station/BTS releases the: Radio resources associated with the call Radio Frequency channel. 1. The BSC initiates the release of the radio resource by sending: A channel_release message to the mobile station via the BTS A deactivate_SACCH message to the BTS. 2. The channel_release message prompts the mobile station to send a disc message to the BTS to release the LAPDm resource. When this is received, the BTS acknowledges this with a ua message to the mobile station and sends a release_indication message to the BSC. This procedure is supervised by a timer in the BSC. The BSC considers the mobile station disconnected and starts the RF channel release when: The timer expires The BSC receives the release_indication message and stops the timer. 3. When the BTS receives the deactivate_SACCH message, it stops sending SACCH information and disables the remote Transcoder alarm detection. This stops the sending of Transcoder alarms to the BSC when the Transcoder detects inactivity on the channel. This is shown in the figure below. If the mobile station does not receive the channel_release message, it considers the stopping of SACCH information as a radio link failure and performs a local release.
MS BTS
1
BSC
clea and r comm
ding c ause v alue
MSC
clu MIE in
chann
el rele
ase
d tiv eac ate SAC
CH
release of A interface resources
2
(to re lease LAP Dm) UA
disc
disable remote TC alarm detect
Timer start (SCCP release) clear c om Timer start (release indication)

SCCP
plete
ed
releas
relea
se in
dicati
on
SCCP
release
comple
te
LAPDm MIE MS SACCH SCCP TC UA
: Link Access Protocol on the Dm Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Signal Connection Control Part : Transcoder : Unnumbered Acknowledgment
Figure 57: BSC/BTS/Mobile Station Interactions in Normal Call Release
186 / 262
5 Call Release
Once the BSC considers the mobile station disconnected, it initiates release of the RF channel from the BTS. In a normal Call Release procedure, this occurs following the release of the mobile station from the Air Interface (as described earlier in this section). 4. Before releasing the RF channel, the BSC sends a physical_context message to the BTS and starts a timer to supervise the response. The response from the BTS is a physical_context_confirm message which contains the last LAPDm performance measurements for the RF channel. 5. On receipt of the physical_context_confirm message, or after the timer has timed out, the BSC sends an RF_channel_release message to the BTS and starts a timer to supervise the release. The BTS releases the level 1 and 2 resources for the channel and replies with an RF_channel_release_ack message. On receipt of the acknowledgment, the BSC releases all resources for the RF channel. This is shown in the following figure.
MS
BTS
BSC
MSC
3
UA
releas e indi cation

physical
context
Timer
confirm
5
nel RF chan release
RF chan nel rele ase ack
Timer
MS UA
: Mobile Station : Unnumbered Acknowledgment
Figure 58: Normal Release Final Steps

If the timer supervising the release times out, the BSC sends the RF_channel_release message again and restarts the timer. If the timer times out again, the BSC releases all resources locally. It also sends an O&M error report to the OMC-R with a cause value indicating that the RF channel release procedure has failed.
Note:
The RF channel can be released locally by the BTS and still be active. If the RF channel is still active, it is released when the BSC attempts to assign it to another call with a channel_activation message. The BTS replies with a channel_activation_nack and the BSC releases the channel (refer to Call Set Up (Section 3) for more information).
187 / 262
5 Call Release
5.2.2 Calls Terminated Following a Channel Change

This section describes the Call Release procedure following a successful channel change procedure. The case presented is an external intercell handover. For an internal channel change, the serving and target BSCs are the same, and in some cases, the serving and target BTSs are the same. 1. The target BSC receives confirmation of the successful handover from the mobile station when the mobile station sends the handover_complete message. This message is passed transparently through the target BTS. See Call Handling (Section 4) for more information about handovers. 2. The target BSC informs the MSC of the handover and initiates the Call Release procedure towards the serving BSC, by issuing a clear_command message. 3. The serving BSC issues a channel_release message to the mobile station and a deactivate_SACCH message to the serving BTS. The normal Call Release procedure described in Normal Release (Section 5.2.1) continues between the serving BSC, the serving BTS, the MSC and the mobile station. This is shown in the following figure.
MS
(FACC H)
Target BTS
Serving BTS
e
Target BSC
Serving BSC
MSC
handover complet
handover perform
ed
chan
nel re
leas
and comm clear ing clud MIE in value e caus
deac
tivate
SAC
CH
FACCH MIE MS SACCH
: Fast Associated Control Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel
Figure 59: Call Release Following a Channel Change
188 / 262
5 Call Release
5.3 Call Release - Special Cases

Call Release can occur for reasons outside normal service. This section treats the following special cases in which Call Release happens: Call Release following Reset BSC-initiated Call Release BTS-initiated Call Release Mobile station-initiated Call Release Remote Transcoder alarms.
5.3.1 Call Release Following Reset

Resets are used in software/hardware failure situations, or when the database is corrupted and recovery procedures have failed. The MSC can reset all calls within a BSC or an individual circuit. For example, if the MSC loses dynamic information regarding calls (i.e., preventing it from providing such services as accounting), it can send a reset or a reset_circuit message to the BSC.
5.3.1.1 Reset
The MSC initiates Call Release when it has to release all calls associated with the BSS (Reset). The MSC sends a reset message containing a cause value to the BSC. The BSC then: Sends an alarm to the OMC-R Sends a block message to the MSC to block circuits Starts to clear all calls in the BSS. For each call, the procedure in Normal Release (Section 5.2.1) is repeated. For each SCCP connection on the A Interface, the BSC can send an SCCP_release message and release any A Interface resources associated with the SCCP. A timer allocates a certain amount of time for the calls to clear. When the timer expires, the BSC sends a reset_ack message to the MSC. Figure 60 shows the Call Release process after a reset is initiated.
189 / 262
5 Call Release
5.3.1.2 Reset Circuit

The reset circuit procedure is initiated from the MSC. The procedure informs the BSC that an individual circuit is no longer active in the MSC. This triggers the call clearing procedure if the circuit has an active SCCP connection. The MSC sends a reset_circuit message to the BSC for each circuit to be reset. Depending on the resources allocated, this can trigger the BSC to: Release the A Interface resources Initiate the release of the SCCP Initiate Call Release towards the BTS and mobile station.
MS BTS BSC
reset
MSC
send alarm to OMCR

e l releas channe
block
SCCP releas e
circuits blocked
disc
to releas e LAPD m
SCCP
releas
e com
plete
e l releas channe release
SCCP re
lease
indicatio
n
SCCP releas e com plete
disc
to rele ase L APD m
quest text re al con physic

physic al con text co nfirm rele indic ase atio n RF channel release
RF channe l release ac k
l physica quest re context physic al con text

nel rele
confirm
RF chan
ase
RF chan
nel releas
e ack
timer
reset a ck
LAPDm MS SCCP
: Link Access Protocol on the Dm Channel : Mobile Station : Signal Connection Control Part
Figure 60: Call Release Following Reset
Note:
If this procedure is invoked due to SCCP problems, then messages on the A Interface may not be passed. The MSC and BSC locally release resources for the A Interface connections. Refer to BSC-Initiated Release (Section 5.3.2) for more details.
190 / 262
5 Call Release
5.3.2 BSC-Initiated Release

The BSC is involved in Call Release for both the A Interface and Abis/Air interfaces. The BSC initiates Call Release on the A Interface when events internal to the BSS terminate communication with the mobile station. The Call Release towards the mobile station can already be in progress or have finished when the BSC initiates a release on the A Interface. If the mobile station is still connected when the BSC initiates a release on the A Interface, the release towards the MSC is triggered by the clear message from the MSC to the BSC.
5.3.2.1 Towards the MSC

The BSC initiates the release towards the MSC by sending a clear_request message. It also starts a timer to supervise the procedure. The MSC releases resources for the A channel and sends the clear_command message to the BSC. This command contains a cause value indicating that the BSC initiated the release. From this point, the Call Release follows the procedure described for normal Call Release (refer to Normal Release (Section 5.2.1)). The procedure starts with the BSC releasing A channel resources. It initiates the release procedure towards the mobile station (if still attached), and returns a clear_complete message to the MSC. This sequence is shown in the following figure.
MS BTS BSC
clea r req ues
MSC
and mm alue r co se v clea cau ing clud IE in
MIE MS
: Mandatory Information Element : Mobile Station
Figure 61: BSC-initiated Call Release toward the MSC
191 / 262
5 Call Release
5.3.2.2 Towards the Mobile Station/BTS

The Call Release procedure towards the mobile station/BTS releases: The radio resources associated with the call The RF channel. The BSC initiates the release of the radio resource by sending: A channel_release message to the mobile station via the BTS A deactivate_SACCH message to the BTS. This is the Normal Release procedure described in Normal Release (Section 5.2.1).
Note:
In this process, once the BSC considers the mobile station disconnected, it initiates release of the RF channel from the BTS. This can occur following: The release of the mobile station from the Air Interface (as in the Normal Release procedure) A handover, when the BSC is sure that the mobile station has successfully changed to the new channel. Refer to Calls Terminated Following a Channel Change (Section 5.2.2). An immediate assign procedure failure. This ensures that the SDCCH is available for reuse as quickly as possible A normal assignment failure or handover failure. This ensures that the traffic channel is available for reuse as quickly as possible.
192 / 262
5 Call Release
5.3.3 BSC-Initiated SCCP Release

The BSC initiates an SCCP release when a release procedure has failed or inactivity is detected in the BSC SCCP entity. Failed Release Procedure If there are no resources allocated to a call and the normal release of the SCCP connection has failed, the BSC forces the release of the SCCP connection: Internally by sending a level 3 command to its SCCP entity Externally by sending an SCCP_released message to the MSC. The BSC does not wait for a reply from the MSC before releasing the SCCP connection. If the original failure is due to a problem on the SCCP connection or in the BSC SCCP entity, the SCCP_released message may not be sent. If the message is sent, the MSC replies with an SCCP_release_complete message and releases any allocated resources. Inactivity Procedure The BSC performs an inactivity procedure for each SCCP connection. If the BSC detects inactivity, it assumes that the associated transaction is no longer active and therefore: Performs Call Release on the Air and Abis interfaces Initiates a reset circuit procedure if an A channel is active Initiates the release of the SCCP connection.
5.3.4 BTS-Initiated Call Release

The BTS initiates a Call Release only if it detects a LAPD failure or when O&M requests a restart of the BTS. Otherwise the role of the BTS in Call Release is to: Relay channel release messages to the mobile station Deactivate the SACCH under control of the BSC Send a release_indication message to the BSC when the mobile station releases the LAPDm connection.
193 / 262
5 Call Release
5.3.4.1 LAPD Failure

When the BTS detects a LAPD failure on a link between one of its frame units and the BSC, it forces the release of all mobile stations on active channels associated with that Frame Unit (TRE for a BTS A9100 or BTS A9110). The BTS stops SACCH frames and sends a Layer 2 disconnect message to each affected mobile station. It also starts a timer to supervise each LAPDm disconnection. The LAPD connection cannot be re-established until the BTS receives an acknowledgment, or the timer expires for each LAPDm connection. If a mobile station sends an acknowledgment, the BTS releases the RF resources. If a mobile station does not respond, the BTS continues to send Layer 2 disconnect messages up to a predefined number. It then waits for the timer to expire and the BTS releases the RF resources.
Note:
If the maximum number of disconnect retries is reached, the BTS LAPDm entity sends an error report to the BSC. This does not stop the timer supervising the disconnection. When all mobile stations are disconnected, the BTS attempts to re-establish the LAPD connection. The BTS then sends an error report to the BSC with a cause value indicating O&M intervention. This cause value indicates that the FU or TRE has cleared all calls.
194 / 262
5 Call Release
The BSC re-initializes the link with the frame unit and starts Call Release for the affected calls with the MSC. This sequence is shown in the following figure.
MS
BTS
Detection of LAPD failure. BTS stops sending SACCH frames.
disc
BSC
MSC
timer
disc
timer
disc
timer
UA
UA
release RF resources release RF resources
UA
release RF resources Reestablish LAPD connection

error report
cause value
Reinitialize FU or TRE link

clear re quest
mmand clear co
e use valu uding ca MIE incl clear comple te
FU LAPD MIE MS SACCH TRE UA
: Frame Unit : Link Access Protocol on the D Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Transmitter/Receiver Equipment : Unnumbered Acknowledgment
Figure 62: BTS-initiated Call Release following LAPD Failure
5.3.4.2 O&M Intervention

The BTS initiates a Call Release if its O&M entity requests a restart of a Frame Unit (TRE for a BTS A9100 or BTS A9110). The FU or TREs response to a restart request is to stop sending frames on the Air Interface. The BTS starts a timer to supervise the disconnection of the mobile stations. The timer allows enough time for the mobile stations to detect a radio link failure due to the lack of SACCH frames. The BTS RF performs a local release. The BTS resets the FU or TRE and waits for the timer to expire. When the timer expires, the FU or TRE attempts to re-establish the LAPD link with the BSC. The BTS sends an error report to the BSC with a cause value indicating O&M intervention. The BSC releases the RF resources and initiates a Call Release with the MSC.
195 / 262
5 Call Release
5.3.5 Mobile Station-Initiated Call Release

The mobile station can initiate a Call Release by: Initiating a radio link failure Disconnecting the LAPDm connection.
5.3.5.1 Mobile Station-Initiated Radio Link Failure

If SACCH frames are no longer received from the mobile station, the BTS starts to count the number of missing frames. When the BTS has counted a certain number of missing SACCH frames, it considers that the radio link has failed. This happens when the mobile station disappears from the Air Interface (caused by adverse radio conditions, the mobile station is switched off, fatal error, etc.).
Note:
There is an optional feature where, after a number of missing SACCH frames, the BSC sets both mobile station and BTS power to maximum in an attempt to regain the Air Interface. If the BTS continues to register missing frames, the radio link fails as described below. The BTS sends a connection_failure_indication message to the BSC with a cause value indicating that the radio link has failed. The BSC initiates Normal Call Release procedures to the BTS by sending an RF_channel_release message to the BTS and a clear_request message to the MSC. This is shown in the following figure.
MS
Interruption of SACCH frames
BTS
BSC
MSC
start counter
connec tion fa ilur e indi ca tion
cause value
clear
reques
se elea el r hann RF c
clea
mm r co
and
lue e va caus ding nclu IE i M
MIE MS SACCH
: Mandatory Information Element : Mobile Station : Slow Associated Control Channel
Figure 63: Call Release due to Mobile Station-Initiated Radio Link Failure
196 / 262
5 Call Release
5.3.5.2 Mobile Station-Initiated LAPDm Disconnection

If the mobile station has an error which unexpectedly terminates the call, it sends a disconnect message to the BTS. The system reaction to the disconnect message in this instance is the same as when the disconnect message from the mobile station is prompted by a channel_release message from the BSC (as explained in BSC-Initiated Release (Section 5.3.2)).
5.3.6 Remote Transcoder Alarms

If the Transcoder detects a break in communication with the BTS, it sets a timer. This timer is defined by GSM standards. On expiration of this timer, the Transcoder sends an alarm to the BTS. If the BTS remote Transcoder alarm detection is active, a connection_failure_indication message is sent to the BSC with a cause value indicating a remote Transcoder alarm. If the BTS detects a break in communication with the Transcoder, it sends a connection_failure_indication message to the BSC with a cause value indicating a remote Transcoder alarm. See the figure below. During an internal handover, this can cause remote Transcoder alarms to arrive at the BSC, as the connection is still active but the call has been handed over. The BSC ignores these alarms for a guard period on new and old channels during handover.
MS BTS BSC MSC
TC detects a communication break and times out
Alarm
con nec tion failu re in dica caus tion e va lue

ase l rele nne cha RF
clea r req ues t
clea
MIE inc
r co
mm
and
se v alue
g ludin
cau
MIE MS TC
: Mandatory Information Element : Mobile Station : Transcoder
Figure 64: Call Release due to Communication Failure detected by Transcoder
197 / 262
5 Call Release
5.4 Preserve Call Feature

The Preserve Call feature avoids locking the cell before modifying its logical configuration. The OMC-R marks the TRXs that are impacted by the modification and the BSC shuts down traffic only on those TRXs, preserving the on-going calls on other TRXs. The OMC-R provides the WTC in the Cell-Frequencies-Type group. This WTC is the one which applies by default to cell shutdown. Modifying a TRX means changing its baseband definition and/or its radio definition. The radio definition of a TRX is the allocation of a frequency or of an FHS/MAIO. If the definition of an FHS is changed, the TRXs which use this FHS must also be considered as modified.
5.4.1 Normal Release

In Normal Release, Preserve Call is set to false if one of the following parameters is modified: attached-sector (PC=False on modified TRX) ARFN (TRX-TS) (PC=False on modified TRX) ARFN-Set (FHS) (PC=False on TRX using the concerned FHS) MAIO (PC=False on modified TRX) HSN (PC=False on modified TRX) Channel-Type (PC=False on modified TRX) Zone_Type (PC=False on modified TRX) The OMC-R considers that the Zone_Type value for a single cell is Not Relevant. When the transition from Not Relevant to another value is not triggered on the concerned TRX, it remains set to False. NB_TS_MPDCH (PC=False on BCCH TRX) If TS0 of the TRX which is carrying the BCCH frequency is impacted, all calls must be shut down on the cell. In this case, the OMC-R marks all TRXs as impacted. This is the case when there is a modification of: BCCH frequency CBCH channel : combined <-> non-combined.
198 / 262
5 Call Release
5.4.2 Abnormal Release

In the following cases, even if the Preserve Call flag is not set to false by the OMC-R, calls are released at TRX or at cell level: Add TRX in a cell and the BSC TCH-RM Entity managing this cell (Traffic Channel Resource Manager) is full Inside the BSC software, the TCH-RM entities manage the radio time slot allocation on cell basis. A cell, mapped on a sector, is mapped on a TCH-RM entity. A TCH-RM entity can manage several cells with a maximum capacity based on the total number of TRX that is limited to 90. If a cell is extended with one or several TRX, the TCH-RM entity managing the cell takes into account the new TRX. If, adding the TRX, the limit of 90 is exceeded, the concerned cell can no longer be managed by this entity. This cell is mapped automatically by the BSC on another TCH-RM. In this specific case, all calls are released on this cell Due to the "adjust" algorithm, TRX(s) with Preserve Call set to true are disturbed in remapping Once the BSC has unmapped and remapped all TRX(s) with Preserve Call set to false, the BSC can be in one of the following situations: There are more TRX than TRE configured There are enough TRE configured but some are not available In both cases, the BSC checks whether a recovery is performed to ensure the availability of the TRX with the highest priority. The application of the recovery also leads to the release of some TRE. The OMC-R facility "Check Telecom Impact" related to PRCs is based on the "preserve calls" parameter value. Consequently, in the three cases mentioned above, the result of the check is not accurate.
199 / 262
5 Call Release
200 / 262
6 Handling User Traffic Across the BSS

This chapter describes the flow of speech and data traffic across the BSS.
201 / 262
6.1 Overview
The BSS performs traffic handling in the uplink and downlink directions for speech and data. The BSS uses the BSC and BTS to perform the required radio transmission, control and baseband functions of a cell and to control the BTSs in its domain. Transmission provides the efficient use of the terrestrial links between the BSS components. Together these components perform the required encoding and rate adaptation procedures.
6.2 Speech
Speech is passed from the mobile station to the PSTN and from the PSTN to the mobile station. This section describes how speech is encoded from the mobile station to the PSTN, as shown in the following figure. Speech in the opposite direction follows the reverse process and so is not described.
Full Rate Speech TCH A 13 kbit/s CIM 13 kbit/s 64 kbit/s A/D
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
PSTN
Mobile Station A 6.5 kbit/s CIM 6.5 kbit/s 13 kbit/s 64 kbit/s A/D
Half Rate Speech TCH
A A/D BIE CIM PSTN SM TC TCH
: Analog : Analog/Digital : Base Station Interface Equipment : Channel Encoded, Interleaved, and Modulated : Public Switched Telephone Network : Submultiplexer : Transcoder : Traffic Channel
Figure 65: Encoded Speech Transmission Across the BSS
202 / 262
6.2.1 Analog
The microphone converts speech to an analog signal. The analog signal is encoded into a digital signal depending on the type of traffic channel used: 13 kbit/s for a full-rate traffic channel (or enhanced full-rate) 6.5 kbit/s for a half-rate traffic channel. It is then transmitted on a 16 kbit/s (8 kbit/s for half-rate) radio time slot. 3 kbit/s and 1.5 kbit/s are used for signaling on full-rate and half-rate channels respectively.
6.2.2 Interleaving and Forward Error Correction

To pass speech over the Air Interface, error checking and redundancy are included to make sure speech information is correctly transmitted. This ensures that valid continuous speech is passed through the BSS. Error correction is based on high redundancy with complicated parity and cyclic redundancy methods. This is done to ensure that many types of parasitic and sporadic errors are detected and to some degree, corrected. In the case of speech, there is cyclic coding, convolutional and parity error encoding of the data. The speech data starts as 260 bits (112 bits) and, after forward error checking, is encoded as a 456 bit block (228 bit block). These blocks are then split into eight (four for half-rate), and interleaved with adjacent blocks into TDMA frames to be transmitted as radio wave bursts. This means that if some of the blocks are lost during transmission, there is a high chance that the other blocks hold enough redundancy to still have a valid speech block.
6.2.3 Speech Data Bursts

The interleaved blocks are transmitted over the Air Interface and are then reassembled in the BTS. As described above, when the interleaved blocks are reassembled and checked for parity errors, there is a high chance that the data can be recovered. In speech data the most significant bits are heavily protected and are always transmitted at the start of a TDMA frame. This ensures that even if the speech block cannot be reassembled, at least the most significant speech data can be used to provide a close approximation.
203 / 262
6.2.4 Digital Speech

Speech bursts are returned to digital speech blocks in the BTS. They are sent to the Transcoder as 13 kbit/s digital speech, plus 3 kbit/s for in-band signaling if they are full-rate speech. The channels on the Abis and Ater interfaces are 64 kbit/s. The speech blocks have to be multiplexed on to these links. This is shown in the figure below. Half-rate speech is sent to the BSC on the Abis Interface as 6.5 kbit/s, plus 1.5 kbit/s signaling. Two half-rate 8 kbit/s channels are associated together into a 16 kbit/s channel. On the Ater Interface a 16 kbit/s submultiplexing scheme is used for all types of traffic. The two paired 8 kbit/s Abis channels are independently switched by the BSC onto two 16 kbit/s Ater channels.
Ater Interface Atermux Interface Ater Interface A Interface
BSC
SM
SM
TC
MSC
30 x 16 kbit/s user traffic channels per link
SM TC
: Submultiplexer : Transcoder
Figure 66: Multiplexed Ater Interface
6.2.5 Digital 64 kbit/s A-law Encoded Speech

The Transcoder converts the 13 kbit/s digital speech to the 64 kbit/s A-law encoding. This is a standard digital speech interface for ISDN and PSTN exchanges. The information passes through the MSC and is sent to the PSTN. The Transcoder performs rate adaptation in both directions.
204 / 262
6.2.6 Enhanced Full-Rate

Enhanced full-rate provides advanced speech encoding on a full-rate traffic channel, for improved voice quality and user comfort. The feature uses a codec with ACELP coding. Enhanced full-rate is enabled in the BSC, on a cell-by-cell basis, by the O&M parameter EFR_ENABLED. When an enhanced full-rate call is set up, the following process occurs: 1. The mobile station makes a call requiring speech, in which it announces its codec preferences to the MSC in the setup message. 2. The MSC passes appropriate assignment_request and handover_request messages to the BSC. 3. The BSC uses the codec list supplied by the MSC to choose the correct codec, based on the support for the codec in the BTS and A Interface TRAU equipment. 4. The BSC activates the selected channel in the BTS, giving the indication of codec type. 5. The BTS configures itself to handle the correct channel coding, and starts sending TRAU frames to the TRAU, in order to configure the TRAU. 6. The BSC builds either an assignment_command message or a handover_command message, indicating to the mobile station which codec it should use when accessing the new channel. 7. Once the mobile station is attached, the BSC reports the selected codec type to the MSC. 8. In case of subsequent handover if the BSC has had to change the codec, the BSC informs the MSC of the change. For more information concerning enhanced full-rate, refer to the A1353-RA Configuration Handbook.
205 / 262
6.2.7 Half-Rate
Half-rate speech channels allow the operator to save time slots on the Air Interface when the number of available frequencies is very limited. Half-rate uses a different encoding algorithm than full-rate, in order to minimize any perceived loss of comfort by the subscriber. Use of the half-rate feature does create extra overhead on the A Interface. Half-rate is activated on a per-cell basis. In effect, the cell is capable of operating in Dual Rate mode, permitting either half-rate or full-rate traffic channels to be allocated. Half-rate can be applied to BSSs with the following equipment: BSC A9120 G2 Transcoder A9125 Transcoder One of the following BTSs: G1 BTS equipped with Dual Rate Frame Unit EVOLIUM BTS.
6.2.8 Adaptive Multiple Rate

AMR increases the quality of speech during conversations and also increases the offered capacity due to the provision of half-rate channels. When looking at current GSM codecs (full-rate, half-rate, and enhanced full-rate), each of them answers only one facet of capacity and quality requirements: Enhanced full-rate brings a higher speech quality than full-rate but with no noticeable impact on capacity Half-rate provides an answer to capacity requirement, but suffers from poor speech quality in bad radio conditions, or mobile station-to-mobile station calls when TFO (see Tandem Free Operation (Section 3.9)) cannot be used AMR is a new technology defined by 3GPP which relies on two extensive sets of codec modes. One has been defined for full-rate and one for half-rate. When used in combined full-rate and half-rate mode, AMR brings new answers to the trade-off between capacity and quality: Speech quality is improved, both in full-rate and half-rate Offered capacity is increased due to the provision of half-rate channels. This allows the density of calls in the network to be increased, with only a low impact on speech quality. The AMR technology also provides the advantage of a consistent set of codecs, instead of the one-by-one introduction of new codecs.
206 / 262
Alcatel offers two versions of AMR: Full-rate mode only, for operators who do not face capacity issues and want to benefit from the optimized quality of speech Combined full-rate/half-rate mode, for operators who want to benefit from the above defined trade-off between quality of speech and capacity. Through these codec mode adaptations, AMR is able to adapt the sharing of speech information and speech protection to current radio conditions, which can vary greatly, depending on location, speed, and interference. Therefore, for any radio conditions, the Alcatel BSS is able to offer the best existing codec, thus the best existing voice quality. AMR functionality can be activated by configuration of the cells and the BTS radio resources in all the network elements (OMC-R, BSC, BTS). The relevant algorithms are activated on a call-by-call basis. On the radio interface, the AMR can only be used with AMR mobiles. On the A Interface , the AMR can only be used if the NSS implements it. The AMR capability is available on a cell-by-cell basis.
6.2.8.1 AMR Normal Assignment

AMR is controlled on a per call basis by the MSC. 1. The MSC sends an assignment_request message to the BSC. In the assignment_request message, the MSC gives the Channel type IE, which indicates: In octet 4, if full-rate or half-rate is to be used and if the BSS is allowed to change In octet 5 and above, octets indicate that AMR is allowed in half-rate or full-rate. 2. The BSC activates the channel in the BTS by sending a channel_activation message, containing the IE Multirate configuration. It indicates the subset of codecs used for full-rate (or half-rate, respectively) link adaptation, the threshold and hysteresis sent to the mobile station for full-rate (or half-rate, respectively) link adaptation and, optionally, the start mode (i.e., the initial codec mode). 3. If the initial codec mode is not given, the BTS chooses the default start mode depending on the number of codec modes contained in the subset. 4. Once the channel is activated within the BTS, the BSC sends all AMR relevant parameters to the mobile station in the assignment_command message. 5. When the speech path is established and synchronization is performed between the Transcoder and the BTS, the BTS checks if the Request or Indication Flag (RIF) given in the TRAU frame is coherent with the type of codec mode (Indication or Command) that should be sent on the radio interface. If necessary, a CMI_CMR alignment command is sent to the Transcoder. 6. Once the BTS detects that downlink CMI/CMR is synchronized between the TRAU frames and the radio interface, it starts codec mode adaptation.
207 / 262
6.2.8.2 AMR O&M Management

The table below summarizes the main O&M configuration parameters that can be changed by the operator from the OMC-R. Parameter AMR_SUBSET_FR Description Bitmap of 8 bits defining the codec subset for AMR full-rate (1 to 4 codecs out of 8), on a per BSS basis. Bitmap of 6 bits defining the codec subset for AMR half-rate (1 to 4 codecs out of 6), on a per BSS basis. Flag on a per cell basis, used only for AMR calls, to enable or disable intracell handovers for channel adaptation. : Flag on a per cell basis to enable or disable AMR. This single flag is used for AMR full-rate and AMR half-rate. Offset for the channel mode adaptation hysteresis under normal load. It can take a value from 0.0 to 7.0 (step = 0.1) on a per cell basis. Offset for the channel mode adaptation hysteresis under high load. It can take a value from 0.0 to 7.0 (step = 0.1) on a per cell basis. Threshold for channel mode adaptation under normal load. It can take a value 0.0 to 7.0 (step = 0.1) on a per cell basis. Threshold for channel mode adaptation under high load. It can take a value from 0.0 to 7.0 (step = 0.1) on a per cell basis. Definition of thresholds on a per BSS basis.
AMR_SUBSET_HR
EN_AMR_CHANNEL_ADAPTATION
EN_AMR
OFFSET_CA_NORMAL
OFFSET_CA_HIGH
RXQUAL_CA_NORMAL
RXQUAL_CA_HIGH
AMR_THR_3, AMR_THR_2, AMR_THR_1 AMR_HYST_3, AMR_HYST_2, AMR_HYST_1
Definition of thresholds and hysteresis, on a per BSS basis
Table 31: AMR Configuration Parameters
208 / 262
6.2.9 Channel Mode Adaption

Channel mode adaptation is the change from one full-rate channel to an half-rate channel and vice-versa. This adaptation is independent from the codec mode currently used. This feature is available when the AMR half-rate option has been installed. The operator has direct operational control of it through the parameter EN_AMR_CHANNEL_ADAPTATION used for both changes from full-rate to half-rate and from half-rate to full-rate. Full-Rate Channel Adaptation Due to High Radio Quality This channel adaptation involves ongoing AMR full-rate communications within cells where half-rate is enabled. During any AMR call, the downlink radio quality is reported by the mobile station through the RX_QUAL. In the same time, the uplink radio quality is evaluated by the BTS through the RX_QUAL, and both are compared to a load-dependent threshold. Indeed, in a cell heavily loaded, a half-rate channel will be preferred even with a bad quality. Whenever both uplink and downlink radio quality are higher than this threshold, then an intracell handover takes place from a full-rate to a half-rate channel. To take into account the load, two different threshold values are used. The change will also only be performed if the current channel type is dual rate and it authorizes changes. Half-Rate Channel Adaptation Due to Low Radio Quality This channel adaptation involves ongoing AMR half-rate communications, using a dual-rate channel type authorizing changes. During any such AMR call, the downlink and uplink radio quality are evaluated with the same metrics as stated for the full-rate channel adaptation, and the same threshold comparison is performed. If either uplink or downlink radio quality are lower than this threshold, then an intracell handover takes place from a half-rate to a full-rate channel. To take into account the load, two different thresholds are also used but they differ from the ones used in full-rate adaptation by an offset value which is also cell load dependent. This offset allows a hysteresis to be introduced between full-rate and half-rate channels.
209 / 262
6.3 Circuit-Switched Data Modes

There are two types of circuit-switched data modes: Transparent Non-transparent. Refer to Transparent Mode (Section 6.3.1) for more information about transparent mode and to Non-Transparent Mode (Section 6.3.2) for more information about non-transparent mode. The following figure illustrates data transmission across the BSS.
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
PSTN
Mobile Station V.110 data blocks A 13 kbit/s CIM 13 kbit/s 64 kbit/s ISDN /Analog A/D
A A/D BIE CIM PSTN SM TC
: Analog : Analog/Digital : Base Station Interface Equipment : Channel Encoded, Interleaved, and Modulated : Public Switched Telephone Network : Submultiplexer : Transcoder
Figure 67: Data Transmission Across the BSS
6.3.1 Transparent Mode

Transparent data mode is based on the V.110 protocol. V.110 is an ITU recommendation. It specifies how ISDN supports DTE. It also specifies the transport of synchronous/asynchronous data over a synchronous link. Data is packaged and sent to the Transcoder in the same way as speech. It is converted to the 64 kbit/s ISDN format for data transmission. Error handling is dealt with by the Air Interface. Transparent mode implies that the following functions are performed by the BSS: Interleaving and Channel Coding Rate adaptation.
6.3.1.1 Interleaving and Channel Coding

Interleaving for data is more complicated than for speech. The data block is split into 22 parts for interleaving 9.6 kbit/s and 4.8 kbit/s data rates. For 2.4 kbit/s, the interleaving is the same as speech. The lower the data rate, the more space can be used for redundancy and error detection. This lowers the error rate. The Air Interface performs the error handling. The V.110 data packets are grouped together and transmitted across the Air Interface exactly like speech. The table below shows the data rate and error rate. A low data rate provides more space for a better forward error correction scheme, in turn reducing the number of errors.
210 / 262
6.3.1.2 Rate Adaptation

Data is packaged differently in V.110 for different data rates. The bandwidth is reduced and therefore the rate is lower. See the table below for the rate conversions. The Transcoder plays the final role in the rate adaptation when the data stream is adapted to 64 kbit/s packets. There is a difference between data and speech rate adaptation. Speech is encoded to A-law, while data is transposed to the first bit and, if required, the second bit of a Pulse Code Modulation byte. PCM transmission is at 8 000 bytes (64 kbit/s). The 8 kbit/s and 16 kbit/s intermediate rates (before the Transcoder) are transposed as 1 or 2 bits per byte respectively. Error Rate (at Full-Rate) 0.3% 0.01% 0.001%
User Rate 9600 4800 <=2400
Intermediate Rate 16 kbit/s 8 kbit/s 8 kbit/s
Radio Interface 12 kbit/s 6 kbit/s 3.6 kbit/s
Table 32: Circuit-Switched Data Rate Conversions Across the Air Interface
6.3.2 Non-Transparent Mode

Non-transparent data mode is similar to transparent data mode, although data is transmitted as packets from the modem on the mobile station to the modem in PSTN. Error handling is handled end-to-end. Non-transparent data mode is a data transmission protocol. It is based on sending RLP packets as four V.110 frames. This is the same process used in transparent mode. Interleaving and channel coding are still used, as they are in the transparent mode. The RLP adds extra protection and also allows the retransmission. Packing RLPs in four V.110 frames ensures transparency over the network. RLP packet size is the same as a radio block size, so it is transmitted as one radio block. Non-transparent data mode uses a 12 kbit/s radio interface rate. Interleaving and channel coding are at 9.6 kbit/s (the same as in transparent mode). The only difference between transparent and non-transparent modes for the BSS is the processing of the four V.110 frames of an RLP packet.
211 / 262
Error handling and rate adaptation are handled as follows: Error Handling Non-transparent data mode has a better error rate as there is no forward error checking or interleaving. Therefore, the size of packets remains small and less prone to errors. There are however, some cyclic redundancy bytes and the protocol is very similar in principle to LAPD. Rate Adaptation There is no rate adaptation in non-transparent mode. The rate can only be adapted by physically transmitting less than the full bandwidth available. The data rate is also limited by the number of errors, as packets have to be retransmitted. The difference between transparent and non-transparent mode data links is transparent to the Transcoder, but not to the BTS. The Transcoder, as described in transparent mode, puts the data in the first bits of a PCM byte. The BTS must ensure that an RLP packet maps into four V.110 frames numbered 0, 1, 2, 3. These must be sent in one block on the Air Interface.
6.4 Short Message Service - Cell Broadcast

There are two types of SMS: Point-to-point SMS allows a short message to be sent to, or received from, a mobile station SMS-CB allows messages to be broadcast to the mobile stations (i.e., one way). SMS-CB can be used for a number of reasons, e.g., to transmit emergency information, road traffic information, etc. An SMS-CB message can be transmitted to all the cells connected to the BSC, or to selected cells only, as required. The following figure shows the SMS-CB components.
Broadcast Message set up by OMCR Operator Broadcast Message to Selected Cell(s) BTS Message broadcast to all Mobile Stations Transmission Request BSC SMSCB commands and signaling CBC Broadcast Message set up by CBC Operator OMCR SMSCB commands and signaling HMI
CBC HMI SMS-CB
: Cell Broadcast Center : Human Machine Interface : Short Message Service - Cell Broadcast
Figure 68: Short Message Service - Cell Broadcast
212 / 262
6.4.1 SMS-CB Operation

The SMS-CB is managed and operated from a separate CBC. The CBC is connected to the BSC and the data needed to connect the BSC to the CBC is sent from the OMC-R. The operator at the CBC inputs the cell broadcast message identifying the broadcast text and the selected cell identities. Only one broadcast message per cell, or cells, is allowed. Any subsequent message simply replaces the message being broadcast. The message is sent from the CBC to the BSCs handling the selected cells. The BSCs then send the message to the individual BTSs of the selected cells. On receipt of the transmission request message from the BSC, the BTS broadcasts the message to the mobile stations in the cell over the Cell Broadcast Channel of the Air Interface. For SMS-CB, the BSC supports only the connection to an external CBC platform. The SMS-CB implements all of the improvements of the phase 2+ recommendations.
6.4.2 Phase 2+ Enhancements

An external CBC can be connected directly to the BSC. This allows the BSC to send information to the CBC, e.g., billing information. Two types of connection can be used to connect the CBC to the BSC: CBC-to-BSC via PSDN This is the default connection. A BSC can be connected to one CBC. CBC-to-BSC via MSC The CBC and OMC-R must be connected to the same MSC In addition to the feature SMS-CB managed from CBC, the following enhancements are defined in the phase 2+ GSM recommendation: Greater throughput with a second CBCH channel (extended CBCH) Better responsiveness when urgent data is to be broadcast due to the use of high priority messages. Messages can be allocated a priority of high, normal, or background Better service availability through the restart with recovery indication feature. The feature brings also better convenience with the support of multipage messages.
213 / 262
6.5 Support of Localized Service Area

The aim of SoLSA is to link radio resources (cells) with services such as specific billing or differentiated access rights. These services are associated with LSAs (Localized Service Area). An LSA can be defined over several cells, and a cell can belong to several LSAs. One possible use of this feature is to enable the efficient deployment of dedicated corporate applications. The following description uses this example. In order to manage efficiently corporate LSAs, the Alcatel BSS SoLSA implementation: Favors the camping of SoLSA mobiles on cells belonging to an LSA where they have a subscription. These mobile stations will likely camp on the corporate cells, even if they are not the best ones Informs the end user that he is camping on a cell belonging to a subscribed LSA and thus that he can benefit from the LSA services. This is achieved through the Localized Service Area Indication SoLSA service. The localized service area concept gives the operator the basis to offer subscribers or groups of subscribers different service features, different tariffs and different access rights depending on the location of the subscriber. It is up to the operator to decide which services features are required for a specific service. The LSA can be considered as a logical subnetwork of the operators PLMN. This subnetwork can be configured by the operator. A subscriber can have LSAs at several PLMNs. The following list shows examples of different types of localized service area: Office indoors. The office cells are those that are provided by indoor base stations Home or office and its neighborhood. The localized service area can be broadened outdoors. The neighborhood cells outdoors can be included in the local service area Industry area. A company with several office buildings may want to have a localized service area that covers all its buildings and outdoor environments A part of a city or several locations.
214 / 262
6.6 PLMN Interworking

A foreign PLMN is a PLMN different from the own PLMN to which the cells internal to the OMC-R belong. Only cells external to the OMC-R can belong to a foreign PLMN. All internal cells belong to the own PLMN. Both OMC-R own cells and cells external to the OMC-R can belong to an own PLMN. The Alcatel BSS supports: Incoming inter-PLMN 2G-to-2G handovers Outgoing inter-PLMN 2G-to-2G handovers (optional feature). The operators are allowed to define handover adjacency links towards external cells belonging to a foreign PLMN, i.e., handovers from a serving cell belonging to the own PLMN towards a target cell belonging to a foreign PLMN. Inter-PLMN 2G-to-2G cell reselection The Alcatel BSS allows the operator to define cell reselection adjacency between two cells belonging to different own PLMN (which must thus be owned by two different BSCs). Multi-PLMN (optional feature). The Multi-PLMN feature allows operators to define several own PLMN in order to support network sharing (Tool Chain, OMC-R, MFS, Abis transmissions - and also BTS, via rack sharing). Inter-PLMN handovers and cell reselection between two different own PLMN are supported. The BSC itself cannot be shared and thus remains mono-PLMN (i.e., all BSC own cells belong to the same own PLMN). The Alcatel BSS supports several own PLMN (up to four, at least one). An OMC-R thus manage at least one (own) PLMN and up to eight PLMN (four own + four foreign). Both cell reselection and handover are allowed between two cells belonging to different own PLMN. The operator is allowed to define handover adjacency between two cells belonging to different own PLMN (which must thus be owned by two different BSCs). The OMC-R (and the Tool Chain) is by definition of the feature itself always shared between the different own PLMN. On the other hand: The MFS can be shared The BSC cannot be shared The BTS can be shared up to the rack sharing level (no radio part sharing) The Abis transmission can be shared The transcoder can be shared. The outgoing inter-PLMN handover feature is a prerequisite for the multi-PLMN feature.
215 / 262
216 / 262
7 Cell Environments
7 Cell Environments
This chapter describes the cell environments available in the Alcatel 900/1800 BSS.
217 / 262
7 Cell Environments
7.1 Overview
The Alcatel BSS provides coverage suited to the needs of urban, rural and coastal areas by offering a variety of possible cell environments. The BSS supports a set of cell configurations to optimize the reuse of frequencies. The operator may choose to deploy a network using both GSM 900 and GSM 1800 bands. The parameters to define cells are grouped into five types: Cell dimension. This consists of macro up to 35 Km (can be up to 70 km with extended cell), and micro up to 300 meters Cell Coverage. There are four types of coverage, single, lower, upper, and indoor Cell Partition. Two types of frequency partition exist, normal or concentric Cell Range. The cell range can be normal or extended Cell Band Type. A cell belongs to either the GSM 900 or GSM 1800 bands, or both in case of a multiband cell. The following figure shows various configurations of the normal GSM 900 or GSM 1800 cell type. Each of the following sections explain the functional differences between the cell described and the single cell configuration.
Inner Zone Outer Zone Single Cell Concentric Cell
Sectored Site Umbrella Cell Microcell Microcell Microcell Inner Cell Outer Limit Umbrella & Concentric Cell Microcell Microcell Microcell
Extended Cell
Inner Cell Outer Cell
Overlap Zone
Outer Cell Inner Limit
Figure 69: Example: Cell Configurations
218 / 262
7 Cell Environments
7.1.1 Rural and Coastal Coverage

In a rural and coastal environment coverage is principally a function of cell planning. Standard cell layouts provide coverage of up to 35 km. Extended cells, which have two collocated antennae, provide options covering traffic density and ranges up to 70 km.
7.1.2 Urban Coverage

In an urban environment the coverage is determined by the location of the BTS antennae. Two types of cells are normally used: Macrocells - where the antenna is located above the roof tops and propagation occurs in all directions. These cells can be sectored by using specific antenna patterns Microcells - where the antenna is located below roof top level, on building facades or street lights. Propagation occurs mainly as line of sight along the street, with strong attenuation at street corners Indoor cells. These three cell types can be used in a hierarchical cell environment where continuous coverage is provided by the macrocell (umbrella cell) and locations of increased traffic density are covered by dedicated microcells and indoor cells. See Umbrella Cell (Section 7.5) for more information.
7.2 Concentric Cell

The goal of concentric cells is to increase the frequency economy of the network. This is done by reducing the interference levels of some BTS carriers. These carrier frequencies can be reused for smaller distances. The inner zone serves a high concentration of mobile station calls in a small area, with a reduced maximum power output limit. The outer zone performs call handling for a greater radius with a normal maximum power output limit. The BCCH, CCCH and SDCCH in concentric cells are put on the outer zone frequencies. Traffic channel assignment during call connection can be allocated to either the outer or inner zones. It depends on the location of the mobile station at that time. The inner and outer zones are part of the same cell, and a frequency carrier is assigned either to the inner or outer zone. This is signalled by the zone_type flag of 1 or 0, (1=inner, 0=outer). The outer zone maximum power limit is the same as normal zones. The inner zone is controlled by two maximum power limit values: one maximum power limit value for the mobile station and one maximum power limit value for the BTS. The micro concentric, mini concentric, indoor concentric cells must be multiband (the allowed FREQUENCY_RANGE is PGSM-DCS1800 or EGSM-DCS1800). This restriction does not apply to the external cells.
219 / 262
7 Cell Environments
7.3 Sectored Site

A sectored site consists of one or more BTS. Each BTS hosts up to six antennae illuminating up to six sectors, each sector covering a separate single macrocell. The figure below shows a three-sector arrangement. The BTS in a sectored site contains up to three transceivers which are each allocated to different given sectors. Each sector and its associated cell are managed independently and are seen functionally, by the OMC-R and BSC, as separate BTSs connected in chain mode. Within the physical BTS site, there is a master BTS and up to two slave BTSs (for G2 BTS and Evolium A9100 BTS, each BTS can have three slaves using the Shared Cell feature, see Cell Shared by Two BTS (Section 7.6) for more information). Each BTS generates its own clock locally, but the slave BTSs are synchronized to the master BTS.
Sector 1
Cell 1
BTS Cell 2 Sector 2
Cell 3
Sector 3
Antenna
Figure 70: Sectored Site Configuration
220 / 262
7 Cell Environments
7.4 Extended Cell

An extended cell is made up of two cells, an inner and an outer, as shown in the figure below. The inner cell handles calls up to a distance of 35 km (the same as a normal cell), while the outer cell handles traffic from 33 km up to a maximum range of 70 km.
Inner Cell Highway Urban Area 70 km max Outer Cell
35 km max
Figure 71: Example of Extended Cell Topology

There are two types of extended cell, the standard and the enlarged. They are described separately.
7.4.1 Standard Extended Cell

The inner and outer cells are covered by two synchronized, collocated G2 BTSs or by only one EVOLIUM BTS. The reception (uplink) of the outer cell is delayed to correspond to a 33 km shift in range. Radio continuity between the two cells is ensured by the overlap zone. The inner cell uses two carrier units: Carrier Unit BCCH Inner: at the inner cell BCCH frequency Carrier Unit RACH Catcher: at the outer cell BCCH frequency, but with transmission switched off. Because the outer cell can have areas of strong signal within the inner cells coverage area, it is necessary to prevent a mobile station in such a region from camping on the outer cell frequency. This could lead to sudden signal degradation as conditions change, and eventual loss of the call. The RACH Catcher receives channel_request messages from mobile stations which are synchronized on the outer cell BCCH frequency, but are within 33 km of the BTS. The BTS knows, from the timing advance sent by the mobile station, that it is actually in the inner cell, and assigns the mobile station to an inner cell SDCCH frequency. The outer cell uses one Carrier Unit with reception delayed by 60 bits. This effectively shifts the logical position of a mobile station 33 km nearer than its actual position and allows it to be handled in the standard GSM 0-63 bit timing advance range. The handover procedure is controlled normally, with the settings ensuring that the necessary distance has been reached before handing a call over to the outer or inner cell. Different types of coverage are possible depending on the type of antenna used for the inner and outer cells. The example in the figure above shows an extended cell with an omnidirectional inner cell and directional outer cell.
221 / 262
7 Cell Environments
7.4.2 Enlarged Extended Cell

The enlarged extended cell is an extended cell designed to provide enlarged capacity for areas where sustained traffic is high. It is especially well-suited for rural areas and dense highways where more than one TRX is necessary to handle traffic. The enlarged extended cell relies on the general principles of the extended cell: it is made up of two sub-cells to handle calls up to a distance of 70 km. However, with enlarged extended cell the two sub-cells are covered by one BTS, assuring a higher synchronization rate. The following telecom features are supported: The TDMA frame time slots can be used independently, providing any TRX with full capacity Inner cell mobile station access requests use the outer cell BCCH frequency Handover between the two sub-cells BCCH TRX recovery.
7.5 Umbrella Cell

In much denser traffic areas, depending on the required traffic capacity, a hierarchical network is used, where continuous coverage is provided by an umbrella cell (macrocell), and traffic hot-spots are covered with dedicated lower layer cells of limited range. Fast moving mobiles are kept in the upper layer cell to avoid a high rate of handovers. For medium density areas small macrocells (called mini cells) are overlaid with one umbrella macrocell. See Mini Cell (Section 7.5.1) for more information. For higher traffic densities microcells are installed in all the streets where very dense traffic occurs. Umbrella macrocells provide continuous coverage for level and quality handovers, and saturated overlaid cells. Refer to Microcell (Section 7.5.2) for more information about the relationship between umbrella cells and microcells.
7.5.1 Mini Cell

Mini cells are used for dense urban areas where traffic hot-spots are covered by very small macrocells (500 m to 1 km radius) and continuous coverage is provided by an overlaid macrocell (5 to 10 km radius). The lower layer mini cells handle pedestrian traffic while the umbrella cell handles the faster moving mobiles. As only macrocells are used there is no street corner effect.
222 / 262
7 Cell Environments
The following figure shows the application of the two-layer hierarchical network, with macrocells for both layers, in a small town.
Umbrella Cell
Pedestrian area
Mini Cells Urban area
Figure 72: Umbrella Cell with Mini Cells
7.5.2 Microcell
Microcells have a small coverage area (less than 300 m radius). These cells are usually situated indoors or along streets in built-up areas. Microcells have an umbrella cell (1 to 2 km radius) to minimize the risk of losing calls by providing maximum coverage. The microcells small radius is created by limiting the maximum power output strategically to cover a pre-defined microcell area. Handover occurs more frequently in a microcell environment due to the small radius sizes. Microcell handovers occur: To handle stationary mobile stations (especially mobile stations used indoors) When a mobile station moves in a street covered by microcells To avoid losing calls. Whenever there is a risk of losing a call, a handover is triggered to the umbrella cell. Fast moving mobiles are handled by the umbrella cell. A mobile handled by a microcell is sent to the umbrella cell if the delay between handovers becomes too small. Conversely a mobile is sent to a microcell if it receives a high level of signal for a sufficient time. Call quality/control is achieved by providing four thresholds for microcell handover and one handover threshold for macrocell handover.
7.5.2.1 Micro-to-Micro Handover

Microcell to microcell handover occurs due to the proximity of the two cells. When the power budget is better in another cell, the mobile station is handed over to the cell which will serve the call more efficiently. This normally occurs in microcells serving in the same street.
223 / 262
7 Cell Environments
7.5.2.2 Micro-to-Macro Handover

The three types of micro-to-macro threshold handovers are described below. This handover type... High Threshold Handover Occurs when... the signal strength has dropped below the theoretical signal level at the radius of the cell. This would normally mean that the mobile station has turned a street corner. the mobile station level is under the high threshold and the signal level has dropped below the low threshold. The handover is to the umbrella/macrocell, which supports the call until the mobile station moves into another cell. When the macro to micro threshold is exceeded in the umbrella/macrocell, the mobile station is passed to a new microcell. the mobile station is forced to handover to the umbrella cell when no measurement reports are transmitted. This occurs after a number of consecutive SACCH reporting periods.
Low Threshold Handover
Rescue Handover
7.5.2.3 Macro-to-Micro Handover

This occurs when the mobile station signal level in a microcell is above the M_to_m threshold for a certain period. This threshold value must always be higher than the low threshold value of the cell. Otherwise, a handover ping-pong effect can occur between the umbrella and the microcell.
Note:
If the low threshold is not used, the M_to_m Threshold value must be above the high threshold value.
224 / 262
7 Cell Environments
7.5.2.4 Threshold Handover Example

The example in the figure below shows two typical cases of handover in microcells: Micro-micro handover along a street (Case 1 in the figure below) Signal levels rising and dropping, causing macro-micro handover (Case 2 in the figure below). This example shows the use of the two levels of macro-micro handover (strong to weak signal, and weak to weaker signal). This is represented by the high and low threshold handovers. This example also shows the macrocell handing back to a microcell once a stronger signal level is received.
High Signal Level 1 2
MicroMicro Handover High Threshold
d B m
6 M_to_m Threshold Low Threshold 5
Low Signal Level
Figure 73: Example: Handovers due to Threshold Triggering
Micro-Micro Handover (Case 1) Macro-Micro Handover (Case 2)
A mobile station is moving along a street. As it moves along a street, the mobile station is handed over from microcell to microcell (1). A mobile station turns a corner then moves indoors. 1. Call starts at (2). The signal level is normal. 2. The mobile station signal level drops below the high threshold level (3), e.g., when turning a corner. To protect the call, it is handed over to the macrocell until a better microcell is found. The call remains with the macrocell until a strong signal from another microcell is received (normal case). 3. If a strong signal from a microcell cannot be found, a weaker signal from a microcell with enough strength to be above M_to_m threshold level, but that remains below the high threshold is found (4). In this case, as long as the signal strength remains above the low threshold and there is not a better microcell, the call remains with that microcell (e.g., the mobile station is indoors). 4. The signal level drops below the low threshold (5). The mobile station is again passed to the macrocell (e.g., the mobile station moves further inside a building). The macrocell is used to ensure call quality. 5. The mobile station moves into a position where the mobile station reports a microcell signal level above the M_to_m threshold (6). The call is handed over to that microcell, e.g., the mobile station is still indoors, but has a stronger signal from a microcell.
225 / 262
7 Cell Environments
7.5.3 Indoor Cell

The aim of indoor layer support is twofold: Firstly, to enable a better radio coverage inside large buildings (hotels, shopping malls, corporate centers) by the public network Secondly, to unloaded the cells provided for outdoor coverage but which are accessible from these buildings. Indoor cells can be deployed in all types of network, even in very dense networks which already have two layers (upper and lower). The feature eases the optimization of multilayer networks which include cells dedicated to indoor coverage. Indoor coverage is performed mostly from outdoor BTS. Although already satisfactory in many cases, the indoor quality of service can be improved by using dedicated in-building equipment. Together with this improved quality, an increase in the indoor capacity can be achieved, particularly in high density public areas such as airports, train stations, shopping malls, business parks, etc. A three layer per band management is introduced and a new type of cell is defined (the indoor cell) that maximizes traffic in these indoor cells while preserving quality. In idle mode, classical criteria (C2) allows mobiles to be forced to camp on indoor cells. For example, when entering a building covered by an indoor cell, calls are automatically transferred from outdoor cells, whatever their type. When moving inside the building, calls are transferred from one indoor cell to another one, even if the received power from outdoor cells is higher. It is only when the mobile leaves the indoor coverage that it is transferred to an outdoor cell. It is important for the Operator to minimize interference from indoor to outdoor. Therefore, indoor cells will often be used with very low radiated power (picocells). In this context, the feature also provides enhanced Power Control algorithms. The cells added to the network for indoor coverage are referred to as indoor cells and form a new layer referred to as the indoor layer. The following figure gives an example of network structure with three layers and two bands.
Upper layer
Umbrella cell 1800 Umbrella cell 900
Microcell 1800 Microcell 900
Lower layer
Indoor cell 1800 Indoor cell 900
Indoor layer
Figure 74: Indoor Cell Example Network Hierarchy with Three Layers and Two Bands
226 / 262
7 Cell Environments
The already deployed network hierarchy has to be adapted as follows: If there were already two layers, cells belonging to the upper layer will remain unchanged. Outdoor cells belonging to the lower layer will also remain in the lower layer. New cells introduced for the indoor layer will belong to the indoor layer If there was only one layer, cells having the cell_layer_type single will become upper. New cells introduced for the indoor layer will belong to the indoor layer. There is no lower layer.
7.6 Cell Shared by Two BTS

The system is able to handle cells whose TRXs are located in two different BTS. This feature brings important flexibility by allowing: An existing site to be extended by only adding TRXs in a new BTS, not changing the arrangement of the existing BTS Existing cells to be combined into one, e.g., combine one 900 cell and one 1800 cell in order to create a multiband cell The support of 3x8 TRX configurations in two racks (instead of three) The support of 16 TRX per cell.
Note:
This feature only applies to BTS A9100. Each set of TRX in a certain BTS must have its own coupling. It is possible to combine the coupling output towards the same antenna through an additional duplexer, although this is a special installation. The fact that part of the sector is in another BTS does not increase the number of necessary antennae. For BTS A9100, each BTS can have one slave, but each slave can in turn have another slave, up to a maximum of three linked slaves for one master BTS. If linked BTSs support part of the same cell, the linked BTSs must be clock synchronized with each other (master/slave). With this feature, the operator can associate two physical sectors from different BTSs into one shared sector. This shared sector can be mono or dual-band and it can support one cell as a normal sector. It takes the identity of one of the physical sectors, called the primary sector. The other physical sector is the secondary sector.
227 / 262
7 Cell Environments
228 / 262
8 Operations & Maintenance

This chapter provides an overview and describes O&M functions in the context of an operational network. This chapter does not describe the principles of O&M. For more information about O&M, refer to the Operations & Maintenance Principles document.
229 / 262
8.1 Overview
To ensure that the BSS operates correctly, O&M actions are implemented at all levels within the BSS. The O&M functions in the BSS are grouped into three categories: Configuration Management The main benefit of configuration management is the reduced time needed to perform operations and reduce telecom outages. This is achieved by having fewer operator commands and providing smooth migration and equipment configuration. The main functions of configuration management include radio configuration management and equipment management. Fault Management Fault Management is used to supervise and to repair the network when anomalies occur. This is done through a sequence of steps from detection to report and recovery. These are carried out by all the BSS/MFS subsystems, and are reported to the operator at the OMC-R. Performance Management. Performance Management is used to monitor the efficiency of the system and the telecom services. It is controlled entirely from the OMC-R and provides measurements and statistics about various traffic events and resource use in the BSS.
8.1.1 Subsystem O&M Functions

The following table provides a brief description of the O&M functions at the subsystem level. This O&M function... Configuration Management Is used... To view and control network resources. Configuration Management allows the operator to: Configure the BSS/MFS hardware and software when it is first installed Change the network by adding, deleting, or moving network entities Upgrade to new hardware or software Change equipment and telecom parameters to improve system performance. For more information, see Configuration Management (Section 8.4).
230 / 262
This O&M function... Fault Management
Is used... By the BTS to monitor the condition of the hardware modules it manages, and report any change in status to the BSC. By the BSC to supervise its own hardware modules and report changes in status to the OMC-R. By the BSC and Transcoder together to provide a set of transmission O&M functions to ensure a high level of fault tolerance and reliability. The functions also provides efficient use of the terrestrial links between the equipment of the BSS. By the MFS to supervise its own hardware modules and report changes in status to the OMC-R. For more information, see Fault Management - Alarms (Section 8.5).
Performance Management
By the BSC and the MFS to: Collect raw measurement data from network elements Transfer the raw measurement data to the OMC-R, where the results are processed and displayed. For more information, see Performance Management (Section 8.6).
Table 33: Subsystem O&M Functions

For more information about O&M functions at the subsystem level, refer to the following:
BTS Functional Description EVOLIUM BTS A9100/A9110/A9110-E Functional Description
231 / 262
8.1.2 System O&M Functions

The OMC-R is responsible for O&M functions at the system level. Its principal operations are: Network configuration. Provides the operator with an interface to the system to: Perform software configuration management (files, version downloading) Perform hardware configuration management (e.g., update the configuration according to extension/reduction operations, configure certain BSS parameters such as Abis link characteristics and some BTS characteristics) Provide configuration functions for logical parameters; Network supervision. Provides the operator with an interface to the system to: Display alarm status and history Display equipment and resource states Monitor and display performance measurement results Provide Usage State on Demand observations Define and supervise counter thresholds (Quality of Service alarms). Network maintenance. Provides the operator with an interface to the system to: Access equipment management functions (test) Access resource equipment state management Lock and unlock equipment and resources Keep track of hardware and software configurations in the system and managing software versions Provide mediation between the BSS and one or more NMCs. This uses the Q3 interface Provide an interface to the electronic documentation collection. For more information about the OMC-R and its functions, refer to the and the .
232 / 262
8.2 O&M Control - Subsystems

O&M functions are controlled either at subsystem level using the LMTs and the IMT (for the MFS) or by the OMC-R at BSS/MFS level. Subsystem control is described briefly here.
8.2.1 LMTs and the IMT

Local Maintenance Terminals are used when performing maintenance tasks at the BSC, BTS, and Transcoder. LMTs are connected directly to the equipment. The operations available at the LMTs act only on the local hardware, not on logical resources. The IMT performs maintenance tasks at the MFS, using a Netscape browser. All these tasks (except for three tasks associated with alarms, enable/disable sound, view history file, and enable/disable external alarm management) can also be accessed from the OMC-R terminal. The IMT alarm tasks are not provided when the IMT is accessed from the OMC-R because the OMC-R already has its own alarm management tasks. The IMT software can be accessed from either the IMT or the OMC-R. It has three different user profiles: administrator, operational, basic. If the IMT software is accessed from the IMT, only one session at a time can be run. Two instances of the IMT can be in use at the same time. For example, if there is one IMT connected to the MFS, then only one IMT window can be opened at the OMC-R. For more information about LMTs, refer to one of the following:
BSC Terminal User Guide Transmission Terminal User Guide BTS Terminal User Guide EVOLIUM A9125 Compact TC Terminal User Guide EVOLIUM A9135 MFS IMT User Guide
8.2.2 OML Auto-Detection

An OML auto-detection feature has been introduced in order to take full advantage of the transmission configuration via OML feature (which is more reliable and more robust than configuration via the Qmux channel). The OML auto-detection feature provides the following benefits: Transmission configuration via OML on all EVOLIUM BTS No LMT configuration necessary during Move BTS Secure recovery after OML breakdown Simplification of BTS installation (for Plug and Play BTS). See OML Auto-Detection (Section 8.4.5) for more information.
233 / 262
8.2.3 Managed Objects

Managed Objects are used to represent elements of the Telecommunication TMN environment on the Q3 Interface in terms of system resources. This concept is also used to represent the activities of management function blocks performed on these resources. In Alcatels network management model, Managed Objects can be physical entities, such as a BSS, BTS, BSC, or a hardware module within one of these entities. They can also be a logical entity, such as programs or program routines which implement communication protocols.
8.2.4 Security Blocks

Alcatel has an internal object model structure, based on objects called Security Blocks. Security Blocks are only used for the BSC, the BTS, and the Transcoder. Security Blocks are only visible to an operator performing local maintenance using certain LMTs, i.e., BSC terminal, BTS terminal, or Transmission terminal. The SBL model is not used by the OMC-R or the IMT. The OMC-R can display SBLs in certain circumstances, e.g., in BSSUSM.
8.3 O&M Control - The OMC-R

The OMC-R is the primary control station for the BSS/MFS and is the heart of the O&M function. The OMC-R provides the operator interface used to perform Configuration Management, Fault Management and Performance Management actions. The following features help the OMC-R to manage O&M activities.
234 / 262
8.3.1 Multiple Human-Machine Interface

This feature permits one OMC-R operator to perform actions normally done by several OMC-Rs, typically during off-duty hours. The connection between the multiple access workstation and the other OMC-R hosts is made via an X.25 network. The following figure illustrates the principle of operation.
Central Site Additional Workstation Printer
HMI Server
Multiple Access Workstation
X.25 Network
OMCR Host 1 OMCR Host 2
OMCR Host n
HMI
: Human Machine Interface
Figure 75: Multiple HMI Access to OMC-Rs

The implementation of this feature takes advantage of the distributed configuration of the OMC-R which usually consists of a host machine and distinct local or remote HMI servers. The site used for multiple access contains the following: Printing facilities Additional workstations which connect to the multiple access workstation, but only connect to the same OMC-R Configuration of each OMC-R is specific to the multiple access workstation and its peripherals.
235 / 262
8.3.2 ACO
Alarm Call Out (ACO) is a process within the HMI server to perform alarm management tasks for a complete network. Alarms from the BSSs controlled by other OMC-Rs are directed to one OMC-R. These links are used to transfer alarm notifications from the controlled OMC-Rs to the ACO OMC-R as shown in the figure below. The ACO OMC-R collects alarms from these OMC-Rs, applies filters defined by the on-duty operator, sends the filtered results to a dedicated printer and sends e-mail to support technicians. ACO can be started and stopped from any OMC-R.
ACO OMCR Workstation
OMCR 3
OMCR 1
Area 3
Area 1
OMCR 2
Area 2
ACO
: Alarm Call Out
Figure 76: ACO Links
8.3.3 Secured X.25 Connection From BSC to OMC-R

The Secured X.25 Connection feature provides redundant links in the event of a link failure on either the OMC-R or BSC side. When a link failure occurs, the initiator system involved must process the changeover. The configuration for the X.25 links consists of two physical links, one for CMISE, and one for FTAM. The following figure illustrates the configuration without redundancy.
OMCR X.25 Network CMISE BSC A HSI 0 BOARD 1 2 3 CMISE OSI CPRA 1 FTAM BSC A FTAM BSC A
OSI CPRA 2
CMISE CPRA FTAM HSI OSI
: Common Management Information Service Element : Common Processor Type A : File Transfer Access and Management : High Speed Interface : Open System Interconnection
Figure 77: X.25 Without Redundancy
236 / 262
Definition of the primary and the secondary links based on their hardware configuration can achieve various types of redundancy, such as: OMC-R-side redundancy BSC-side redundancy Complete redundancy. The following figure illustrates these redundancy types.
OMCR X.25 Network HSI Board 0 1 2 3 3 1 2 OSI CPRA 2 Secondary Link BSC Primary Link OSI CPRA 1
Secondary Link Configurations 1. OMCR side redundancy 2. BSC side redundancy 3. Complete redundancy
CPRA HSI OSI
: Common Processor Type A : High Speed Interface : Open System Interconnection
Figure 78: X.25 With Redundancy

When the OMC-R or the BSC sets up a CMISE or FTAM association, the subsystem chooses the active link. The active link is the primary link if it is in traffic, otherwise it is the secondary link. The following events occur: The transfer is performed on the primary link if the association is successful. The association is attempted three times The primary link is set out of service if the association is unsuccessful after the third try If the secondary link is in traffic, it becomes the active link and the association is tried on this link. If the secondary link is out of service, the application is impossible. Links are periodically tested for availability. When the primary link is recovered it becomes active and in traffic. Loss of one link (i.e., primary or secondary) triggers an alarm and the recovery triggers the end of alarm.
237 / 262
8.3.4 Electronic Documentation

Installation and use of the electronic documentation collection depends of the configuration. Small Configurations The documentation collection is installed on each OMC-R as a collection without a Verity search engine. To search the documentation collection, install the documentation collection CD-ROM on a single PC, and use the search function provided on the CD-ROM. Standard, Large, and XLarge Configurations. The license for the documentation collection and Verity search engine is installed on one OMC-R. All other OMC-Rs on the same site are connected to this OMC-R. The maximum number of users that can be managed for each search engine license is 75. This corresponds to a site with five Large configuration OMC-R. Refer to A1353-RA Capacity per BSS Category for more information on the various OMC-R configurations.
8.4 Configuration Management

Configuration Management, simply, is the process of putting in place the essential hardware and software components of the network, and determining their operating capabilities. The table below shows the configuration management functions of each network element. Network Element BSC Configuration Management Functions Software and database replacement Reading and modifying logical parameters. BTS Supervision of the BTS equipment. This includes initializing and configuring the BTS Transfer of software and data files to the FUs (G1/G2 BTS) or TREs (BTS A9100/A9110) Software and database replacement Auto Identification (BTS A9100/A9110 only). See Auto-Identification (Section 8.4.4) for more information Application of the logical configuration of the BTS. Transcoder Communication through the Q1 Interface with the Transcoder, SM and BIE modules Permission for configuration and reconfiguration of the Transcoder, SM and BIE modules.
238 / 262
Network Element TSC MFS
Configuration Management Functions Communication through the LAPD link with the BSC Reading and modifying parameters Control station and GPU configuration Framer configuration for Gb Interface messages GPU switch configuration for circuit-switched connections.
Table 34: Configuration Management Functions

For detailed information about configuration management refer to Configuration Management in the Operations & Maintenance Principles document or the descriptive documentation.
8.4.1 Hardware Configuration

Hardware Configuration enables the operator to: Control the placement in service of both BSS and MFS hardware Control the manner in which deployed hardware elements will act and interact within the BSS and MFS Modify the parameters that control these elements. It also permits the operator to view the current hardware configuration status of the network.
239 / 262
8.4.2 Logical Configuration

There are three types of Logical Configuration: Radio Logical Configuration allows the operator to change the parameters that control the Air Interface. This includes channel definitions, manipulating and reconfiguring the Carrier Units or TREs and defining the Frequency Hopping System. Cell Logical Configuration displays and modifies BSS logical parameters and threshold values which influence a cells operational behavior. These are divided into several classes which simplify searches. GPRS Logical Configuration allows the management of the following: The telecommunications application, including bearer channels, Gb Interface, Ater Mux Interface towards the BSC, and cell management domains Synchronization of the logical GPU resource states after a server changeover Configuration of a logical GPU when requested by the GPU (after a start, reset or changeover) Network service configuration and the supervision of the Gb Interface domain.
8.4.3 Software Configuration

Software Configuration enables new versions of the BSS software to be installed in the BSS. This feature also allows the operator to display current software versions of the BSS. BSC and BTS software is managed from the OMC-R, MFS software is managed from the IMT.
8.4.4 Auto-Identification
Auto-Identification gives the BTS A9100 and the BTS A9110 the capacity to recognize their own hardware configuration, and to provide this information to the OMU and the BTS Terminal. The auto-identification procedure is triggered by the OMU in the following situations: BTS/SUM power up BTS reset OMU reset/auto reset Module initialization (on maintenance operator command, or during a Local Recovery Action or Hardware Extension, the auto identification takes place only for the module(s) concerned by the operation). The BTS A9100 and the BTS A9110 capabilities received by the OMU at auto-identification are stored and can be used internally by the OMU software or sent to the BSC at Hardware audit.
240 / 262
8.4.4.1 Auto-Identification Components

Auto-identification has the following two components: Remote Inventory Remote inventory identifies the following: RIT type of each managed module Hardware capabilities of each RIT. RF Cable Identification RF Cable Identification provides the following information: Location of each RIT (subrack and slot) Sector to antenna network x mapping TRE to antenna network x mapping. For more information, refer to the BTS Functional Description and the BTS Terminal User Guide.
8.4.4.2 Consistency Checks

When a new Configuration Data Message is received from the BSC, the BTS A9100 and/or the BTS A9110 perform a consistency check of capabilities against the Configuration Data Message. They also do this at module initialization due to maintenance operator command or to a Hardware Extension operation. The BTS A9100 and/or BTS A9110 also check that the received OMU Configuration Parameter Data File is valid for this generation of BTS. Consistency checks are also performed by G1 and G2 BTS. For more information, refer to the following:
EVOLIUM BTS A9100/A9110 Functional Description EVOLIUM BTS A9100 Hardware Description EVOLIUM BTS A9110 Hardware Description BTS Terminal User Guide.
241 / 262
8.4.5 OML Auto-Detection

The OML auto-detection feature was introduced in order to take full advantage of the transmission configuration via OML feature (which is more reliable and more robust than configuration via the Qmux channel). The OML auto-detection feature provides the following benefits: The feature allows one extra time slot to be used for signaling (if no G1/G2 BTS are present on the Abis Interface). This provides an increase of telecom traffic on one Abis (because there are no time slots dedicated to the Qmux) There is no need for on-site BTS reconfiguration during a move BTS scenario (using the LMT to reconfigure the BTS). Also, the Qmux address for the EVOLIUM BTS can be modified remotely from the OMC-R There is no need for on-site BTS reconfiguration during an OML multiplexing change (from 16k to 64k) Secure recovery after OML breakdown Simplification of the commissioning procedure: Synchronization between OMC-R and commissioning personnel is no longer required. The BTS can be installed before or after the BTS is created at the OMC-R The OMC-R operator no longer needs to know on which time slot the OML is, and no longer needs to configure it manually Transmission configuration via OML for all EVOLIUM BTS.
242 / 262
8.4.6 Network Element Provisioning

Network element provisioning allows equipment that is not yet in commercial use to be distinguished from equipment that is under maintenance. This is not important for network monitoring. The feature introduces the status "commercial use" that is associated with the BTS. This status is changeable on line from the OMC-R. It is also available at the radio configuration export/import interface of the OMC-R for co-ordination with the operators information systems. For the BTS marked as "not in commercial use", potential alarms are raised with a "warning" severity and the performance measurement results are not taken into account. BTS marked as "not in commercial use" are not reported in the topology files sent to the NPA and A9156-RNO. They can also be filtered from the supervision view. Previously, as soon as a BTS was declared, it was supervised, but this raised permanent alarms when the BTS was not physically connected. If cells were created on this BTS and PM cell measurements ran on it, this led to very poor PM results as the BTS was not in commercial service. An attribute (commercialUse = On or Off) is associated with each BTS. The attribute can be changed at both the SC and the PRC radio network level to mark the BTS as out of commercial use, or in commercial use. When this attribute is set (i.e., the BTS is out of commercial use), all alarms related to the BTS have a maximum severity equal to a warning (except for the alarms from the MFS). At the OMC-R, the operator still sees all of the alarms and alarm states, and is able to trigger all O&M commands. This allows the operator to be aware of the fault situation of the BTS, but does not give a false status of the network. There is no PM handling and storage for BTS that are marked out of commercial use (except for the PM counters that are relative to RSL/OML traffic which are not filtered). To avoid any impact of cells not in commercial use on NPA indicators, the operator follows the sequence below: 1. Create the BTS. 2. Set it in no commercial use. 3. Map the cell onto the BTS. In the scenario above, none of the PM observed by the BSC on this cell are taken into account by MPM/NPA. If the operator maps the cell before putting the BTS in commercial use, the BSC starts reporting PM on it. As soon as PM results are collected by MPM/NPA, indicators are computed. Due to the extrapolation function of NPA, these indicators are computed for a long period. At this point, it is essential to prevent any reporting so as to avoid misleading indicators.
243 / 262
8.5 Fault Management - Alarms

The BSS generates alarms to signal a change in the behavior of a particular function within the system, such as a potential problem or a confirmed failure in the system. This section describes the alarm generation process. It describes the alarms and their effects on the system. The following table shows the fault management functions of each network element. Network Fault Management Functions Element BSC Fault detection, fault correlation and fault localization on all devices controlled by the processor BSC reconfiguration in case of loss of the BCCH, Terminal Control Unit/FU or a Carrier Unit (G1 or G2 BTS) BSC reconfiguration in case of loss of the BCCH, TCU/TRE (BTS A9100/A9110). Through the TSC, the BSC also performs the following functions: Monitors the status of the Transcoder, SM and BIE modules Provides local access to configure the Transcoder, SM and BIE modules via an RS-232 connection to the BSC terminal Gives access to the fault localizing features of the TSC (for example, the ability to set up loop-back tests).
244 / 262
Network Fault Management Functions Element BTS Testing the equipment. This includes collecting alarms and reporting to the BSC. Fault detection, fault correlation and fault localization for the BTS Management of equipment states. This includes triggering BTS channel configuration in case of a failure. Provides access for local diagnostics and configuration of the BTS BTS power supply control Event report management. See Alarm Generation (Section 8.5.1) for further information concerning events. MFS Collects all fault information for telecom and external alarms, the telecommunications hardware and the active server Records the fault information in a table Allows the IMT and the OMC-R access to the fault information Generates the ending alarm for pending alarms Manages the communications with the IMT.
Table 35: Fault Management Functions

For additional information about fault management, refer to the descriptive documentation and Fault Management in the Operations & Maintenance Principles document.
8.5.1 Alarm Generation

When an Alarm is generated, it is indicated as either: Fault (begin or end) If a fault arises, the related alarm is stored in the relevant BSS unit, and also in the OMC-R. The alarm begin message signals that a particular system activity has stopped due to an error. When the error is corrected, an alarm end message is sent to indicate that the condition no longer exists, and the alarm is taken out of the Alarms-in-Force List. Event An Event occurs when an unexpected situation arises during system operation.
245 / 262
Alarms can be generated as a result of previous alarms or events which influence other parts of the system. For example, when the Carrier Unit produces an alarm to signal an internal fault, the FU and the Radio Signaling Link produce alarms to signal that no information is being received from the Carrier Unit. Fault correlation and filtering actions are performed by the O&M modules in each unit, so that a single fault is sent as an alarm. In the case of the faulty Carrier Unit, an alarm is sent signaling a Carrier Unit fault. In this example, the loss of the RSL link is signalled from the BSC but is not correlated. Refer also to Alarm Handling in the Operations & Maintenance Principles document.
8.5.2 Alarm Functions

The following alarm functions help the operators monitor and correct fault conditions in the system.
8.5.2.1 Correlation
Correlation refers to the collection and analysis of all available fault indications for a particular problem. Fault correlation is performed to define where and why the fault occurred. An example of correlation is described below: 1. When several boards in the BTS report clock problems, these reports are correlated by the OMU. 2. The clock generator is faulty alarm is sent to the OMC-R via the BSC.
8.5.2.2 Filtering
Alarms are filtered to minimize the number of fault alarms reported and displayed to the operator and are displayed in order of severity. Refer also to Alarm Handling in the Operations & Maintenance Principles document. To reduce the number of alarms in the OMC-R, short end alarms are filtered. For these alarms a BEGIN is raised soon after the previous END. These END /BEGINs are not considered significant and are filtered. The operator sees fewer alarms and is informed that alarms are filtered, because the number of filtered alarms, if any, is indicated in AS.
8.5.2.3 Persistency
A fault is signaled only if there is no recovery after the timer expires. For example, for a LAPD failure of an RSL link, an alarm is only sent if the LAPD link has not recovered before the persistency timer has expired.
8.5.2.4 Alarm Surveillance

AS is an OMC-R application that supports fault management integration in TMN functions. It collects alarms issued by applications residing in the various Management Layers and processes them. To improve operator action visibility on alarms in RNUSM, the displayed information is reshuffled, as RNUSM was not designed to support supervision. The operator can see whether unacknowledged alarms are still present. Use of alarm acknowledge status, alarm status, and alarm synthesis are computed on all active alarms. The operator is, as yet, unaware of new alarms. It is presumed that an operator is aware of each alarm he acknowledges and unaware of alarms that he has not acknowledged.
246 / 262
8.5.2.5 Alarms-in-Force List

Each BSS component keeps an Alarms-in-Force List, so that the system knows that an alarm has begun. This list ensures synchronization of alarms throughout the BSS components. This makes the alarm situation visible at all times. The OMC-R also keeps track of all the Alarms-in-Force Lists for each BSS component.
8.5.3 BSC Alarms

The BSC detects alarms on the Abis and A trunk via the TCU and the DTC. It also detects alarms from each functional unit of the BSC. Refer also to Alarm Handling in the Operations & Maintenance Principles document.
8.5.3.1 Processor Failure

The active S-CPRA creates a daisy-chain map of all the processors in the BSC. Every ten seconds, the S-CPRA sends the map to the next processor. This processor sends the information to the next processor in line, until the S-CPRA receives the daisy-chain map. The daisy-chain map can be modified by an intermediary processor when that processor cannot send the map to the next processor in line. In this case, the intermediary processor skips the processor and removes that processor from the daisy-chain map. When the S-CPRA receives the map with the same processor missing twice in a row, it tries to recover the processor. If the processor cannot be recovered, the S-CPRA places the processor in the FLT state. The S-CPRA signals the processor failure to the OMC-R as follows: If the processor failure is in the TCU, recovery only takes place to ensure BCCH functionality. If a DTC processor fails, the BSC tries to inform the MSC, so that the MSC is aware the SS7 link is out of service. This implies: The loss and, if possible, the changeover of the SS7 The blocking of circuits.
8.5.3.2 Telecom Link or Trunk Failure

The TSC supervises its trunks between the Transcoder, BTS, and MSC. Failure of the Abis Interface is signaled to the BSC by all of the RSLs of the associated BTS. A single RSL failure reflects the status of the corresponding LAPD and FU. All A Interface faults are controlled by the Transcoder and the MSC. However they are also monitored by the BSC, in order to define the status of each "end-to-end" A-trunk. The following figure shows RSL fault correlation on the Abis Interface.
247 / 262
Note:
The BTS_TEL SBL describes the status of the GSM-defined BTS telecom functions. Its state is defined by operator commands, and correlation of the LAPD RSL states or of the different Carrier Units.
Fault Start RSL1 Persistency Correlation CPR Informed RSL State Change Alarm begin BTS_TEL ACTIVE INACTIVE Fault Start RSL2
Fault Start RSLN (last RSL)
CPR RSL
: Common Processor : Radio Signaling Link
Figure 79: RSL Correlation on the Abis Interface
8.5.3.3 Abis Interface Fault Monitoring

The BSC monitors the Abis Interface faults as follows: 1. The BSC detects the first LAPD RSL link failure of the BTS. The BSC starts a persistency timer.It puts the SBL of the RSL into a Maintenance Seized-Auto state while the following actions occur: The RITs are now in the SOS state. This is because the RIT belonging to the RSL still functions, but cannot communicate with the BSC Telecoms resources are blocked to prevent new activity at the BSC end of this link The RSL SBL is put into the FLT state, reflecting the loss of the RSL. 2. The persistency timer expires and the CPR is informed of the fault. If the link recovers during the persistency period, nothing is reported. Otherwise a correlation timer starts and waits for further RSL link failures belonging to the same BTS. 3. Once the correlation timer expires, the BSC sends a state-change-report message to the OMC-R. The message contains a list of all RSL that are in the FLT state. 4. The OMC-R is then informed about the state of the BTS_TEL. If all the RSLs belonging to the BTS have failed, then an alarm is sent to the OMC-R signaling the loss of the cell. When an SBL is put in to the FLT state, it is shown in the Alarms-In-Force List.
248 / 262
8.5.3.4 A Interface Fault Monitoring

When the BSC detects a DTC failure, the BSC puts the DTC SBL in the MSD-Auto state, then into the FLT state. Through TS0 signaling, the MSC is informed that the trunk is no longer operational and prevents all transactions requiring the A channel (including new mobile-originated calls) from using the failed link of the DTC. The failure is also signalled to the OMC-R. The TSC also detects a failure of the Ater link and signals the failure to the OMC-R.
Note:
The A channel is allocated only by the MSC.
8.5.3.5 Failures Detected by Software

Software throughout the BSC detects error and alarm conditions. It reports these conditions to the alarm handling software. The alarm handling software performs persistency, filtering and correlation actions on the received alarm indicators, and determines the required action (e.g., to isolate a faulty SBL). The figure below shows an example alarm report. If one or more RSL links remain for the failed BTS, an event change is sent. The BTS_TEL is put in a FIT state, as some channels for that cell are in operation. The AIFL shows the new alarm. The BSC marks the cell as degraded in service and reconfigures the BTS.
Figure 80: Example: Alarm Report
249 / 262
8.5.4 BTS Alarms

Alarms in the BTS are tracked by the OMU. The following sections describe the OMU hardware and alarm functions. BTS alarm collection is also described.
8.5.4.1 BTS Alarm Hardware

Alarm Hardware G1/G2 Alarm Buses OMU Function The OMU has a Q1 Interface to the Carrier Units, MCLU, EACB, and FHU modules in the system, as well as a Token Bus Interface with all of the FU modules. The BSII provides the OMU with an interface to the TRE functional unit, and to the antenna network x and TRANS & CLOCK functional entities, which have their own on-board controllers. The BCB provides an interface to all the functional entities in the BTS.
BTS A9100/A9110 Alarm Buses
Table 36: BTS Alarm Hardware Description
8.5.4.2 BTS Alarm Functions

Alarm Q1 Interface (G1/G2 BTS) OMU Function On the Q1 Interface, a system of double polling takes place. The OMU polls each subsystem individually to find out if there is an error. If there is an error, the OMU demands an error report from that board. Normally, the information from the error report is used as an alarm or an event notification. The OMU is informed by the FU about the type of error that has occurred. The OMU sends the alarm information to the BSC. Each module spontaneously reports errors to the OMU, which processes the report as an alarm or an event notification. The Base Station Control Bus operates in a master/slave configuration where the SUM functions as Pilot (master) and the functional entities function as Terminals (slaves) in normal conditions. The OMU collects alarm information on the BCB and sends it to the BSC.
Token Bus Interface (G1/G2 BTS)
BSSI (BTS A9100/A9110)
BCB (BTS A9100/A9110)
Table 37: BTS Alarms Functional Description
250 / 262
8.5.4.3 Alarm Collection

The mechanism for BTS alarm collection on all buses is as follows: 1. The alarm is added to the AIFL. 2. The OMU enters alarm information in a queued buffer. In this way, alarms are queued even if the link between the BTS and the BSC is temporarily unusable.If the buffer becomes full (over 100 messages): All fault/state change messages are deleted No more messages are sent until a state and alarm audit takes place to synchronize the BSC and the OMC-R. An audit BTS request is transmitted on a regular basis until an audit occurs. 3. The alarm messages containing the alarm information are transmitted to the BSC. The alarm messages are described in the BTS Alarm Dictionary and the BSC/TC Alarm Dictionary. 4. The message is sent to the CPRA, where it is date and time stamped. 5. The BSC performs one of two activities: If possible, it converts the alarm into a CMISE message, performs an action and sends a different alarm/event to the OMC-R, via the alarm queue Otherwise, it retransmits the message to the OMC-R, via the alarm queue. 6. The message is put in the alarm queue for BTS alarms. If the queue overflows, the BSC performs an Alarms-in-Force audit on all the modules in the BTS. This signals that information was received and lost when the queue overflowed, and that resynchronization is required. 7. The OMC-R receives the alarm over the CMISE link. The alarm is put into the AS component where it is logged.
251 / 262
8.5.5 Alarms Detected by the TSC

TSC O&M activities are similar to those performed by the BTS. The TSC has a Q1 Interface to the transmission equipment. A system of double polling occurs on the Q1 Interface: The first poll checks if there was a change in states. The second poll occurs only if the state has changed, in order to obtain more information about the changes. The Transcoder supervises PCM links. The loss of a link between the BSC and Transcoder is reported by the Transcoder to the TSC.
8.5.6 MFS Alarms

The MFS generates alarms to signal a change in the behavior of a particular function within the system, such as a potential problem or a confirmed failure in the system. The Global Alarm Manager manages the MFS alarms. It processes all hardware and telecom alarms and is responsible for: Collecting all fault information relating to GPUs, the active server, and telecom and external alarms Recording alarms in a table Allowing the IMT and the OMC-R to access the alarms Generating ending alarms when a fault is cleared (for example, when a GPU is replaced) Managing a communication session with the IMT.
252 / 262
8.5.7 Recovery Example: Carrier Unit Failures with BCCH

This recovery example considers a BTS with two Carrier Units. One Carrier Unit is used for BCCH channel handling, the other is used for normal traffic. If the Carrier Unit holding the BCCH fails, it is switched out and the second Carrier Unit takes the place of the first. As an example, this section describes the systems reactions when a Carrier Unit (TRE for a BTS A9100 or a BTS A9110) which has the BCCH channel fails.
Note:
In the BTS A9100 or the BTS A9110, the SBLs FU and Carrier Unit have been merged into one indivisible SBL, called the TRE. At the BSC, however, all BTS A9100 and BTS A9110 TRE faults are mapped to the Carrier Unit to provide compatibility with G1 and G2 BTSs. Thus, at the BSC all such errors are displayed as Carrier Unit faults. That is how they are presented in this example. FU faults in G1 and G2 BTSs continue to be reported as such.
8.5.7.1 Fault Recovery Mechanism

The recovery mechanism in the BSS allows a failed unit to switch to a replacement unit, such as: Redundant hardware A similar unit which had lower priority active use than the failed unit. (For example, the BCCH has to exist for the cell to function, so another Carrier Unit/FU pair (TRE for a BTS A9100 or a BTS A9110) is expendable to replace the failed Carrier Unit). The recovery mechanism of the BSS recognizes that the Carrier Unit can change to its twin Carrier Unit. A step-by-step scenario of Carrier Unit recovery is described in the next section.
8.5.7.2 Carrier Unit Recovery Scenario

1. The Carrier Unit holding the BCCH fails. 2. The BTS sends the BSC a recovery request, reporting that the Carrier Unit is faulty and is out of service, and that a recovery is required. The BTS also suggests a new Carrier Unit to the BSC, to be used to carry the BCCH. When the recovery request is received, the BSC temporarily blocks the resources while it checks if reconfiguration is available. If reconfiguration is available, the BTS_TEL SBL becomes FIT, all calls on the Carrier Unit are immediately released, and the RSL is blocked. 3. The BSC sends an alarm to the OMC-R, signaling the loss of BCCH. 4. The BSC attempts a recovery. The recovery command is BTS-CONF-DATA(2).
253 / 262
5. The BTS receives and acknowledges the recovery message. It then switches off the faulty Carrier Unit and switches on the second Carrier Unit. The second Carrier Unit adjusts its frequency to the BCCH frequency. 6. If the configuration was successful, the BTS sends a confirmation to the BSC. The BSC then sends the new sys_info (1-6). 7. The BCCH is now broadcasting on the same frequency as before, via the newly configured Carrier Unit. 8. The BSC sets the BTS_TEL SBL to FIT and informs the OMC-R by sending an end of alarm. The BTS_TEL remains FIT due to the loss of a channel. 9. If the new Carrier Unit was previously IT, its previously attached resources are lost. An alarm is sent to the OMC-R to update the information on lost channels. The following figure shows the redundancy process for a failed Carrier Unit with BCCH.
OMC BSC
BTS_TEL=IT
Resources blocked, BCCH reconfiguration possible
req ( Reco_ CU, F OS)
BTS
CU Fault
BTS_TEL=FIT
gin) H be 4 BCC of loss cell, rm ( Ala
BTS_C
ONF_
DATA
BTS_TEL=FIT
5 BTS performs the reconfiguration

ONF_ COMP L
(2)
6 8
of BC CH en d)
BTS_C
SYS_IN
FO (1..6
Alarm
ss (cell, lo
gin) CH be ss of T cell, lo ( Alarm
BTS_TEL=FIT
BCCH CU TCH
: Broadcast Control Channel : Carrier Unit : Traffic Channel
Figure 81: Example: Loss of Carrier Unit Holding BCCH.
Note:
The BTS_TEL SBL describes the status of the GSM-defined BTS telecom functions. Its state is driven by operator commands, or by correlation of the LAPD RSL states or of the different Carrier Units.
254 / 262
8.5.8 Automatic Power-Down

This feature is available only on the BTS A9100. It is used typically in an outdoor installation where the BTS has a backup battery power supply. In case of main power-supply failure, the BTS A9100 is automatically switched to battery power. This situation continues until the main power is restored or the battery is drained, whichever happens first. To extend the time during which the BTS A9100 can function under battery power, the BTS is reduced to a minimum configuration to reduce power consumption. Once a power-supply failure alarm arrives, the OMU starts a timer. If, once the timer expires, the alarm is still active, the OMU switches off all TREs except the BCCH TRE (one per sector for a sectored site), by placing the TREs to be powered down in the FOS state. If, in a given sector of a sectored site, the BCCH TRE is configured without a traffic channel, another TRE (which carries the SDCCH) is kept powered on, so that calls are still possible in this sector, though limited to one TRE. When the power-supply failure alarm disappears, the OMU starts a timer. If the alarm re-occurs before the timer expires, the OMU takes no further action. This is to guard against a possible unstable restoration of power. If the BTS power-supply remains stable until the timer expires, the OMU performs an autonomous auto reset with BTS activation. This re-initializes all available TREs. For more information on this feature, refer to the following:
EVOLIUM BTS A9100/A9110 Functional Description EVOLIUM BTS A9100 Hardware Description EVOLIUM BTS A9110 Hardware Description.
8.5.9 BSC Alerter

The BSC Alerter is a telecom supervision function which generates an alarm event when the system suspects abnormal behavior of a resource. This is system defined and not dependent on site configuration or traffic conditions in a particular cell. An Alerter functions by monitoring and computing the levels of specific Performance Management counters. If the count exceeds the operator-defined parameters, the Alerter generates an alarm for the BSC resource. This alarm is sent to the OMC-R operator.
Note:
For performance reasons, each alerter type has a maximum limit of 16 alarms. For more information about BSC Alerters, refer to BSC Alerters in the Operations & Maintenance Principles document.
255 / 262
8.6 Performance Management

The following provides a brief overview of performance management facilities in the BSS. For detailed information on performance management, refer to Performance Management in the Operations & Maintenance Principles document. For a description of individual counters, refer to PM Counters and Indicators. The following table shows the performance management functions of the BSC and the MFS. Network Element BSC Performance Management Functions Result collection and collation X.25-related counters Traffic measurements on radio channels Performance Measurement result reporting Trace invocation result reporting. MFS Collects the performance management counters associated with each logical GPU Creates a file of counter values.
Table 38: Performance Management Functions
8.6.1 Traces
Trace management coordinates and triggers trace activities within the BSS. Tracing is originated from the MSC. There are two types of tracing: Call tracing IMSI tracing. Call tracing follows a specified transaction (subscriber call, location update, short message, etc.) inside the BSC. When the specified transaction ends, or the transaction changes to another BSC, the trace activity ends. IMSI tracing is not restricted to speech. It includes information about the radio resources set up for the mobile. This includes, for example, location updating, supplementary services, short messages, etc. For more information on trace management, refer to Trace Management in the Operations & Maintenance Principles document.
256 / 262
8.6.2 Performance Monitoring

Monitoring system performance provides information that can be used to improve the system performance, optimize traffic levels, perform network radio planning and optimization, and plan network reconfiguration. The OMC-R manages the gathering of data collected from all the network elements by means of PM counters. PM counter values are collected into results files in the BSC. In the BSS, there are two types of raw counters: standard and detailed. These two counter types are gathered in the following counter groups: Cumulative counters Status inspection counters DER counters RMS counters. For the MFS, the counters are all standard counters. These counters are divided into two groups: Counters monitoring activity between the BSC and the MFS Counters monitoring activity between the MSC and the MFS.
8.6.3 Radio Measurements Statistics

In order to help the operator find "clean" frequencies for better frequency planning, the Radio Measurements Statistics (RMS) counters provide information based on the Mobile Assisted Frequency Allocation (MAFA) feature. MAFA is a standardized GSM feature that provides a way for the system to ask each mobile station to measure extra frequencies (frequencies of non-neighbor cells). MAFA can also be used to check interferences from non-neighbor cells. RMS is a BSC/BTS feature that records measurements from the BTS and mobile stations. For MAFA, specific mobiles supporting this standardized GSM feature are required. Every mobile station supporting MAFA acts as a potential spectrum analyzer and provides excellent information on the radio conditions for each single cell. Using this feature, the operator can: Detect interfered frequencies Assess the quality of the cell coverage Detect and quantify cell unexpected propagation Assess the traffic distribution in the cell from statistics on reported neighbor cells Evaluate the voice quality in the cell.
257 / 262
During the observation period, the BTS/FU keeps track of all the RMS statistics derived from the measurements reported by the mobile stations or measured by the BTS/FU itself on the TCH (SDCCH are not used with RMS). At the end of the observation period when the RMS data has been collected from the concerned BTS/FUs, the BSC builds a report (called the RMS result file). The transfer towards the OMC-R occurs via FTAM. In addition, it is possible during the observation period to apply MAFA (also called Extended Measurement Reporting). This procedure consists of sending an Extended Measurement Order (EMO) to the mobile stations. On receipt of the command, the mobile stations take one SACCH multiframe to perform measurements on specific frequencies. The measurements are reported via the EXTENDED_MEASUREMENT_REPORT message. The EMO is sent only once per call. The statistics related to MAFA are collected in the BTS and integrated in the RMS results. The statistics are based on the measurements performed at the BTS and the mobile station, on the TCH only. The statistics can be classified as follows: Radio related statistics. These can be classified as follows: Statistics related to the whole serving cell Statistics related to the TRXs. Voice quality statistics. Nine counters and indicators provide an overview of the communications quality (TCH only) for each TRX. Radio Measurement Statistics is available on G1 BTS Mk2, G2 BTS equipped with DRFU and EVOLIUM BTS.
8.6.4 Results Analysis

Using the OMC-R, an operator can view alarms and PM measurements from the OMC-R databases, and use this information to analyze data and produce reports. The OMC-R also generates QoS alarms to notify the operator of possible network problems. Counter and indicator information can be processed by a tool, in one of two versions: MPM, which is integrated in the OMC-R. It provides instant access to results files NPA is usually a standalone tool that runs on a separate Sun workstation (but in the case of a small configuration, NPA can be embedded into the OMC-R) It has nearly the same functionality as MPM, with the following differences: NPA can aggregate the data on a daily, weekly, or monthly basis, where MPM can only aggregate on a daily basis NPA cannot manage alerters. For more information on results analysis and the tools available to process counter and indicators information, refer to the Results Analysis section of the Operations & Maintenance Principles document.
258 / 262
8.7 Audits
Audits can be automatic or initiated by an operator. They can be performed at several levels: From the OMC-R to the Transcoder, the BSC, or the MFS From the BSC to the BTS. More information on Audits can be found in the Operations & Maintenance Principles document. as follows: Configuration Management Audits in Configuration Management Audits/Resynchronization Fault Management Audits in Fault Management Audits. Using the IMT, it is possible to perform a radio re-initialization, or a radio resynchronization of the MFS.
8.7.1 Audit Types

There are several types of audits, as described in the following table. Type Logical Audit Description A logical audit is performed on logical parameters. The logical parameters include dynamic cell information, its power ratings, information on adjacent cells, the radio configuration of the cell, and hopping and paging groups. No logical audit is provided for the MFS side. The software version audit controls the versions of software that exist on the subsystem. Hardware audits control the hardware on the subsystem. This audit provides a physical list of all components in the subsystem, their SBLs, and their associated RITs. The OMC-R updates the database with this information. The OMC-R requests the AIFL from a unit of the BSS. The OMC-R then compares this with its own list and updates its database if there are any differences. A state audit checks the state of SBLs on a particular subsystem, to ensure that SBL databases are synchronized. All the SBLs and their states are compared with the data in the OMC-R. If the SBL does not exist in the database, it is created and its state is registered.
Software Version Audit Hardware Audit
Alarm Audit
State Audit
Table 39: Audit Types
259 / 262
Two types of action are possible for the MFS: Re-initialize GPRS configuration Allows the OMC-R to force the logical configuration of the MFS, by deleting the current one, and then recreating one from scratch, using the current OMC-R configuration. This is roughly the equivalent of a Force configuration at the BSS side. However, it always induces some outages Resynchronize GPRS configuration. Allows the OMC-R to force the logical configuration of the MFS, by computing the differences with the current OMC-R configuration. It is the preferred synchronization action at the MFS side, as it minimizes the MFS outage. A suite of audits is automatically invoked by the OMC-R or the BSC to resynchronize the system. This is done: To perform a RESET/RESTART When there is a loss of links between subsystems. This ensures that the system databases are synchronized after autonomous operation while the link was down (i.e., the BTS_O&M was disabled). To make changes in the databases, without the possibility of aligning both subsystems To start a BSC Alarms-in-Force audit if the BSC alarm queue overflows To perform software database replacement. Audit information for the whole system is stored in the OMC-R.
8.7.2 Audit Flow

Audit flow is based on an action request from the OMC-R, or on an automatic request. The subsystem receiving the audit request performs an audit of its functional units. The reply can have one or several report messages to pass the information back to the request originator. The request originator can generate more actions based on the information received. For example, when the state of the Carrier Unit and its pair FU do not match, the BSC disables the FU/Carrier Unit pairs. The OMC-R, on reception of the audit report, updates its database. During download the results of the software audit are used to provide the list of modules the OMC-R needs to update the BSS subsystem. This is done by comparing the OMC-R lists of modules to transfer, and their version numbers, to see if they already exist in the subsystem. Only the newer versions are transferred to the subsystem.
260 / 262
8.8 Remote Inventory

The Remote Inventory feature allows an operator to get hardware and firmware information from the OMC-R. This information is used for retrofit, deployment or maintenance. The main benefit is that the amount of site visits can be reduced considerably. The Remote Inventory data is reported to the OMC-R by the BTS A9100 and the BTS A9110 which are very numerous and spread out in the field. The operator can get this data in two ways, automatic or on-demand. The on-demand mode remains available when the automatic mode is selected. Among the reported data is information that is very useful for retrofit or maintenance actions, e.g., the site name, the exact location of the board, the serial number, the part number and the variant. Sending the data to external tools is possible due to the ASCII file format. This format is the same as the one obtained when using a BTS Terminal at a BTS site. Existing external tools can therefore be reused. The Remote Inventory feature brings the following benefits: Reliability Inventory data is reported directly (periodically if requested) by the BTS to the OMC-R (through the BSC which is transparent), so the operator always has the correct information. To keep the OMC-R at a high level of performance, Alcatel recommends using the automatic mode with a seven-day acquisition period. Cost cutting It is no longer necessary to go on site to get hardware and firmware information before performing a retrofit or a maintenance action. Remote Inventory can be performed at the MFS. Information can be displayed for the selected subrack. For more information, refer to the IMT online help. For more information on Remote Inventory, see Remote Inventory in the Operations & Maintenance Principles document.
261 / 262
BLANK PAGE BREAK
262 / 262

Bss Documentation

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Bss Documentation

Загружено:

Авторское право:

Доступные форматы

Alcatel BSS

BSS System Description

BSS Document Concept Guide Release B8

3BK 20822 AAAA TQZZA Ed.04

BLANK PAGE BREAK

Status Short title

RELEASED System Description

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

3BK 20822 AAAA TQZZA Ed.04

Base Station Subsystem

MFS NMC PSDN PSTN SGSN

Figure 1: BSS in the PLMN

1.1.1 EVOLIUM Radio Solutions

BTS G1 and BTS G2 are still supported by EVOLIUM.

3BK 20822 AAAA TQZZA Ed.04

1.1.2 Extended GSM Band (E-GSM)

1.1.3 GSM 850

1.1.4 Frequency Band Configurations

3BK 20822 AAAA TQZZA Ed.04

1.2 BSS Functions

1.2.1 Call Set Up

Table 1: Types of Call Set Up

3BK 20822 AAAA TQZZA Ed.04

See Call Set Up (Section 3) for more information.

1.2.2 Call Handling

1.2.3 Call Release

1.2.4 Operations & Maintenance

3BK 20822 AAAA TQZZA Ed.04

1.3 BSS Components

1.3.1 Base Station Controller

3BK 20822 AAAA TQZZA Ed.04

1.3.2 Base Transceiver Station

1.3.2.1 Antenna Diversity

3BK 20822 AAAA TQZZA Ed.04

1.3.2.2 G1 and G2 BTS Antenna Diversity

OMU CONTROL BASEBAND CONTROL BASEBAND RADIO COUPLING

BIE CU FHU FU OMU RX TX

Figure 2: Antenna Diversity on G1 and G2 BTSs

3BK 20822 AAAA TQZZA Ed.04

1.3.2.3 BTS A9100/A9110 Antenna Diversity

ANT ANx ANy SUM TRE

Figure 3: Antenna Diversity on the BTS A9100

3BK 20822 AAAA TQZZA Ed.04

1.3.3 Transcoder And Transmission Function

: Base Station Interface Equipment : Submultiplexer : Transcoder Submultiplexer Controller : Transcoder

Figure 4: Transmission Components in the BSS

3BK 20822 AAAA TQZZA Ed.04

1.3.4 The Multi-BSS Fast Packet Server

1.3.4.1 GPRS Processing Units

3BK 20822 AAAA TQZZA Ed.04

1.3.4.2 GPU Protocol Management