Академический Документы
Профессиональный Документы
Культура Документы
2 / 250
Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.3.5 Multi-GPU per BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Extended GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.4 The A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.5 The Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.6 Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7 The Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Master Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Static Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Multiple PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 GPRS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 The Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 The BSCGP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 The GCH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 GPRS Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Radio Power Control and Radio Link Measurement . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Time Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14 16 16 17 17 17 18 18 19 22 23 25 26 28 29 30 33 33 34 34 35 36 36 36 37 38 39 39 41 47 48 48 49 52 52 52 53 54 56 56 57 59 59 60 61 62 63 64 64 65 65
3 / 250
Contents
2.5.2 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.5.3 PCM Link Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.5.4 Resource Reallocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 2.6 Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.6.1 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.6.2 Smooth PDCH Traffic Adaption to Cell Load Variation . . . . . . . . . . . . . . . . . . . . . . 70 2.6.3 GPRS Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.6.4 Delayed Downlink TBF Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.7 Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.7.1 GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.7.2 Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 2.7.3 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 2.7.4 Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 2.7.5 GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.7.6 GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.7.7 GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 3.2 Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.2.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.2.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3.2.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3.3 Mobile Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.3.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.3.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.3.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.3.4 IMSI Attach-Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.4 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3.4.1 Paging Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.4.2 Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.5 Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.5.1 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.5.2 In-queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.5.3 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.6 Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.6.1 Classmark IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.6.2 Classmark Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 3.6.3 Location Updating with Classmark Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 3.7 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.8 Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3.8.1 Ciphering Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.8.2 Ciphering Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.9 Tandem Free Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.9.1 TFO Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 3.9.2 TFO Optimization and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 4.2 In-Call Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 4.2.1 In-Call Modification Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.2.2 Circuit-switched Group 3 Fax Data Rate Change . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.2.3 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.3 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 4.3.1 Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.3.2 Synthesized Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 4.4 Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 4.4.1 Speech Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4 / 250
Contents
4.4.2 BSS Discontinuous Transmission Towards Mobile Station . . . . . . . . . . . . . . . . . 4.4.3 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 Radio Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Handover Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Target Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 Synchronous and Asynchronous Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 BTS Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2 BSC Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Call Re-establishment by the Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling User Traffic Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Enhanced Full-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Half-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Adaptive Multiple Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Channel Mode Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Circuit-Switched Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Non-Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Support of Localized Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 PLMNs Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Concentric Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Sectored Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Umbrella Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Mini Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Microcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Cell Shared by Two BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 O&M Architecture and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 O&M Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
141 142 144 144 144 145 146 148 149 151 152 159 160 167 167 168 170 171 172 173 173 178 179 179 180 182 183 185 186 187 188 188 190 191 192 194 195 196 197 198 200 200 203 204 206 207 208 210 210 211 215 217 218 218 219
5 / 250
Contents
8.3
8.4
8.5
8.6
8.7 8.8
8.2.2 O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 NE 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
220 221 222 223 224 226 227 228 228 228 229 230 231 232 234 234 235 238 240 240 241 243 243 244 244 245 246 247 248 250
6 / 250
Figures
Figures
Figure 1: BSS in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Figure 2: Antenna Diversity on G1 and G2 BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 3: Antenna Diversity on the BTS A9100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figure 4: Transmission Components in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figure 5: Cell Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 6: Logical Position of External Components Associated with BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 7: Location Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figure 8: TMN System Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figure 9: General Telecommunication Layers within GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figure 10: BSS Application, Transmission Layers and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figure 11: Time Slot 4 of a Time Division Multiple Access Frame Supporting Access Grant Channels . . . 41 Figure 12: Model LLC Packet Data Unit used in GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 13: The Alcatel GPRS solution in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 14: GPRS Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Figure 15: GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figure 16: Mobile Station-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . 74 Figure 17: GGSN-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Figure 18: Mobile-Originated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figure 19: Mobile-Terminated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Figure 20: Mobile Station Originating Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . 78 Figure 21: Network-Originating Packet Data Protocol Context De-activation Processes . . . . . . . . . . . . . . . . 79 Figure 22: GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Figure 23: GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Figure 24: Mobile Station-Originating GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Figure 25: Network-Originating GPRS Detach Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Figure 26: Radio and Link Establishment for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Figure 27: SDCCH Channel Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Figure 28: Immediate Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Figure 29: Connection for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Figure 30: Normal Assignment for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Figure 31: Channel Activation Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Figure 32: Channel Assignment Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Figure 33: Call Connection for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Figure 34: Radio and Link Establishment for Mobile Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Figure 35: Normal Assignment for Mobile Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Figure 36: CCCH with Three Blocks Reserved for AGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Figure 37: Four TDMA Frame Cycles Providing 24 Paging Sub-channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Figure 38: Paging Message Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Figure 39: Location Update with Classmark Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7 / 250
Figures
Figure 40: Location Update with Mobile Station Sending Location Area Identity of Previous VLR . . . . . . . 122 Figure 41: Ciphering Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Figure 42: Example of TFO Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Figure 43: Frequency Hopping within an FHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Figure 44: Different Forms of Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Figure 45: Power Control Flow of Measurement and Decision Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Figure 46: Power Output Balancing Based on Received Quality and Signal Levels . . . . . . . . . . . . . . . . . . . . 147 Figure 47: Quality and Level Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Figure 48: Better Zone Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Figure 49: Better Cell Handover (Power Budget) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Figure 50: Distance Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Figure 51: Umbrella Cell Load in Mobile Velocity Dependent Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Figure 52: Synchronous Internal Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Figure 53: Asynchronous External Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Figure 54: Mobile Station Disconnecting a Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Figure 55: Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Figure 56: Initiation of Normal Release by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Figure 57: BSC/BTS/Mobile Station interactions in Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Figure 58: Normal Release Final Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Figure 59: Call Release Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Figure 60: Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Figure 61: BSC-initiated Call Release toward the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Figure 62: BTS-initiated Call Release following LAPD failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Figure 63: Call Release due to Mobile Station initiated Radio Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Figure 64: Call Release due to Communication Failure detected by Transcoder . . . . . . . . . . . . . . . . . . . . . . 186 Figure 65: Encoded Speech Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Figure 66: Multiplexed Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Figure 67: Data Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Figure 68: Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Figure 69: Example: Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Figure 70: Sectored site configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Figure 71: Example of Extended Cell Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Figure 72: Umbrella Cell with Mini Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Figure 73: Example: Handovers due to Threshold Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Figure 74: Indoor cell example network hierarchy with three layers and two bands . . . . . . . . . . . . . . . . . . . . 213 Figure 75: Multiple HMI Access to OMC-Rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Figure 76: ACO Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Figure 77: X.25 Without Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Figure 78: X.25 With Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Figure 79: RSL Correlation on the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
8 / 250
Figures
Figure 80: Example: Alarm Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Figure 81: Example: Loss of Carrier Unit Holding BCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
9 / 250
Tables
Tables
Table 1: System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Table 2: GPRS System Information Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Table 3: GPRS System Information Messages Used with MPDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Table 4: Gb Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Table 5: BSCGP Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Table 6: Network Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Table 7: Time Slot Allocation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Table 8: PDCH Traffic Load States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Table 9: Types of Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Table 10: Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Table 11: Cell List Identifier and Paging Performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Table 12: Paging Request Message and Mobile Station Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Table 13: Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Table 14: Classmark Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Table 15: Mobile Station Ciphering Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Table 16: Downlink Discontinuous Transmission Status in Channel_activation . . . . . . . . . . . . . . . . . . . . . . . . 141 Table 17: Operator Discontinuous Transmission Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Table 18: Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Table 19: Mobile Station Maximum and Minimum Power Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Table 20: Circuit-Switched Data Rate Conversions Across the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Table 21: Configuration Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Table 22: Fault Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Table 23: BTS Alarm Hardware Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Table 24: BTS Alarms Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Table 25: Performance Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Table 26: Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10 / 250
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.
11 / 250
Preface
Assumed Knowledge
The document assumes that the reader has an understanding of: GSM GPRS Mobile Telecommunications Network Management concepts and terminology.
12 / 250
1 Introduction
1 Introduction
This chapter gives a brief overview of the Alcatel BSS, its functions and features. It describes: Overview BSS functions Internal and external components and interfaces BSS Network Management The distribution of telecommunications software in the BSS.
13 / 250
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 signalling 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
OMCR
NMC
: Gateway GRPS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Network Management Center : Packet Switched Data Network : Public Switched Telephone Network : Serving GRPS Support Node
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: G2 BSC G2 Transcoder G2.5 Transcoder BTS A9100 BTS A910 A935 MFS.
Note:
14 / 250
1 Introduction
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.
GSM 850
The GSM 850 MHz band has been introduced in the 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 in their network the GSM system with the GSM 1900 MHz to extend or replace their D-AMPS existing network. The term GSM 850 is used for any GSM system which operates in 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. 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. Refer also to Basic GSM System Specifications.
GPRS
GPRS, the solution chosen by European Telecommunication Standards Institute to answer the demand for increased data transmission rates, is now 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 within the BSS, see GPRS in the BSS (Chapter 2).
15 / 250
1 Introduction
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 signalling channel is used. Supplementary service calls, such as SMS, allows the mobile station to send and receive messages to and from the BTS. These calls pass small amounts of information. Therefore, only a signalling channel is used. 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 signalling channel. These calls use traffic channels. Call set up processes include: Radio and Link Establishment to assign a signalling 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. See Call Set Up (Chapter 3) for more information.
16 / 250
1 Introduction
17 / 250
1 Introduction
18 / 250
1 Introduction
19 / 250
1 Introduction
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
BIE CU FHU FU OMU RX TX
BASEBAND CONTROL
BASEBAND
RADIO
COUPLING
: Base Station Interface Equipment : Carrier Unit : Frequency Hopping Unit : Frame Unit : Operations and Maintenance Unit : Receiver : Transmitter
20 / 250
1 Introduction
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
ANT ANx ANy SUM TRE : Antenna : Antenna Network Type x : Antenna Network Type y : Station Unit Module : Transmitter/Receiver Equipment
BASEBAND
RADIO COMBINING
RADIO DUPLEXING
Note:
The configuration shown above (1 Sector, 3X4 Transceivers) is one example only. Other combinations of Antennas and TREs are possible. There is no antenna network y in the BTS A910, and the antenna network y is not needed if the sector has two TREs.
21 / 250
1 Introduction
Submultiplexers
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
22 / 250
1 Introduction
23 / 250
1 Introduction
Telecom functions: Radio and transmission resources control Radiolink 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 Signalling management on the GSL interface. 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 FR) BSC interface protocols (BSCGP, L2-GSL, and L1-GSL) RRM protocol. The PMU manages the corresponding Gb and GSL interfaces.
24 / 250
1 Introduction
Cell Mapping
Mapping a cell means that a cell is associated to 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 switch-over. 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
: GPRS Processing Unit
GPU
25 / 250
1 Introduction
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 the Classmark 2 is set to 1 (regardless of the value of the Band 2 bit of the Classmark 3) or The FC bit of the Classmark 2 is set to 0, and the Band 2 bit of the 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.
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.
26 / 250
1 Introduction
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 the 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 the 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 the Classmark 2 is set to 1 (whatever the value of the band 2 bit of the Classmark 3) If the FC bit of the Classmark 2 is set to 0 and the band 2 bit of the 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.
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.
27 / 250
1 Introduction
MSC
SGSN
GGSN
PSDN
OMCR
HLR
NMC
: Gateway GRPS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Network Management Center : Packet Switched Data Network : Public Switched Telephone Network : Serving GRPS Support Node
28 / 250
1 Introduction
MSC
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.
29 / 250
1 Introduction
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 three idle mode functions: Cell selection and cell reselection Location updating Overload control.
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.
30 / 250
1 Introduction
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). It 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.
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. 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 signalling 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 signalling channel and establishes a signalling path between the mobile station and MSC. See Mobile Originated Call (Section 3.2) for more information. When a signalling 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
Location Updating
31 / 250
1 Introduction
interrogates the old VLR for authentication and subscriber information. For further 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. The BSS adds the cell identity of the mobile station 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 in either its HLR or its VLR. Following a location update procedure, the VLR can assign a new Temporary Mobile Subscriber Identity 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.
Mobile Station
BTS
BSC BSC
MSC
VLR
Mobile Station
Protocol Messages
BTS
BSC BSC
MSC
VLR
VLR
Overload Control
To protect the system against overload, the system can bar access to mobile stations, by changing the RACH control information in the system information messages described in Table 1. For further information, see GPRS Overload Control (Section 2.6.3) and Overload Control (Section 4.7).
32 / 250
1 Introduction
33 / 250
1 Introduction
OMCR
Mediation Function
MFS
Network Element
BSC
BSS
BTS
BTS
BTS
: Operation Support System : Multi-BSS Fast Packet Server : Network Management Center
34 / 250
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 the following main areas: Association connection and disconnection mechanisms Message format and structure Command types. For further information on Network Management and the Q3 Interface see the Operations & Maintenance Principles document.
35 / 250
1 Introduction
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
36 / 250
1 Introduction
LAPDm
LAPDm
LAPD
LAPD
SCCP SS7
SCCP SS7
Layer 2
Layer 1
Layer 1
Layer 1
Layer 1
Layer 1
Layer 1
TC A Interface
Abis Interface
37 / 250
1 Introduction
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. Layer 2 provides the frame handling functions for the interface. It is also used to pass signalling messages using the International Telecommunications Union signalling System No. 7 protocol. This comprises: Message Transfer Part, which provides the mechanism for reliable transfer of the signalling messages Signalling Connection Control Part, which provides the mechanism to identify transactions relating to a specific communication.
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.
Ater Interface
The part of the A Interface between the Transcoder and BSC is known as the 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. This feature improves efficiency on the Ater Mux PCM connection between the G2 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 G2 BSC and G2 Transcoder allows up to 116 traffic channels.
38 / 250
1 Introduction
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.
The data link layer provides frame handling and signalling functions using the LAPD. This layer supports three types of signalling links: The Radio Signalling Link for signalling 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 signalling (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.
The BTS management 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 RR management sub-layer 3 on the Air Interface. Non-transparent messages include messages for radio link layer control and channel management.
39 / 250
1 Introduction
Modification of parameters is done from the OMC and propagated to the BSC and the concerned BTSs. A new connection type parameter is associated to each Abis link. The operator can set the parameter at Abis creation time. If the satellite link is to be made using the Ater interface, the new connection type parameter associated to 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.
40 / 250
1 Introduction
Physical Layer 1 Data Link Layer 2 Application Sub-Layer Radio Resources Management
The physical layer is a radio link where channels are divided by time and frequency. The data link layer provides frame handling and signalling functions, using a modified version of the LAPDm. 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).
The Air Interface is divided by frequency and time, using Frequency-Division Multiplex Access and Time Division Multiple Access. 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 Time Division Multiple Access 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 (Chapter 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. 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
AGCH
Frame 2
Frame 3
Frame 4
Frame 5
Figure 11: Time Slot 4 of a Time Division Multiple Access Frame Supporting Access Grant Channels
Channels can be divided into traffic channels and control channels.
41 / 250
1 Introduction
Traffic Channels
A traffic channel can be used for speech or data. The Alcatel BSS supports the following types of traffic channels: Speech: 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).
Control Channels
CCHs control communications between the BSS and the mobile stations. There are three types of CCH: 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. The CCCH communicate with mobile stations in the cell before a dedicated signalling 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. The DCCH and ACCH pass signalling information for a specific mobile station transaction. Two channels use the DCCH time slot: SDCCH: used for signalling and short message information CBCH: uses an SDCCH channel for Short Message Service Cell Broadcasts.
42 / 250
1 Introduction
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 signalling purposes as well as the SACCH slot SACCH: associated with a traffic channel, which uses 1 out of 26 slots for signalling purposes. An ACCH channel is always associated with a traffic channel.
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 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
Sys_info 2
BCCH
Neighbor cell BCCH frequency list Indication of which Network Color Code it is allowed to monitor. RACH control information.
BCCH
Extended Neighbor cell BCCH frequency list in same band as serving cell. This message is only sent if Sys_info 2 is not sufficient to encode all available frequencies. RACH control information. Spare bits.
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. Spare bits.
43 / 250
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 timeout. 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.
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.
44 / 250
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
CI Location Area Identity Cell options: Power control information Discontinuous Transmission information Radio link timeout Indication of which Network Color Code it is allowed to monitor.
45 / 250
1 Introduction
46 / 250
47 / 250
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 graphics-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 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.
48 / 250
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
MS
SGSN
GGSN
BSS
BTS GCH BTS Abis BSC GCH BSCGP Transcoder Ater MSC/ VLR Circuit Switched Traffic MFS
To PSTN
GCH
: BSC GPRS Protocol : Frame Relay Data Network : GPRS Channel : Gateway GRPS Support Node : Multi-BSS Fast Packet Server : Public Switched Telephone Network : Serving GRPS Support Node : Visitor Location Register
49 / 250
In the Alcatel solution, the Multi-BSS Fast packet Server with its associated interfaces is the BSS element. All other components are external to 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.
GPRS Mobiles
There are three classes of GPRS-capable mobile stations: Class A Class B Class C. Currently, only class B and C mobile stations are supported.
Class A Class B
Class A mobile stations can handle circuit-switched voice and GPRS traffic simultaneously. Class B mobile stations can be IMSI attached and GPRS attached at the same time, but use only one service (circuit-switched or GPRS) 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 mobile stations an be either IMSI attached or GPRS but not both, and can use circuit-switched or GPRS services alternately. 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.
50 / 250
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.
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.
See The Multi-BSS Fast Packet Server (Section 1.3.4) for details of the MFS
51 / 250
52 / 250
A primary Master Channel can be dynamically allocated as soon as there is GPRS traffic in a cell. This feature can be enabled on a per cell basis. If there is no GPRS traffic, the primary Master Channel is released in this cell. 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. The Primary MPDCH is dynamically allocated by the BSS upon occurrence of any GPRS traffic in the cell (receipt of either a downlink LLC PDU, or a channel request from a mobile station with any establishment cause). The primary MPDCH is dynamically de-allocated when no GPRS traffic is detected during a given period (typically a few minutes). This minimizes the TCU load (and also the CCCH load). 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 may 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 to be broadcast which enhances the overall performance of the network. For example, the permanent broadcast of C31 and C32 criteria enhances the cell reselection for all GPRS attached mobile stations. Better performance in a GPRS network by reducing the load on CCCH. Shortened access time for multislot mobile stations. A faster paging cycle. A higher radio resource efficiency due to the flexibility in the mapping of logical channels onto the physical channels.
53 / 250
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. This feature enables automatic dynamic allocation and release of secondary Master Channels based on common signalling traffic load estimates. This dynamically adapts the GPRS signalling capacity of the cell to the traffic demand. The secondary master PDCH are always dynamically established or released in the cell, regardless of whether the Primary Master Channel is statically or dynamically allocated. The feature provides the operator with the following improvements: Increase the GPRS signalling capacity as the traffic load increases in the cell. Avoids the need to reserve static radio resources to match the maximum traffic demand. Configuration of the allocation and de-allocation algorithm thresholds is performed automatically by the BSS.
54 / 250
The following table describes the parameters that can be defined by the operator. Parameter Name Definition Type Mandatory Rules
BS_PBCCH_BLKS Coded on 2 bits: 00=Block B0 used for PBCCH 01=Block B0 and B6 used for PBCCH 10=Block B0, B6, and B3 used for PBCCH 11=Block B0, B6, B3, and B9 used for PBCCH
Number 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.
Number BS_PRACH_BLKS <= BS_PRACH_BLKS_MAX Number BS_PRACH_BLKS_MAX >= BS_PRACH_BLKS S/(16 * BS_PRAC H_BLKS_ MAX) > round_trip_delay.
55 / 250
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 signalling 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.
This bi-directional channel is used for maintaining a continuous timing advance update mechanism.
56 / 250
57 / 250
PSI 2
PBCCH
The PSI 2 message is sent on the PBCCH in several instances (up to 8) in order to give information on: Reference frequency lists Cell allocation GPRS mobile allocations 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 PACCH/D of a mobile station that is in packet transfer mode.
PSI 3/3bis
PBCCH
The PSI 3/3bis messages are sent on 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 PSI3/3bis instances, the coding of the PSI3/3bis messages is optimized by compressing the redundant parameters.
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).
58 / 250
59 / 250
Note:
The common radio signaling functions of the BSCGP are handled on the GPRS Signaling Link, which is carried inside the Ater interface.
60 / 250
61 / 250
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.
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. A Temporary Block Flow is maintained only for the duration of the data transfer. The Temporary Block Flow 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 Temporary Block Flow in each direction, and the path of each Temporary Block Flow can be different.
62 / 250
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 re-selection is equivalent to circuit-switched call re-establishment. Refer to Call Re-establishment by the Mobile Station (Section 4.8) for more information.
63 / 250
2.4.2 Paging
Paging is the procedure by which the network contacts a mobile station. The network can coordinate 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. 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. 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
64 / 250
65 / 250
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 kbits/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.
66 / 250
67 / 250
Busy
Full
68 / 250
Allocated PDCHs
MAX_PDCH_GROUP 3
MAX_PDCH_HIGH_LOAD
Cell activated
GPRS MS PDCH
69 / 250
every TCH_INFO_PERIOD) for the PDCH traffic adaption load averaging algorithm.
70 / 250
of a network server as seen from this MFS. The timer range is 0-5000 ms (in 100 ms steps). The default value is 700 ms.
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 MS, the network maintains the downlink TBF by occasionally sending dummy downlink RLC data blocks to the MS, 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 MS, beginning with the next available BSN. When the network wishes to poll the MS 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 CS-1 downlink RLC data block. The LLC Dummy UI Command is an invalid LLC PDU and is discarded by the LLC entity in the MS.
Unacknowledged Mode
In RLC unacknowledged mode the MS detects the end of the TBF by detecting the Final Block Indicator (FBI) bit set to 1. The MS 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.
71 / 250
GPRS
Attach
Reque
st
Update
Locati
on
on nticati Authe
er scrib Sub ta Da
Subs c Data riber ACK
GPRS
Attach
Accep
: Home Location Register : Multi-BSS Fast Packet Server : Mobile station : General Packet Radio Service : Serving GRPS Support Node
72 / 250
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.
73 / 250
BSC
MFS
SGSN
GGSN
Context Reque st
st
tex Con
DP te P Crea sponse t Re
te PDP Activa
: Gateway GRPS Support Node : Multi-BSS Fast Packet Server : Mobile station : Packet Data Protocol : Serving GRPS Support Node
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 bidirectional 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.
74 / 250
GGSN-Originating Activation
MS BTS
The GGSN Packet Data Protocol context activation process is illustrated in the following figure.
BSC MFS SGSN HLR GGSN
PDU
Routin
g Info ACK
PDU N
otifica
tion R
eques
PDP C
ontext
Activatio
: Gateway GRPS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Mobile station : Packet Data Protocol : Protocol Data Unit : Serving GRPS Support Node
75 / 250
BSS
SGSN
2 3
RLC
PDU
5
PDU RLC ACK N / ACK
: Logical Link Control : Mobile station : Protocol Data Unit : Radio Link Control : Serving GRPS Support Node : Temporary Block Flow : Uplink
76 / 250
STAND BY
Pag PCH H or PPC Pack et Ch Requ annel est F L TB et U ent k c a P gnm Assi in g PS
2 3
READY
LLC PDU
DL
: Downlink : Mobile station : Logical Link Control : Paging Channel : Protocol Data Unit : Packet Paging Channel : Packet Switched : Serving GRPS Support Node : Temporary Block Flow : Uplink
77 / 250
BSC
MFS
SGSN
GGSN
tivate
PDP C
ontext
Reque
st
DeA
: Gateway GRPS Support Node : Multi-BSS Fast Packet Server : Mobile station : Packet Data Protocol : Serving GRPS Support Node
Figure 20: Mobile Station 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.
78 / 250
SGSN-Originating De-activation
MS BTS
Network originated Packet Data Protocol context de-activation processes are shown in the following figure.
BSC MFS SGSN
Delete PDP Conte xt Req uest
GGSN
SGSNOriginating
tivate DeAc
PDP C
ontext
Reque
st
DeAc
tivate
PDP C
ontext
Accep
GGSNOriginating
C
tiv DeAc
ate PD
P Con
text Re
quest
DeAc
tivate
PDP C
ontext
Accep
: Gateway GRPS Support Node : Multi-BSS Fast Packet Server : Mobile station : Packet Data Protocol : Serving GRPS Support Node
79 / 250
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.
80 / 250
RR Su
spend
Susp end
Susp end
T3
Suspe Suspe nd Ack nd Ack
MFS SGSN
81 / 250
Resu
me
Resu me
T_GPRS_Resume
T4
Resu Resu me A ck me A ck
se Relea annel RR Ch
Routing Area
Update Reque st
MFS MS RR SGSN
: Multi-BSS Fast Packet Server : Mobile station : Radio Resource : Serving GRPS Support Node
82 / 250
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 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. 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.
83 / 250
BSC
MFS
SGSN
GGSN
Detac
h Req
uest
GPRS
: Gateway GRPS Support Node : Multi-BSS Fast Packet Server : Mobile station : Packet Data Protocol : Serving GRPS Support Node
84 / 250
Network-Originating Detach
MS BTS
GPRS
Co
Detac
h Acce
pt
Cance
l Loca
tion AC
: Gateway GRPS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Mobile station : Packet Data Protocol : Serving GRPS Support Node
85 / 250
86 / 250
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. This chapter also describes the following parts of the Call Set Up procedure: Overview Mobile Originated Call Mobile Terminated Call Paging Congestion Classmark Handing Authentication Ciphering.
87 / 250
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.
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 signalling 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 signalling 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 signalling channel. These calls use traffic channels.
Service Calls
88 / 250
3 Call Set Up
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.4). Immediate assignment procedure allocates a resource to the mobile station and establishes a Radio signalling Linkbetween the BSS and the mobile station. A interface connection, to assign an SCCP signalling 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 Assigning a traffic channel, if required Connecting the call.
89 / 250
3 Call Set Up
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.). 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.
90 / 250
3 Call Set Up
MS
Channe l Reque st (RAC H)
BTS
BSC
MSC
REF
Chann
el Requ
ired
REF+R
FN+TA
SDCCH Allocation
n Ack
iate as
sign c
omma
nd
Immed
iate
TA+S
DCC
H+po
wer+
REF RFN+
R REF+
FN+T
A+SD
CCH
SABM
+ cm +
Service
Request
Establis
h Indic
UA
cm + Ser
vice Req
uest
cm + Ser
vice Req
uest
SCCP
Conne
ction C
onfirm
: Classmark : Mobile station identity : Mobile station power or BTS power : Random access information value : Reduced frame number : Description of the allocated SDCCH (Stand-alone Dedicated Control Channel) : Initial layer 3 message : Timing advance : Un-numbered acknowledgment
Figure 26: 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. 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.
91 / 250
3 Call Set Up
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
Chann
TA+S
MSC
el Acti
vation
er
DCCH
+pow
power SDCCH TA
: Mobile station power or BTS power : Description of the allocated SDCCH (Stand-alone Dedicated Control Channel) : Timing advance
92 / 250
3 Call Set Up
Immediate Assignment
The BSC builds and sends an immediate_assign_command message reiterating 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
nd omma sign c iate as d e m FN Im EF+R er+R +pow H C DC TA+S
BSC
Im
te as media
signm
ent (A
GCH)
Switch to SDCCH
REF RFN SDCCH TA
: Random access information value : Reduced frame number : Description of the allocated SDCCH (Stand-alone Dedicated Control Channel) : Timing advance
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. 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.
93 / 250
3 Call Set Up
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 is user setable. 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.
This message can not be used when the mobile station is responding to paging, i.e. in the case of a Mobile-terminated call. 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.
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.
94 / 250
3 Call Set Up
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
BTS
BSC
MSC
+ cm +
Service Reques t
Establi
sh Indic
UA
Serv ice Re quest
cm + Se
rvice Re
quest
cm + Se
rvice Re
quest
Co SCCP
nnecti
on Co
nfirm
cm Service Request UA
: Classmark : Initial layer 3 message including the mobile station identity and classmark : Un-numbered acknowledgment
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. 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 signalling link is established between the mobile station and the MSC.
SCCP Connection
95 / 250
3 Call Set Up
Authentication
Ciphering
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).
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 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. 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.
96 / 250
3 Call Set Up
MS
set up (S DCCH)
tele/bearer service called party no.
BTS
layer 3 CC
BSC
MSC
layer 3 CC
layer 3 CC
layer 3 CC
call proceeding
assign
ment re
nel ty
quest
m
TCH allocation
physic al con text re quest
chan
pe+c
physica
l conte
xt confi
TA
rm
power +
(SACC
H)
assign
H) (SDCC mand nt com e m n assig
comm ment
and
release SDCCH
SABM
(FACC
UA
H) (FACC
Set transcoder
assign
ment c o
mplete
layer 3 CC
layer 3 CC
layer 3 CC
connect acknowledgement
layer 3 CC
layer 3 CC
cipher cm DTX TA
: Encryption algorithm + ciphering key : Classmark : Discontinuous transmission flags : Timing advance
97 / 250
3 Call Set Up
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 station 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.
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.
98 / 250
3 Call Set Up
The following figure shows the channel activation process for the traffic channel.
MS BTS BSC TCH allocation
quest text re al con physic
MSC
chann
(SACC H)
el activ
ation
channe
l activa
tion ack
nowled
ge
assig
o ment c assign CH) d (SDC mman
com nment
mand
: Encryption algorithm + ciphering key : Discontinuous transmission flags : Mobile station : Timing advance : Traffic Channel
99 / 250
3 Call Set Up
The following figure shows the channel assignment process for the traffic channel.
MS release SDCCH
SABM
BTS
BSC
MSC
(FACC
H)
establi
UA (FA CCH)
Set transcoder
sh ind
ication
assign
ment c
omple
te (FA
CCH)
assign
ment c
omple
te
FACCH MS SABM UA
: Fast Associated Control Channel : Mobile station : Set Asynchronous Balanced Mode : Unnumbered Acknowledgment
100 / 250
3 Call Set Up
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
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 has the effect on the system of increasing 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.
101 / 250
3 Call Set Up
MSC
paging
reques
t
SI
(PCH)
paging
com
mand
TMSI/
IMSI +
TMSI/IM
chann
el requ
est
(RACH )
chann
el requ
ired
: International Mobile Subscriber Identity : Mobile station : Paging Channel : Random Access Channel : Temporary Mobile Subscriber Identity
Figure 34: Radio and Link Establishment for Mobile Terminated Call
102 / 250
3 Call Set Up
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).
103 / 250
3 Call Set Up
MSC
call confirmed
bearer servi
ring tone
alerting
layer 3 CC layer 3 CC
user answer
connect
layer 3 CC layer 3 CC
MS SDCCH
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.
104 / 250
3 Call Set Up
105 / 250
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 assign 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 are 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
106 / 250
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
AGCH
AGCH
AGCH
PGR6
PGR7
PGR8
PGR9
PGR10
PGR11
AGCH
AGCH
AGCH
PGR12
PGR13
PGR14
PGR15
PGR16
PGR17
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
: Access Grant Channel : Paging Group : Paging Channel : Time Division Multiple Access
107 / 250
3 Call Set Up
108 / 250
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
MSC
+ cell
paging and comm
list IE
paging
t reques
H time + CCC
slot +
paging
group
SI TMSI/IM
channe
l reque
st
channe
REF +
SABM + serv ice req uest (p aging respon
l requir
ed
RFN +
TA
se)
: 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
109 / 250
3 Call Set Up
110 / 250
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_Q_LENGTH parameter to 0 disables the 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.
111 / 250
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_Q_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 Forced Directed Retry.
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. 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.
112 / 250
3 Call Set Up
Queue Preemption
If a higher priority request arrives in the queue, Queue Preemption 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.
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. Half-rate calls use only a half time slot. If two half-rate calls are alone on separate time slots they are gathered on to a single time slot. This frees a whole time slot to serve a queued full-rate request. Reshuffling half-rate calls is enabled on a per cell basis, by setting the EN_HR_RESHUFFLING parameter to TRUE. Setting the EN_HR_RESHUFFLING parameter to FALSE disables reshuffling half-rate calls 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 There are at least two half-rate resources in the half-rate pool The parameter EN_HR_RESHUFFLING is set to TRUE. If the request is a half-rate request, it is not queued but served, because at least two half-rate resources in the half-rate pool are required to trigger the algorithm. If there is only one resource in the half-rate pool, it means there is an odd number of half-rate calls in the cell, so it is not possible to pair the last one. The queued request may be an assignment, or an incoming external emergency handover. If the algorithm has been triggered once and the queued request served (or rejected by expiry of the timer), if at least another request still remains in the queue, and if the trigger condition is still fulfilled for the top queued request (assignment or external emergency handover), then the algorithm is triggered again. If a half-rate request is queued behind a full-rate request, the half-rate request is served on a remaining half-rate resource of the half-rate pool (if any) without triggering the algorithm again. Half-rate calls are paired using an intracell handover. In the case of concentric cells, mobile stations are queued in the outer zone only. The check for two free half-rate resources applies to the outer zone only (to free a resource in the outer zone). The mobile station selected will make its handover into the outer zone (i.e. this handover does not allow handover from the outer zone to the inner zone).
113 / 250
3 Call Set Up
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 shall not be triggered.
114 / 250
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 signalling 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 & Phase 2 GSM the signalling 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 that pre-emption can be deferred while 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 is to be pre-empted. Pre-emption isapplied to 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.
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. The informaton is used for the following procedures: Paging TCH Assignment TCH Handover. Only TCH pre-emption is supported (i.e. only for circuit-switched services).
115 / 250
3 Call Set Up
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.
116 / 250
3 Call Set Up
MSC
Mobile station
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.
3.6.1 Classmark IE
The Alcatel 900/1800 BSS supports classmark 1, classmark 2 and classmark 3 IEs. The 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 the classmark 1 IE, plus support of A5/2 encryption.
117 / 250
3 Call Set Up
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. The 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. The RF Power Level indicates the mobile station power capability. For Alcatel 900: Class 1 = 20W Class 2 = 8W Class 3 = 5W Class 4 = 2W Class 5 = 0.8W. For Alcatel 1800: Class 1 = 1W Class 2 = 0.25W. 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.
Revision Level
RF Power Level
Support of A5/1 Encryption Support of A5/2 Encryption Impact on BSS and MSC
This field indicates 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. This field indicates 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. 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 the classmark 1 Information Element 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 classmark 1 Information Element was received. Therefore, a classmark updating procedure is required.
118 / 250
3 Call Set Up
119 / 250
3 Call Set Up
BTS
BSC
MSC
switch to SDCCH
SABM + rn +
fn + cm
establish
indication
SCCP co
nnection
H/SA (FACC
CCH)
SCCP
connect
ion
pow
+s er + TA
ys info
5&6
ark classm
enauiry
confirm
classmark change
classmark 2IE
classmark update
classmark 2IE
location update
(SDCCH)
: Classmark : Fast Associated Control Channel : Information Element : Mobile station : Random Access Channel : Set Asynchronous Balanced Mode : Slow Associated Control Channel : Signal Connection Control Part : Stand-alone Dedicated Control Channel : Timing advance
120 / 250
3 Call Set Up
The mobile station initiates a location update procedure by sending a channel_request message on the RACH. The BSS performs the immediate assign procedure, as described in Mobile Originated Call (Section 3.2). 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. 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. When the BSC receives an SCCP_connection_confirm message, it sends a classmark_enquiry message to the mobile station. 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. 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. When ciphering is set, the MSC can accept the location update.
121 / 250
3 Call Set Up
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.
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.
BSC
MSC
VLR
info request
IMSI + Ki
service request + TMSI + old LAI new TMSI BTS Mobile Station BSC
MSC
VLR
: International Mobile Subscriber Identity : Individual Subscriber Authentication Key : Location Area Identity : Temporary Mobile Subscriber Identity : Visitor Location Register
Figure 40: Location Update with Mobile Station Sending Location Area Identity of Previous VLR
122 / 250
3 Call Set Up
Authentication Procedure
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. The mobile station responds using the RAND and the value authentication Key assigned to its TMSI or IMSI. For mobile station originated calls, the mobile station uses: The TMSI, if available The IMSI, if no TMSI is assigned. For mobile station 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. 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.
123 / 250
3 Call Set Up
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. 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.
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
124 / 250
3 Call Set Up
BSS 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.
125 / 250
3 Call Set Up
Ciphering is initiated by the MSC by sending a cipher_mode command to the BSC. This command contains the permitted_algorithms message. 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. 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. 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. 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. 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 MSC
cipheri
encryp tion co d mman
ng mo
de com
mand
ted a permit
lgorith
ms + K
cipheri
ng mo
man de com
H)
(SDCC
algorithm or no encryption
cipheri
ng mo
de com
plete
cipher mode
comple te
MS
: Mobile station
126 / 250
3 Call Set Up
SDCCH
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.
127 / 250
3 Call Set Up
128 / 250
3 Call Set Up
BTS A
Channel activation TFO enabled
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
TRAU frames
TFO_ACK
TFO_ACK
Codecs match
TFO_ON
TFO frames
TFO_ON
5
TFO REPORT (TFO STATUS= ON) TFO REPORT (TFO STATUS= ON)
: Pulse Code Modulation : Transcoder : Tandem Free Operation : Transcoder Rate Adaptation Unit
129 / 250
3 Call Set Up
As the same codec is used on both sides, there is no TFO negotiation needed between the TRAU. 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 intra-cell handover is performed to change the speech codec locally used, and TFO exchange of speech stream begins. A logical parameter, configurable at OMC-R level, 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 intra-cell handover is not possible, TFO mode is given up, and the system reverts to normal mode.
130 / 250
3 Call Set Up
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 to be 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 parts 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.
For a better traffic load regulation Alcatel has defined the function "Force TFO half-rate when loaded" to give control to the operator of load regulation precedence over TFO. 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 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 part supports half-rate, then the distant part will do an intra-cell handover to use half-rate, and TFO will go on with half-rate. If the distant part 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.
131 / 250
3 Call Set Up
132 / 250
4 Call Handling
4 Call Handling
This chapter provides an overview of Call Handling and describes the supervision of a call in progress. The following specific areas are described: Overview In-call modification Frequency hopping Discontinuous Transmission Radio Power Control Handover procedures Overload conditions Call re-establishment by the mobile station.
133 / 250
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.
134 / 250
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 (Chapter 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 signalling 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.
For a mobile station to mobile station call, both mobile stations must negotiate a dual service during call establishment. 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 to 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. 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). The BSS handles the normal assignment procedure as if assigning a traffic channel during call set up (described in Call Set Up (Chapter 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. 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
135 / 250
4 Call Handling
informs the mobile station that the procedure is successfully completed, and the mobile station can start transmitting in the new mode.
For non-transparent fax transmission, the data rate change is handled within the BSS, using in-band signalling. 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. Transparent fax frames are passed transparently through the BSS. Therefore, in-band signalling cannot be used within the BSS. The Group 3 fax equipment informs the MSC of a data rate change using in-band signalling. 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.
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.
136 / 250
4 Call Handling
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 re-use. Interference Diversity minimizes the time during which a given user on a given mobile station will experience the effects of such interference.
137 / 250
4 Call Handling
f1
f2
f3
f1
f2
f3
f1
f2
f3
f1
f2
f3
: Frequency : Frequency Hopping System : Traffic Channel : Mobile Allocation Index Offset : Hopping Sequence Number : Time slot
138 / 250
4 Call Handling
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.
139 / 250
4 Call Handling
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.
Discontinuous Transmission
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 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. 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.
140 / 250
4 Call Handling
1. This bans Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX.
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).
141 / 250
4 Call Handling
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.
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.
142 / 250
4 Call Handling
DTX
: Discontinuous Transmission
143 / 250
4 Call Handling
144 / 250
4 Call Handling
Reporting Period
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.
145 / 250
4 Call Handling
start counter
conn ectio n fail ure in dicati
lue
on
caus
e va
clear
n han el re e leas
requ
est
RF
MS TX
146 / 250
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 too high Quality bad Handover desired High Signal Level
RXLEV
Figure 46: Power Output Balancing Based on Received Quality and Signal Levels
147 / 250
4 Call Handling
30 dBm (1 W)
10 dBm
39 dBm (8 W) 39 dBm (8 W)
13 dBm 13 dBm
30 dBm (1 W)
4 dBm
33 dBm (2 W)
0 dBm
148 / 250
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 Internal External. 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.
Internal
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.3). External Handovers take place between cells controlled by different BSCs. These can be under control of the same MSC or of different MSCs. See Target Cell Evaluation (Section 4.6.3) for more details about these handover cases.
External
149 / 250
4 Call Handling
Directed Retry
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 handover the call to a traffic channel of a neighbor cell controlled by the same BSC. An External Directed Retry attempts to handover the queued call to a traffic channel of a neighbor cell which is controlled by a different BSC.
Secured Incoming
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. 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 overlap totally the microcells). 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 hand over. The signalling 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. Therefore, 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.
Fast Traffic
UMTS to GSM
150 / 250
4 Call Handling
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. The BSC calculates the need for a handover using an algorithm, the use of which is described in Handover Detection (Section 4.6.2). The BSC uses the uplink idle channel measurements made by the BTS to make a table of traffic channel channels, classified by interference levels. This table is used to select a channel for assignment. 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. 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.
Need for Handover Traffic Channel Quality Tables Target Cell List
Handover Decision
151 / 250
4 Call Handling
152 / 250
4 Call Handling
High Quality
123456 123456789 123456 123456789 123456 123456789 123456789 Level 123456 Power Desired Power 123456789 Intercell 123456 Increase Quality Decrease to Handover 123456 to and Level 123456789 Conserve Improve Balance Resources 123456 123456789 Level (no action 123456789 and Minimize 123456 needed) 123456789 Interference 123456 123456 123456789 123456 123456789 123456789 123456 12345678901234 123456 12345678901234 Power Increase to 123456 12345678901234 improve quality 123456 12345678901234 123456 12345678901234
Quality Intercell Handover Quality Intracell Handover High Level Low Level
Low Quality
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.
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.
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.
153 / 250
4 Call Handling
154 / 250
4 Call Handling
155 / 250
4 Call Handling
BSS 1
1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890
BSS 2
156 / 250
4 Call Handling
Low load Max speed discrimination in force Macrocell with little traffic
Minimum Dwell Time Low minimum dwell time High minimum dwell time
157 / 250
4 Call Handling
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.
In certain networks, two different frequency bands can exist, for example, one frequency band uses the GSM frequencies, the other frequency band uses the DCS 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.
158 / 250
4 Call Handling
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 A1353RA 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 handover a call depend on which cell has been chosen as the target cell.
Internal: Intracell
If the target cell and the 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.
159 / 250
4 Call Handling
If the target cell is not the same as the serving cell but is 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 is controlled by the MSC. If the target cell and the 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. If the target cell and the serving cell are 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.
160 / 250
4 Call Handling
MS
Target BTS
measu remen t report s (S ACCH )
Serving BTS
BSC
MSC
measu
remen
t result
physic
al con
confirm
text
TA + p
ower
chann
el acti
vation
TA + c
iph
TX + er + D
chann
power
+ chan
nel
el acti
vation
ack
HO
A+ sc + T cell de ower + p + f re
hando
ver co
mman
hando
SABM
ver de
tection
establis
h indic
ation
hando
ver co
mplete
hando
ver pe
rforme
: Discontinuous Transmission : Handover : Mobile station : Set Asynchronous Balanced Mode : Slow Associated Control Channel : Timing advance
Measurement Reporting
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.
161 / 250
4 Call Handling
Handover Detection
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 cell list. For this example, the first cell on the list (target cell) is a cell controlled by this BSC and the BTSs of both serving and target cell are collocated. Once this cell is chosen, the BSC initiates the synchronous internal handover procedure. The BSC sends a physical_context_request message to the serving BTS, requesting current timing advance and power level information. This information is passed to the target BTS. The serving BTS responds with a physical_context_confirm message.
Channel Activation
When the BSC receives the physical context information, it sends a channel_activation message to the target BTS, indicating: The channel to be used The mobile station timing advance to be applied The encryption algorithm and ciphering key A Discontinuous Transmission indicator for uplink (not used) and downlink (see Speech Transmission (Section 4.4.1)) The mobile station power to be used The BTS power to be used. The target BTS sets its resources to support the channel. It then uses a channel_activation_acknowledgment message to reply to the BSC. This lets the BSC know that the target BTS is ready. The target BTS also starts transmission of SACCH/FACCH frames so that when the mobile station accesses this BTS, it receives sys_info 5 and sys_info 6 messages. The mobile station also receives the timing advance and power control updates.
Handover Command
The BSC sends the handover_command message transparently through the BTS to the mobile station. This message contains: The new channel and its associated control channel The target cell description A power level indication for the mobile station initial access to the target cell A handover reference The timing advance to be used in the target cell Any cipher mode information (phase 2 mobile stations can change cipher mode during a handover procedure).
162 / 250
4 Call Handling
The Handover
The mobile station releases its connection with the serving BTS and sends four consecutive access bursts to the target BTS on the uplink SACCH. These bursts include the handover reference and use a timing advance of 0. The BTS calculates the timing advance (it may have changed since the physical context procedure). It sends a handover_detection message to the BSC indicating the timing advance measured for the access burst. If the mobile station timing advance needs to be updated, the BSC sends this information in the physical_information message on the FACCH channel associated with the traffic channel. The mobile station then sets ciphering (as required). It sends its first frame, SABM, using the timing advance information either as sent in the handover_command message, or as updated in the FACCH frames. When the BTS receives the frame from the mobile station, it sends an acknowledgment frame to the mobile station and an establish_indication message to the BSC. This informs the BSC that the radio link has been established. The BSC starts BTS and mobile station power control. On receipt of the acknowledgment frame, the mobile station sends a handover_complete message to the BSC. The mobile station can now start transmitting on the new channel. The BSC informs the MSC of the handover in a handover_performed message and initiates the release of the old channel.
163 / 250
4 Call Handling
Serving BTS
Target BSC
Serving BSC
MSC
(SACCH)
HO detect HO alarm
handover required
handover requ
channel activati
SACCH/FACCH
est
on
channel activation
ack
hanover request
+ handover com
ack
mand
handover command
d handover comman
ch+cell+HOref+cipher
handover detect
handover detect
HO ref + TA
handover detect
ack
establish indication
(FACCH)
handover complete
handover performed
clear comman
: Discontinuous Transmission : Fast Associated Control Channel : Handover : Mobile station : Set Asynchronous Balanced Mode : Slow Associated Control Channel : Timing advance
Measurement Reporting
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.
164 / 250
4 Call Handling
Handover Detection
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.
Channel Activation
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.
Handover Command
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.
The Handover
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.
165 / 250
4 Call Handling
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.
166 / 250
4 Call Handling
Note:
The telecommunications processors of the MSC can also become overloaded. However, MSC overload control is not the domain of the BSS.
The BTS monitors the load on the FU or TRE by measuring the free time on the FU or TREs Signalling 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.
167 / 250
4 Call Handling
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 signalling 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 defence actions. 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 signalling 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 MSC are overloaded.
168 / 250
4 Call Handling
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:
AUT_BAR enables/disables the automatic banning of cells after all access
classes have been barred. This forces the mobile station to camp on another cell.
EC_BAR 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.
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.
169 / 250
4 Call Handling
170 / 250
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. It specifically describes Call Release procedures in normal service plus the following special cases: Overview Following Reset BSC initiated BTS initiated Mobile station initiated 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.
171 / 250
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 signalling 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.
172 / 250
5 Call Release
BSS
nect (la yer 3
MSC
CC)
relea
uest se req
(layer
3 CC)
release
comple
te
(layer 3
CC)
MS
: Mobile station
173 / 250
5 Call Release
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. 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 omma nd
MSC
chann
el rele
ase
a activ te S AC CH
de
disc
(to re lease LAPD m)
UA
on
SCCP release comple te
physic
te al con
est xt requ
Timer
RF cha
nnel re
lease
RF ch an
nel rele
Timer
ase ac k
: Link Access Protocol on the Dm Channel : Link Access Protocol on the Dm Channel : Mandatory Information Element : Mobile station : Slow Associated Control Channel : Signal Connection Control Part : Transcoder : Unnumbered Acknowledgment
174 / 250
5 Call Release
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 signalling which controls the connection. 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. 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. This is shown in the following figure.
MS BTS BSC
clear c
MIE in
MSC
omma nd
e valu e
cludin
g caus
chann
el rele
ase
CH AC te S
dea
ctiv
: Mandatory Information Element : Mobile station : Slow Associated Control Channel : Signal Connection Control Part
175 / 250
5 Call Release
The normal Call Release procedure towards the mobile station/BTS releases: The radio resources associated with the call The Radio Frequency 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. Thechannel_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. 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 BSC
clear c
MIE in
MSC
omma nd
e valu e
cludin
g caus
chann
el rele
ase
tiva ACC te S H
c dea
relea
se in
dicati
on
SCCP
release
comple
te
: Link Access Protocol on the Dm Channel : Mandatory Information Element : Mobile station : Slow Associated Control Channel : Signal Connection Control Part : Transcoder : Unnumbered Acknowledgment
176 / 250
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). 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. 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
UA
relea
se in
dicati
on
quest
physic
al con
text re
physic
al con
Timer
text co nfirm
RF ch
annel
releas
RF ch
annel
Timer
releas e ack
MS UA
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 chapter 3 for more information).
177 / 250
5 Call Release
Target BTS
handover complet e
Serving BTS
Target BSC
Serving BSC
MSC
handover perform
ed
clear
comm
lu
and
se va lue
inc MIE
cau ding
chann
el rele
ase
c dea
tiva
te S
AC
CH
: Fast Associated Control Channel : Mandatory Information Element : Mobile station : Slow Associated Control Channel
178 / 250
5 Call Release
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. The figure below shows the Call Release process after a reset is initiated.
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.
179 / 250
5 Call Release
MS
BTS
BSC
reset
MSC
block
SCCP releas e
circuits blocked
te
disc
to relea se LAP Dm
SCCP
release
comple
channe
e l releas release
SCCP re lease
indicatio
n
rele CCP ase c omp lete
to re
disc
leas e LA PDm
phys
ntex ical co
t re
quest
S
physical context
confirm
RF cha
nnel re
lease
ack
timer
reset a ck
LAPDm MS SCCP
: Link Access Protocol on the Dm Channel : Mobile station : Signal Connection Control Part
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.
180 / 250
5 Call Release
interface, the release towards the MSC is triggered by the clear message from the MSC to the BSC.
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 MSC
clea
MIE
r co
mm
and
MIE MS
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.
181 / 250
5 Call Release
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.
182 / 250
5 Call Release
LAPD Failure
When the BTS detects an 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 A910). 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. The BSC reinitializes 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.
183 / 250
5 Call Release
MS
BTS
BSC
MSC
timer
disc
timer
disc
UA
timer
UA
UA
clear co
d mman
: Frame Unit : Link Access Protocol on the D Channel : Mandatory Information Element : Mobile station : Slow Associated Control Channel : Transmitter/Receiver Equipment : Unnumbered Acknowledgment
O&M Intervention
The BTS initiates a Call Release if its O&M entity requests a restart of an Frame Unit (TRE for a BTS A9100 or BTS A910). 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 reestablish 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.
184 / 250
5 Call Release
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.
BTS
BSC
MSC
start counter
conn ectio n fail ure in dicati
lue
on
caus
e va
clear
e ann as l rele e
requ
est
RF
ch
MIE
MIE MS SACCH
Figure 63: Call Release due to Mobile Station initiated Radio Link Failure
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)).
185 / 250
5 Call Release
Alarm
e leas el re ann h c RF
clea
MIE inc
r co
mm
and
se v alue
g ludin
cau
MIE MS TC
186 / 250
187 / 250
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. The TSS 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
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 signalling on full-rate and half-rate channels respectively.
188 / 250
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.
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. 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 signalling if they are full-rate speech. The channels on the Abis and Ater interfaces are 64 kbit/s. The speech blocks 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 signalling. 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 mated 8 kbit/s Abis channels are independently switched by the BSC onto two 16 kbit/s Ater channels.
Digital Speech
Ater Interface
Atermux Interface
Ater Interface
A Interface
BSC
SM
SM
TC
MSC
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.
189 / 250
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 processes occur: The mobile station makes a call requiring speech, in which it announces its codec preferences to the MSC in the setup message. The MSC passes appropriate assignment_request and handover_request messages to the BSC. 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. The BSC activates the selected channel in the BTS, giving the indication of codec type. The BTS configures itself to handle the correct channel coding, and starts sending TRAU frames to the TRAU, in order to configure the TRAU. 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. Once the mobile station is attached, the BSC reports the selected codec type to the MSC. In the case of subsequent handover if the BSC has had to change the codec the BSC informs the MSC of the change. For further information concerning enhanced full-rate, refer to the A1353RA Configuration Handbook.
190 / 250
6.2.2 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: G2 BSC G2 Transcoder One of the following BTSs: G1 BTS equipped with Dual Rate Frame Unit EVOLIUM BTS.
191 / 250
192 / 250
Normal Assignment
AMR is controlled on a per call basis by the MSC. In the assignment request message, the MSC gives the Channel type IE, which indicates the following: 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 following octets indicate that AMR is allowed in half-rate or full-rate. 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). 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. Once the channel is activated within the BTS, the BSC sends all AMR relevant parameters to the mobile station in the assignment command message. 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. Once the BTS detects that downlink CMI/CMR is synchronized between the TRAU frames and the radio interface, it starts codec mode adaptation.
O&M Management
This section summarizes the main O&M configuration parameters that can be changed by the operator from the OMC-R:
AMR_SUBSET_FR Bitmap of 8 bits defining the codec subset for AMR full-rate
load. It can take the value 0.0 to 7.0 (step = 0.1) on a per cell basis.
RXQUAL_CA_HIGH Threshold for channel mode adaptation under high load. It
can take the value from 0.0 to 7.0 (step = 0.1) on a per cell basis.
AMR_THR_3, AMR_THR_2, AMR_THR_1 Definition of thresholds on a per BSS
basis.
193 / 250
AMR_HYST_3, AMR_HYST_2, AMR_HYST_1. Definition of thresholds and hysteresis, on a per BSS basis.
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 full-rate to 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. 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 adaption, 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 half-rate to 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.
194 / 250
Transparent
The 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.
Non-Transparent
The non-transparent data mode is similar, 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. Refer to Transparent Mode (Section 6.3.1) for more information about the transparent mode and to Non-Transparent Mode (Section 6.3.2) for more information about the non-transparent mode. The following figure illustrates data transmission across the BSS.
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
PSTN
13 kbit/s
CIM
: Analog : Analog/Digital : Base Station Interface Equipment
13 kbit/s
: Channel Encoded, Interleaved, and Modulated : Public Switched Telephone Network : Submultiplexer : Transcoder
195 / 250
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.
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%
Table 20: Circuit-Switched Data Rate Conversions Across the Air Interface
196 / 250
Error Handling
The 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). 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.
Rate Adaptation
197 / 250
HMI
198 / 250
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.
199 / 250
200 / 250
Inter-PLMN 2G to 2G cell reselections 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 reselections 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 reselections and handovers 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 part can be shared. The transcoder part can be shared. The outgoing inter PLMN handovers feature is a prerequisite for multi PLMN feature.
201 / 250
202 / 250
7 Cell Environments
7 Cell Environments
This chapter describes the cell environments available in the Alcatel 900/1800 BSS. The following cell environments are described: Overview Single Cell Concentric Cell Sectored Site Extended Cell Umbrella Cell Mini Cell Microcell. Indoor cell
203 / 250
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 DCS 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 DCS 1800 bands, or both in case of a multi-band cell.
In the 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 co-located antennae, provide options covering traffic density and ranges up to 70 km. In the 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. The figure below 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.
Urban Coverage
204 / 250
7 Cell Environments
Sectored Site Umbrella Cell Microcell Microcell Microcell Inner Cell Outer Limit Umbrella & Concentric Cell Microcell Microcell Microcell
Extended Cell
Overlap Zone
205 / 250
7 Cell Environments
206 / 250
7 Cell Environments
Cell 1
Cell 3
Sector 3
Antenna
207 / 250
7 Cell Environments
35 km max
208 / 250
7 Cell Environments
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.
209 / 250
7 Cell Environments
Pedestrian area
210 / 250
7 Cell Environments
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.2 Micro to Macro Handover High Threshold Handover Low Threshold Handover
This type of 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. This type of handover occurs when 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.
Rescue Handover
Note:
211 / 250
7 Cell Environments
d B m
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 remain 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 whereby the mobile station reports a microcell signal level above 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.
212 / 250
7 Cell Environments
Upper layer
Lower layer
Indoor layer
Figure 74: Indoor cell example network hierarchy with three layers and two bands
213 / 250
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.
214 / 250
7 Cell Environments
Note:
This feature is applies only 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 3 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 main sector. The other physical sector is the secondary sector.
215 / 250
7 Cell Environments
216 / 250
217 / 250
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 Fault Management Performance Management. These categories are described later.
218 / 250
BSC Terminal User Guide Transmission Terminal User Guide BTS Terminal User Guide EVOLIUM A925 Compact TC Terminal User Guide EVOLIUM A935 MFS IMT User Guide
OML Auto-detection
An OML auto-detection feature has been introduced in order to take full advantage of the transmission configuration via OML feature (it 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 A simplification of the BTS installations (in the idea of Plug&Play BTS). See OML Auto-detection (Section 8.4.5) for more information.
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.
219 / 250
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.
Configuration Management
Configuration Management is the process of viewing and controlling 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.
Fault Management
Fault Management allows the operator to supervise and to repair the network when anomalies occur. It does this through a sequence of steps from detection to reporting and recovery. These are carried out by all the BSS/MFS subsystems, and are reported to the operator at the OMC-R. Performance Management allows the operator 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 usage in the BSS.
Performance Management
220 / 250
221 / 250
HMI Server
X.25 Network
OMCR Host n
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.
222 / 250
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 OMCs, 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
223 / 250
OSI CPRA 2
: Common Management Information Service Element : Common Processor Type A : File Transfer Access and Management : High Speed Interface : Open System Interconnection
224 / 250
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
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.
225 / 250
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. The license for the documentation collection and Verity search engine is installed on one OMC-R. All other OMC-R 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.
226 / 250
MFS
Reading and modifying parameters Control station and GPU configuration Framer configuration for Gb Interface messages GPU switch configuration for circuit-switched connections.
227 / 250
228 / 250
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.
Consistency Checks
When a new Configuration Data Message is received from the BSC, the BTS A9100 and the BTS A910 performs a consistency check of its capabilities against the Configuration Data Message. It also does this at module initialization due to maintenance operator command or to a Hardware Extension operation. The BTS A9100 and the BTS A910 also checks 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/A910 Functional Description EVOLIUM BTS A9100 Hardware Description EVOLIUM BTS A910 Hardware Description BTS Terminal User Guide
229 / 250
230 / 250
8.4.6 NE Provisioning
Network element provisioning allows equipment that is not yet in commercial use to be distinguished from equipment that is under maintenance. This is mot important for network monitoring. The feature introduces the status "commercial use" that can be associated to the BTS. This status is changeable online from the OMC-R. It is also available at the radio configuration export/import interface of the OMC-R for coordination with the operators information systems. For the BTS marked as "not in commercial use", potential alarms are raised with only a "warning" severity and the performance measurement results are not taken into account. The BTS marked as "not in commercial use" are not reported in the topology files sent to the A985-NPA and A956-RNO. They can be also 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, PM cell measurements were running on the BTS, and this lead to very poor PM results as the BTS was not in commercial service. An attribute (commercialUse = On or Off) is associated to each BTS. The attribute can be changed from 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 severity maximum 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, as usual. 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 the BTS that are marked out of commercial use (except for the PM counters that are relative to RSL/OML traffic which are not filtered).
231 / 250
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/A910). Through the TSC, the BSC also performs the following functions: Status monitoring of the Transcoder, SM and BIE modules Local access provision to configuration of the Transcoder, SM and BIE modules via an RS-232 connection to the BSC terminal. Giving access to the fault localizing features of the TSC (for example, the ability to set up loop-back tests)
232 / 250
BTS
Testing of 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. Access provision for the 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 to access the fault information Generates the ending alarm for pending alarms Manages the communications with the IMT.
233 / 250
Filtering
Alarms are filtered to minimize the number of fault alarms reported and displayed to the operator. Alarms are displayed in order of severity. Refer also to the Alarm Handling section of the Operations & Maintenance Principles document.
Persistency
A fault is signalled only if there is no recovery after the timer expiration. For example, in the case of an LAPD failure of an RSL link, an alarm is sent only if the LAPD link has not recovered before the persistency timer has expired. 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. 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.
Alarm Surveillance
Alarms-in-Force List
234 / 250
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 change-over of the SS7 The blocking of circuits.
The TSC supervises its trunks between the Transcoder, BTS, and MSC. Failure of the Abis interface is signalled 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.
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.
235 / 250
CPR Informed
Persistency
Correlation
CPR RSL
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 RTS 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 signalling the loss of the cell. When an SBL is put in to the FLT state, it is shown in the Alarms-In-Force List.
236 / 250
When the BSC detects a DTC failure, the BSC puts the DTC SBL in the MSD-Auto state, then into the FLT state. Through the TS0 signalling, the MSC is informed that the trunk is no longer operational and prevents all transactions requiring the A channel (includes new mobile station-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. The A channel is allocated only by the MSC. 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.
237 / 250
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.
238 / 250
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 messsages are described in the BTS Alarm Dictionary and the BSC/TC Alarm Dictionary. 4. The message is sent to the CPR-A, 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 re-transmits 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.
239 / 250
240 / 250
Note:
In the BTS A9100 or the BTS A910, 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 A910 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.
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 A910) 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. Below is a step-by-step scenario of Carrier Unit recovery.
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 and all calls on the Carrier Unit are immediately released. The RSL is blocked. All calls on the Carrier Unit are immediately released. 3. The BSC sends an alarm to the OMC-R, signalling the loss of BCCH. 4. The BSC attempts a recovery. The recovery command is BTS-CONF-DATA(2).
241 / 250
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
3 4
BTS_TEL=FIT
Alarm
ss (cell, lo
of BCC
H beg
in)
BTS_CO
NF_DAT
A (2)
BTS_TEL=FIT
6 8
ss of B CCH e nd)
SYS_INF
O (1..6)
ell, lo larm (c
9
begin)
(ce Alarm
ll, loss
of TCH
BTS_TEL=FIT
BCCH CU TCH
Note:
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.
242 / 250
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 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/A910 Functional Description EVOLIUM BTS A9100 Hardware Description EVOLIUM BTS A910 Hardware Description
Note:
For performance reasons, each alerter type has a maximum limit of 16 alarms. For further information concerning BSC Alerters, refer to the BSC Alerters section of the Operations & Maintenance Principles document.
243 / 250
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 the Trace Management section of the Operations & Maintenance Principles document.
244 / 250
245 / 250
246 / 250
247 / 250
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 as follows: Configuration Management Audits in the Configuration Management Audits/Resynchronization section of the Operations & Maintenance Principles document. Fault Management Audits in the Fault Management Audits section of the Operations & Maintenance Principles document.. Using the IMT, it is possible to perform a radio re-initialization, or a radio resynchronization of the MFS.
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.
Alarm Audit
State Audit
248 / 250
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. Re-synchronize 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.
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.
249 / 250
250 / 250