Академический Документы
Профессиональный Документы
Культура Документы
2 / 306
Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Evolium Radio Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Extended GSM Band (E-GSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 GSM 850 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Frequency Band Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 BSS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 BSS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Base Station Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Base Transceiver Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Transcoder And Transmission Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 The Multi-BSS Fast Packet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Extended GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 E-GSM Mobile Station Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 E-GSM Management After Initial Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 E-GSM Determination at Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.4 TCH Allocation for E-GSM and P-GSM Mobile Stations . . . . . . . . . . . . . . . . . . . . 1.5 External Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Network Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Mobile Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Phase 2 Mobile Support in a Phase 1 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Operations and Maintenance Center-Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Telecommunications Management Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Q3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 BSS Telecommunications Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Call Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 Mobility Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 Radio Resource Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.4 The A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.5 The Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.6 The Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7 HSL Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.8 Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.9 The Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.10 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.11 Dynamic SDCCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 2G and 3G Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.1 2G and 3G Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.2 2G to 3G Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.3 2G to 3G Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16 17 17 17 18 18 18 19 20 20 21 21 22 23 26 27 30 30 31 31 32 33 34 35 39 39 40 40 41 42 42 42 43 44 45 45 46 46 47 52 56 57 57 58 59 61 62 62 64 67 67
3 / 306
Contents
2.2.2 Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 2.2.3 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.3 GPRS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.3.1 The Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.3.2 The BSCGP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.3.3 The GCH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.3.4 Specific LCS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.4 GPRS Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.4.1 MAC and RLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.4.2 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.4.3 Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.4.4 Enhanced Packet Cell Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.4.5 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 2.4.6 Radio Power Control and Radio Link Measurement . . . . . . . . . . . . . . . . . . . . . . . . 80 2.5 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.5.1 Time Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.5.2 Autonomous Packet Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.5.3 Packet Flow Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 2.5.4 Dynamic Abis Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 2.5.5 Enhanced Transmission Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.5.6 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.5.7 PCM Link Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2.5.8 TBF Resource Re-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2.6 Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 2.6.1 Smooth PDCH Traffic Adaption to Cell Load Variation . . . . . . . . . . . . . . . . . . . . . . 91 2.6.2 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 2.6.3 M-EGCH Statistical Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 2.6.4 GPRS Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 2.7 Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.7.1 GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.7.2 Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 2.7.3 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 2.7.4 Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 2.7.5 GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 2.7.6 GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 2.7.7 GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 2.8 Location Services (LCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 2.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 2.8.2 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 2.8.3 LCS Positioning Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 2.8.4 LCS Scenario in Circuit-Switched Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 2.8.5 Physical Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 2.8.6 SMLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 2.8.7 BSS and Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 2.8.8 LCS O&M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 2.9 High Speed Data Service (HSDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 2.9.1 HSDS Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 2.9.2 GPRS CS3/CS4 and EGPRS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 2.9.3 Transmission Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 2.9.4 Cell/GPU Mapping Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.1.1 Call Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.1.2 Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 3.2 Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 3.2.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 3.2.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4 / 306
Contents
3.3
3.2.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Off Air Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 IMSI Attach-Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Paging Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 In-queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Classmark IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Classmark Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Location Updating with Classmark Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 IMSI/TMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Authentication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Mobile Station Ciphering Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.2 BSS Ciphering Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.3 Ciphering Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.4 Ciphering Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Tandem Free Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.1 TFO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.2 TFO Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.3 TFO Optimization and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 In-Call Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 In-Call Modification Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Circuit-Switched Group 3 Fax Data Rate Change . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Synthesized Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Speech Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Continuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Voice Activity Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 BSS Discontinuous Transmission Towards Mobile Station . . . . . . . . . . . . . . . . . 4.4.5 Mobile Station Discontinuous Transmission Towards BSS . . . . . . . . . . . . . . . . . 4.5 Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 BTS Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Mobile Station Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Power Control Decision and Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5 Change Power Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Principal Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Radio Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Handover Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 Target Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5 Synchronous and Asynchronous Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
140 146 147 147 148 149 149 150 152 155 155 155 156 158 159 160 162 163 165 165 166 167 167 168 168 168 171 172 173 174 175 176 177 178 179 179 180 181 182 183 183 183 184 184 186 188 188 188 189 190 192 193 194 196 197 203 205
5 / 306
Contents
4.7
4.6.6 Circuit-Switched Telecom Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Preserve Call Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Normal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Abnormal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling User Traffic Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Analog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Interleaving and Forward Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Speech Data Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Digital Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.5 Digital 64 kbit/s A-law Encoded Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.6 Enhanced Full-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.7 Half-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.8 Adaptive Multiple Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.9 Channel Mode Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.10 VGCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Circuit-Switched Data Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Non-Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 SMS-CB Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Phase 2+ Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Support of Localized Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 PLMN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 Rural and Coastal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Urban Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Concentric Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Sectored Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Standard Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Enlarged Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 PS in Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Umbrella Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Mini Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Microcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 Indoor Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Cell Shared by Two BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
209 211 211 212 214 215 216 217 217 223 224 224 226 228 228 231 232 233 233 234 235 236 236 237 237 237 238 238 239 240 241 244 245 246 246 248 249 249 250 251 252 253 254 256 256 256 257 258 259 259 260 261 261 262 265 266
6 / 306
Contents
7.7 Unbalancing TRX Output Power per BTS sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Subsystem O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 System O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 O&M Control - Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 LMTs and the IMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 OML Auto-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.4 Security Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 O&M Control - The OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Multiple Human-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 ACO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Connection From BSC to OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.4 Electronic Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.2 Logical Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.3 Default Parameter Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.4 Software Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.5 Auto-Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.6 OML Auto-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.7 Network Element Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.1 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.3 Radio Measurements Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.4 Results Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.1 Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.2 Audit Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8 Remote Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
267 269 270 271 272 273 273 274 274 274 275 275 276 277 278 279 280 280 281 281 281 283 284 285 287 287 289 293 295 295 296 299 299 300 300 301 301 303 304 304 305 306
7 / 306
Figures
Figures
Figure 1: BSS in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figure 2: Antenna Diversity on G1 and G2 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 3: Antenna Diversity on the BTS A9100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 4: Transmission Components in the BSS with A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 5: Cell Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 6: Logical Position of External Components Associated with BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 7: Location Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 8: TMN System Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 9: General Telecommunication Layers in GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figure 10: BSS Application, Transmission Layers and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 11: Time Slot 4 of a TDMA Frame Supporting Access Grant Channels . . . . . . . . . . . . . . . . . . . . . . . . . 48 Figure 12: Model LLC Packet Data Unit used in GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figure 13: The Alcatel GPRS Solution in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 14: GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Figure 15: Mobile Station-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . 95 Figure 16: GGSN-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Figure 17: Mobile-Originated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Figure 18: Mobile-Terminated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Figure 19: Mobile-Originating Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Figure 20: Network-Originating Packet Data Protocol Context De-activation Processes . . . . . . . . . . . . . . . 107 Figure 21: GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Figure 22: GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Figure 23: Mobile Station-Originating GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Figure 24: Network-Originating GPRS Detach Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Figure 25: Generic LCS Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Figure 26: Radio and Link Establishment for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Figure 27: SDCCH Channel Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Figure 28: Immediate Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Figure 29: Connection for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Figure 30: Normal Assignment for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Figure 31: Channel Activation Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Figure 32: Channel Assignment Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Figure 33: Call Connection for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Figure 34: Radio and Link Establishment for Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Figure 35: Normal Assignment for Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Figure 36: CCCH with Three Blocks Reserved for AGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Figure 37: Four TDMA Frame Cycles Providing 24 Paging Sub-channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Figure 38: Paging Message Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Figure 39: Location Update with Classmark Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8 / 306
Figures
Figure 40: Location Update with Mobile Station Sending Location Area Identity of Previous VLR . . . . . . . 165 Figure 41: Ciphering Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Figure 42: Example of TFO Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Figure 43: Frequency Hopping within an FHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Figure 44: Different Forms of Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Figure 45: Power Control Flow of Measurement and Decision Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Figure 46: Power Output Balancing Based on Received Quality and Signal Levels . . . . . . . . . . . . . . . . . . . . 191 Figure 47: Quality and Level Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Figure 48: Better Zone Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Figure 49: Better Cell Handover (Power Budget) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Figure 50: Distance Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Figure 51: Umbrella Cell Load in Mobile Velocity Dependent Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Figure 52: Asynchronous External Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Figure 53: Mobile Station Disconnecting a Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Figure 54: Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Figure 55: Initiation of Normal Release by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Figure 56: BSC/BTS/Mobile Station Interactions in Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Figure 57: Normal Release Final Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Figure 58: Call Release Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Figure 59: Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Figure 60: BSC-initiated Call Release toward the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Figure 61: BTS-initiated Call Release following LAPD Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Figure 62: Call Release due to Mobile Station-Initiated Radio Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Figure 63: Call Release due to Communication Failure detected by Transcoder . . . . . . . . . . . . . . . . . . . . . . 232 Figure 64: Encoded Speech Transmission Across the BSS with A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . 236 Figure 65: Multiplexed Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Figure 66: Data Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Figure 67: Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Figure 68: Example: Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Figure 69: Sectored Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Figure 70: Example of Extended Cell Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Figure 71: Umbrella Cell with Mini Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Figure 72: Example: Handovers due to Threshold Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Figure 73: Indoor Cell Example Network Hierarchy with Three Layers and Two Bands . . . . . . . . . . . . . . . . 265 Figure 74: Multiple HMI Access to OMC-Rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Figure 75: ACO Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Figure 76: X.25 Without Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Figure 77: X.25 With Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Figure 78: RSL Correlation on the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Figure 79: Example: Alarm Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
9 / 306
Figures
10 / 306
Tables
Tables
Table 1: Types of Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Table 2: Network Subsystem Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Table 3: Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Table 4: Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Table 5: System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Table 6: GPRS System Information Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Table 7: Gb Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Table 8: BSCGP Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Table 9: GPRS Mobility Management States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Table 10: Cell Reselection Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Table 11: Network Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Table 12: Time Slot Allocation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Table 13: Autonomous Packet Resource Allocation Time Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Table 14: TBF Allocation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Table 15: PDCH Traffic Load States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Table 16: HSDS Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Table 17: Types of Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Table 18: Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Table 19: Cell List Identifier and Paging Performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Table 20: Paging Request Message and Mobile Station Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Table 21: Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Table 22: Classmark IE Field Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Table 23: Classmark Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Table 24: Mobile Station Ciphering Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Table 25: Downlink Discontinuous Transmission Status in Channel Activation . . . . . . . . . . . . . . . . . . . . . . . . 184 Table 26: Operator Discontinuous Transmission Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Table 27: Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Table 28: Mobile Station Maximum and Minimum Power Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Table 29: Target Cell Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Table 30: Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Table 31: AMR Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Table 32: Circuit-Switched Data Rate Conversions Across the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Table 33: Subsystem O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Table 34: Configuration Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Table 35: Fault Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Table 36: BTS Alarm Hardware Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Table 37: BTS Alarms Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Table 38: Performance Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Table 39: Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
11 / 306
Tables
12 / 306
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 (O&M). These areas describe the O&M functions within the system. It describes both local and distributed O&M functions in a BSS.
Whats New
In Edition 01
Update sections after review Extended GSM (Section 1.4), GPRS Channels and System Information Messages (Section 2.2), Results Analysis (Section 8.6.4) Update section 2G to 3G Handover (Section 1.8.2) with regards for compressed messages in call setup step. Update section 2G to 3G Reselection (Section 1.8.3) with TDSCDMA feature. Update section 2G to 3G Reselection (Section 1.8.3) with availability in case of NC2. Update section Cell Reselection Modes (Section 2.4.3.1) with NC2 related restriction. Update section Modulation and Coding Schemes (Section 2.9.2.2) with recommendation on IR activation. Update section Multi-GPU per BSS (Section 1.3.4.3) for 1 GSL configured on GPU.
13 / 306
Preface
The following improvements are added: DTM in Dual Transfer Mode (Section 1.7.9.5) MCCCH in Control Channels (Section 1.7.9.4) MCS reduction on the flight & WRR in MAC Algorithm (Section 2.7.3.8) MX capacity improvements in HSL Links (Section 1.7.7)
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.
Assumed Knowledge
The document assumes that the reader has an understanding of: GSM GPRS Mobile Telecommunications Network Management concepts and terminology.
14 / 306
1 Introduction
1 Introduction
This section gives a brief overview of the Alcatel BSS, its functions and features.
15 / 306
1 Introduction
1.1 Overview
The BSS provides radio coverage for GSM subscribers in a defined area. Its principal role is to provide and support signaling and traffic channels between mobile stations and the NSS. The following figure shows the BSS within the PLMN, and its links to the PSTN and the PSDN in a fixed network.
PLMN Mobile Stations Network Subsystem MSC TC BTS BSC MFS SGSN PSDN Fixed Network PSTN
Router
OMCR
AGPS server
NMC
: Multi-BSS Fast Packet Server : Network Management Center : Packet Switched Data Network : Public Switched Telephone Network : Serving GPRS Support Node
16 / 306
1 Introduction
Note:
17 / 306
1 Introduction
1.1.5 GPRS
GPRS, the solution chosen by European Telecommunication Standards Institute to answer the demand for increased data transmission rates, is available in the Alcatel BSS. This means there are now two parallel systems in the PLMN: circuit-switched transmission for voice, and packet-switched transmission for data. For information on how GPRS functions in the BSS, see GPRS in the BSS (Section 2) .
18 / 306
1 Introduction
Supplementary Service
User Traffic
Table 1: Types of Call Set Up Call set up processes include: Radio and Link Establishment to assign a signaling channel between the mobile station and the NSS Classmark handling to manage different mobile station power and ciphering capabilities Ciphering to ensure data security on the Air Interface The normal assignment process to assign a traffic channel between the mobile station and the NSS. See Call Set Up (Section 3) for more information.
19 / 306
1 Introduction
20 / 306
1 Introduction
21 / 306
1 Introduction
22 / 306
1 Introduction
23 / 306
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
24 / 306
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 Antennae and TREs are possible. There is no ANy in the BTS A9110, and ANy is not needed if the sector has two TREs.
25 / 306
1 Introduction
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
BTS
BIE
BIE
BSC
TC
TSC BTS
BIE SM TSC TC
Figure 4: Transmission Components in the BSS with A9120 BSC Similarly with A9120, BSS with the A9130 BSC differs by that the transmission components are replaced by virtual transmission processors.
26 / 306
1 Introduction
27 / 306
1 Introduction
28 / 306
1 Introduction
GPU1
BSC
GPU2
GPU3
GPU4
: GPRS Processing Unit
GPU
29 / 306
1 Introduction
30 / 306
1 Introduction
31 / 306
1 Introduction
32 / 306
1 Introduction
SGSN
GGSN
PSDN
Router
OMCR HLR
AGPS server
NMC
GGSN HLR MFS NMC PSDN PSTN SGSN : Gateway GPRS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Network Management Center : Packet Switched Data Network : Public Switched Telephone Network : Serving GPRS Support Node
33 / 306
1 Introduction
34 / 306
1 Introduction
35 / 306
1 Introduction
36 / 306
1 Introduction
37 / 306
1 Introduction
The BSS adds the cell identity of the mobile stations current location to the message sent to the MSC. This information is sent in a Mobility Management sub-layer message and is transparent to the BSS. The NSS stores this information either in its HLR or its VLR. Following a location update procedure, the VLR can assign a new Temporary Mobile Subscriber Identity (TMSI) to the mobile station. See Authentication (Section 3.7) for more information about the TMSI. The following figure shows a mobile station as it moves to a new location area.
VLR
38 / 306
1 Introduction
39 / 306
1 Introduction
OSS
OMCR
Mediation Function
MFS
Network Element
BSC
BSS
BTS
BTS
: Operation Support System : Multi-BSS Fast Packet Server : Network Management Center
40 / 306
1 Introduction
1.6.2 Q3 Interface
Communication between the NMC and the OMC-R takes place across the Q3 Interface (see Figure 8 ). The Q3 protocols can be divided into: Association connection and disconnection mechanisms Message format and structure Command types. For more information on Network Management and the Q3 Interface, see the Operations & Maintenance Principles .
41 / 306
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
42 / 306
1 Introduction
MS
BTS
BSC
BSSAP
BSSAP
BSSAP
LAPDm
LAPDm
LAPD
LAPD
SCCP SS7
SCCP SS7
Layer (2)
Layer (1)
Layer (1)
TC A Interface
Abis Interface
43 / 306
1 Introduction
44 / 306
1 Introduction
45 / 306
1 Introduction
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.
46 / 306
1 Introduction
47 / 306
1 Introduction
Frame 1
Frame 2
Frame 3
Frame 4
Frame 5
AGCH
Figure 11: Time Slot 4 of a TDMA Frame Supporting Access Grant Channels Channels can be divided into traffic channels and control channels.
48 / 306
1 Introduction
Speech Full-rate speech traffic channel Enhanced full-rate speech traffic channel Half-rate speech traffic channel.
Data
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).
Note:
A time slot that is configured as a TCH time slot can be used as a PDCH, a VGCH (Voice Group Call Services Channel), or a standard CS TCH. In terms of radio resource management, there is no practical difference between Voice Group Call Services (VGCS) traffic and standard point-to-point CS traffic, and the operator only configures the TCH.
49 / 306
1 Introduction
The BCCH broadcast cell information to any mobile station in range. Three channels use the BCCH time slot: FCCH: used on the downlink for frequency correction of the mobile station with the BTS SCH: used on the downlink for frame synchronization of the mobile station with the BTS BCCH: used to broadcast system information to the mobile stations on the downlink, to give the cell configuration, and how to access the cell.
CCCH
The CCCH communicate with mobile stations in the cell before a dedicated signaling channel is established. Three channels use the CCCH time slot: RACH: used on the uplink by the mobile station for initial access to the network PCH: used on the downlink for paging messages to the mobile station AGCH: used on the downlink to give the mobile station access information before a dedicated channel is assigned. The multiple CCCH feature allows the operator to use only one additional CCCH, so two Time slots TS0 and TS2 are used. The operator decides to configure either 1 or 2 TS for mCCCH, i.e. no dynamic allocation by the BSS depending on the load is foreseen.
DCCH
The DCCH pass signaling information for a specific mobile station transaction. Two channels use the DCCH time slot: SDCCH: used for signaling and short message information CBCH: uses an SDCCH channel for Short Message Service - Cell Broadcasts.
ACCH
The ACCH pass signaling information for a specific mobile station transaction. An ACCH channel is always associated with a traffic channel. Two channels use the ACCH time slot: FACCH: associated with a traffic channel, and can steal slots out of 24 or 26 slots which are normally dedicated to the traffic channel for signaling purposes as well as the SACCH slot. SACCH: associated with a traffic channel, which uses one out of 26 slots for signaling purposes.
50 / 306
1 Introduction
51 / 306
1 Introduction
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.
Sys_info 2bis
BCCH
Extended Neighbor cell BCCH frequency list in the same band as the serving cell. This message is only sent if Sys_info 2 is not sufficient to encode all available frequencies. RACH control information. Spare bits
Sys_info 2ter
BCCH
Extended Neighbor cell BCCH frequency list in different band as serving cell. The minimum number of cells, if available, to be reported in each supported band in measurement results. RACH control information. 3G cell description. Spare bits
52 / 306
1 Introduction
Message
Sys_info 3
Channel BCCH
Information Cell Identity Location Area Identity Control channel description Cell options: Power central information Discontinuous Transmission (mechanism) information Radio link time out. Cell selection parameters: Cell reselect hysteresis for Location Area reselection Maximum transmit power allowed in cell Additional reselection parameter Allows/forbids new establishment causes (phase 2 mobile stations) Minimum receive level to access cell. RACH control information Spare bits setting flags and timers.
Sys_info 4
BCCH
Location Area Identity. Cell selection parameters: Cell reselect hysteresis for Location Area reselection Maximum transmit power allowed in cell Additional reselection parameter Allows/forbids new establishment causes (phase 2 mobile stations) Minimum receive level to access cell. RACH control information CBCH channel description CBCH Mobile Allocation Spare bits setting flags and timers.
Sys_info 5
SACCH
Neighbor cell BCCH frequency list. For VGCS, only VGCS capable neighbor cell BCCH frequency list.
53 / 306
1 Introduction
Message
Sys_info 5bis
Channel SACCH
Information 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. For VGCS, only VGCS capable neighbor cell BCCH frequency list.
Sys_info 5ter
SACCH
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. For VGCS, only VGCS capable neighbor cell BCCH frequency list.
Sys_info 6
SACCH
Cell Identity Location Area Identity Cell options: Power control information Discontinuous Transmission information Radio link time out Indication of which Network Color Code it is allowed to monitor. For VCGS, status of the NCH, and an indication of whether paging channel restructuring has taken place
Sys_info 7 Sys_info 8
BCCH
SI 7 Rest Octets SI 8 Rest Octets SI 4 Rest Octets_S LSA Parameters LSA ID information LSA identity
Sys_info 10
SACCH
54 / 306
1 Introduction
Message
Sys_info 13
Channel BCCH
Information SI 13 Rest Octets without PBCCH configured in the cell: SI 13 Rest Octets GPRS Mobile Allocation GPRS cell options GPRS Power Control parameters. SI 13 Rest Octets with PBCCH configured in the cell: SI 13 Rest Octets GPRS Mobile Allocation PBCCH description.
Sys_info 16 Sys_info 17
BCCH
SI 16 Rest Octets SI 17 Rest Octets LSA Parameters LSA ID information LSA identity
55 / 306
1 Introduction
Note:
56 / 306
1 Introduction
3G cells UARFCN + Primary scrambling code Only UARFCN or (UARFCN + Scrambling codes per scrambling code group) MCC + MNC + RNC-ID + C-ID UC-ID = RNC-ID + C-ID, C-ID Local Cell Identifier
Only ARFCN
57 / 306
1 Introduction
1.8.2 2G to 3G Handover
Description notions A 2G to 3G handover is based on the measurements reported by the UE/MS. As soon as measurements above a given threshold are reported for one or several 3G cells, those cells are candidate for handover. The averaged measurements received along a given time must be above a given threshold The only measurements requested to the UE/MS are CPICH Ec/No. Nevertheless an internal parameter (FDD_REP_QUANT) is foreseen to choose that type of measurement The feature can be activated or not on a per cell basis, by an O&M parameter (EN_3G_HO) When a dual mode UE/MS enters the RR dedicated mode, it shall send a CLASSMARK CHANGE message and/or a UTRAN CLASSMARK CHANGE message which contains the INTER RAT HANDOVER INFO. There is no acknowledgement from the network at layer 3 If the UTRAN CLASSMARK CHANGE is to be sent by the MS, the CLASSMARK CHANGE message is sent first If a condition is met to perform handover from 2G to 3G, the BSS does not perform an intersystem handover via directed retry. The BSS proceeds with the normal assignment procedure If a condition is met to perform handover from 2G to 3G on the SDCCH, the BSS does not perform an intersystem handover. The BSS proceeds with the normal assignment procedure on the allocated SDCCH When handover to 3G occurs, the LAC can also be used as additional information but it is not part of the cell identifier. There are two types of lists to describe the neighbour cells in the serving cell: Distribution lists. The list is shared between all the MS of the serving cell and consequently build from information sent within the SYSTEM INFORMATION family messages on BCCH or PACKET SYSTEM INFORMATION family messages on PBCCH. Non-distribution lists. The list is given to an individual UE/MS camping on the serving cell and consequently build from information sent in dedicated SYSTEM INFORMATION family, MEASUREMENT INFORMATION and PACKET MEASUREMENT INFORMATION messages on SACCH or PACCH/PCCCH. For 2G to 3G CS handover, in the call setup step of dual mode mobiles, the INTER RAT HO INFO element via the UTRAN CLASSMARK CHANGE message is not segmented and it is compressed. There is a gain of 700ms and a reduction of SDCCH load during call setup. Dimensionning and support constraints: In the Alcatel UTRAN, 2G to 3G handover is supported from Rel-4
58 / 306
1 Introduction
This feature is limited to TCH/2G to TCH/3G handover SDCCH/2G to SDCCH/3G handover is not foreseen to be implemented SDCCH/2G to TCH/3G handover is not foreseen to be implemented When both 2G and 3G candidate cells are determined, the 3G cell(s) prevail A dual mode UE/MS only in dedicated transfer mode can be handedover to UTRAN Maximum number of outgoing 2G to 3G adjacencies at the most per 2G cell: 8 Maximum number of outgoing 2G to 3G adjacencies at the most per BSC: 980 Maximum number of 3G (external) cells at the most per BSC: 450 Maximum number of distinct 3G FDD_ARFCN neighbouring one 2g cell: 3 MEASUREMENT REPORT message is limited to 6 measurements.
1.8.3 2G to 3G Reselection
It is not allowed 2G to 3G reselection in PTM and NC2 in medium radio condition. NC2 2G to 3G reselection is allowed in good coverage condition. 2G to 3G/TDSCDMA cell reselection is available and optional, lockable at OMC-R.
59 / 306
1 Introduction
60 / 306
61 / 306
2.1 Overview
The success of GSM has taken place in parallel with the explosion of interest in the Internet and related data services. Presently, data transmission over the Air Interface is limited to 9.6 kb/s, too slow for use of graphic-intensive services such as the World Wide Web and personal video conferences. In addition, the circuit-switched method used for data transmission makes inefficient use of radio resources, which are under increasing pressure from the growth in GSM subscribers and use. The solution chosen by the European Telecommunication Standards Institute for the double challenge of increased demand for data service and pressure on radio resources is called General Packet Radio Service. The European Telecommunication Standards Institute recommendations establish a standard for inserting an alternative transmission method for data in the PLMN: packet switching instead of circuit switching. The Alcatel GPRS solution follows the ETSI GSM phase 2+ recommendations closely.
62 / 306
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
Figure 12: Model LLC Packet Data Unit used in GPRS Examples of packet-switching protocols include X.25 and Internet Protocol. Since GPRS is compatible with these widely used protocols, it is suitable for access to public or custom packet data services, or to the Internet. Mobile telephones using packet data services must be connected to a portable computer or an electronic organizer.
63 / 306
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 GPRS Support Node : Multi-BSS Fast Packet Server : Public Switched Telephone Network : Serving GPRS Support Node : Visitor Location Register
Figure 13: The Alcatel GPRS Solution in the PLMN In the Alcatel solution, the MFS with its associated interfaces is the BSS element. All other components are external to the BSS. The following internal and external components are described in this section: GPRS mobiles The Serving GPRS Support Node The Gateway GPRS Support Node The Multi-BSS Fast packet Server.
64 / 306
65 / 306
66 / 306
67 / 306
SI 2quater
BCCH
68 / 306
69 / 306
Note:
The common radio signaling functions of the BSCGP are handled on the GPRS Signaling Link, which is carried inside the Ater Interface.
70 / 306
71 / 306
72 / 306
GMM Ready
GMM Standby
73 / 306
NC1
NC2
74 / 306
75 / 306
76 / 306
77 / 306
THR_NC2_LOAD_RANKING
78 / 306
2.4.5 Paging
Paging is the procedure by which the network contacts a mobile station. The network can co-ordinate circuit-switched and packet-switched paging if there is a Gs Interface between the MSC and the SGSN. This means that circuit-switched paging messages can be sent on the channels used for packet-switched paging messages, and vice-versa. Three modes are defined. Mode Network Operation Mode 1 Description Circuit-switched paging messages are sent via the SGSN and MFS. The circuit-switched paging message for the GPRS-attached mobile station is sent on the PPCH or CCCH paging channel, or on the PACCH. This means that the mobile station only needs to monitor one paging channel. It receives circuit-switched paging messages on the PACCH when the mobile station is in packet transfer mode. 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.
Table 11: Network Operation Modes Packet-switched paging does not use the Local Area for paging, but a GPRS Routing Area. The RA is smaller, thus fewer cells are involved. For VGCS, Notification messages are broadcast periodically in the cell, on NCH, and optionally on FACCH, for ongoing point-to-point calls, to notify the VGCS mobile station of a new VGCS call being established. This process is similar to the Paging procedure used for standard calls. Different notification procedures are applied, depending on the mode of the mobile station to be notified: Idle Mode Notification messages are broadcast on the NCH of the cell for new or ongoing VGCS calls Group Receive Mode or Group Transmit Mode Notification messages are broadcast on the FACCH of other ongoing VGCS calls to notify the new VGCS calls that are being set-up in the cell Dedicated Group Transmit Mode Notification messages are broadcast on the FACCH of the dedicated TCH allocated to the talker Dedicated Mode Notification messages are broadcast on the FACCH of all on going point-to-point calls in the cell to notify the new VGCS calls that are being set-up in the cell.
79 / 306
80 / 306
Table 12: Time Slot Allocation Parameters If MAX_UL_TBF_SPDCH is set to five, the minimum raw bit rate per user will be increased from 1.9 kbit/s to 2.68 kbit/s (13.4/5). When the PDCH reaches five, it is declared full and will not accept a sixth shared user. However, setting the N_TBF_PER_PDCH parameter will affect a compromise between resource efficiency and quality of service For example, if N_TBF_PER_PDCH = 2 and coding scheme 2 is used, the preferred raw bit rate per user will be 6.7 kbit/s/s (13.4/2). When the number of users on the PDCH reaches the N_TBF_PER_PDCH value (2), the PDCH is declared "busy" and will preferably not accept a third user. But if the GPRS load is such that all PDCHs are busy, the BSS will override the number of users set in N_TBF_PER_PDCH and increase the number of shared resources to the maximum, using the MAL_XL_TBF_SPDCH value. For VGCS, a time slot configured as a TCH time slot is considered by the BSC to be a TCH time slot reserved for VGCS and normal traffic when it is identified as TCH/SPDCH. When there are VGCS only time slots available (configured but currently free) in the cell, these time slots are used for VGCS. If there are no VGCS only time slots available, the other free VGCS capable time slots are used. Otherwise, VGCS calls are handled as normal calls and are managed using the same time slot allocation strategy as for standard calls.
81 / 306
82 / 306
Autonomous Packet Resource Allocation uses a CS/PS resource-sharing concept with radio resources defined as follows: A Time Slot Defined as [hellip] Reserved for PS Is...
Reserved for PS traffic only. The number of Reserved for PS time slots is defined by the MIN_SPDCH parameter. Used for either CS or PS traffic, but PS traffic has priority. The number of Priority for PS time slots is defined by the MAX_SPDCH_HIGH_LOAD and MIN_SPDCH parameters. Used for either CS or PS traffic, but CS traffic has priority. The number of Priority for CS time slots available is the difference between the MAX_SPDCH and MAX_SPDCH_HIGH_LOAD parameters. Reserved for CS traffic only. The number of Reserved for CS time slots is defined by the MAX_SPDCH parameter.
Priority for PS
Priority for CS
Reserved for CS
Table 13: Autonomous Packet Resource Allocation Time Slots This feature introduces a new parameter, MAX_SPDCH_LIMIT . It defines the number of SPDCHs that can be granted by the BSC to the MFS, and replaces the MAX-SPDCH_DYN parameter.
83 / 306
84 / 306
In a basic case of mobile station initiated PDP context , PFC works as follows: 1. The mobile station defines the required QoS parameters and sends an Activate_PDP_Context_Request or a Modify_PDP_Context_Request message to the SGSN. 2. The SGSN determines the QoS it wants, based on: the QoS requested by the mobile station the subscribed QoS stored in the HLR network QoS constraints. The SGSN then performs internal call admission control and resource allocation. 3. The SGSN asks the GSGN to create the PDP context. 4. The GSGN performs internal call admission control and can eventually downgrade the QoS requested by the SGSN. 5. The SGSN uses the PFC feature to read and, if necessary, manage the QoS (for example, to downgrade resources when there is a cell change to a congested cell). 6. The SGSN informs the GSGN of any changes and informs the mobile station of the PDP context creation or modification, including the final QoS established in the network.
Note:
PFC can only be used if both the BSS and the SGSN support the feature. For more information about PDP context management, refer to Packet Data Protocol Context Activation (Section 2.7.2) .
85 / 306
86 / 306
87 / 306
Upon receipt of an Extra Abis Pool Configuration message, the resource manager: Deletes from the Abis pool any EXTSs indicated as removed from the list of available EXTSs. The corresponding GCHs are released and the Abis and Ater nibbles are then de-switched in the BSC. Add new EXTSs to the Abis pool. From that moment on, the new EXTSs are available to any M-EGCH in the BTS. Upon receipt of an RR Allocation Indication message, the Abis resource manager: Pre-empts any basic Abis nibbles whose time slots are no longer available for PS traffic. The corresponding GCHs (if any) are released and Abis-Ater de-switching is done in the BSC. Adds any basic Abis nibbles whose time slots are newly available for PS traffic to the Abis pool. When a Cell Deletion message is received by the MFS, the Abis resource manager immediately removes all the basic nibbles of the cell (TREs BCCH, static SDCCH) from the pool. All the GCHs using these nibbles are released (but they can be used in another cell). Then Abis-Ater de-switching is done in the BSC.
88 / 306
89 / 306
The four types of TBF re-allocations are described in the table below: This type of re-allocation... T1 T2 Is used to...
Maintain a TBF alive despite a pre-emption. Re-allocate an on-going TBF when establishing a concurrent TBF when: A downlink TBF is established concurrent with an existing uplink TBF, which is allocated with the maximum number of time slots supported in the direction of the bias, re-allocation cannot be given to the mobile station An uplink TBF is established concurrent with a downlink TBF.
T3
Offer better throughput to on-going TBFs when: A TBF cannot be served with the maximum number of PDCHs it supports because: Of lack of resources at the time of the request The EGPRS class is used to establish a GPRS TBF, where the GPRS mobile station class allows a greater number of allocated PDCHs with better PDCH allocation available to serve the TBF. "Signaling traffic" becomes "data traffic" An EGPRS TBF is served on a TRX which offers a higher throughput (i.e., a better TRX class). In this case, "Signaling traffic" becomes "data traffic", and an EGPRS TBF is served on a TRX which offers a higher throughput (i.e., a better TRX class).
T4
Move an uplink GPRS TBF sharing one PDCH with a downlink EGPRS TBF onto PDCHs which do not support a downlink EGPRS TBF. When one PDCH is shared between an uplink GPRS TBF and a downlink EGPRS TBF, the downlink EGPRS TBF is limited to GMSK (i.e., MCS4). Consequently, after a T4 re-allocation the downlink EGPRS TBF is able to use 8-PSK (i.e., up to MCS9). T4 re-allocation is not used with dual transfer mode mobile stations.
90 / 306
Busy
Full
91 / 306
92 / 306
GPRS
Attach
Reque
st
Update
Locati
on
Authe
nticati
on
er scrib Sub ta Da
Subs c Data riber ACK
A GPRS
ttach A
ccept
GPRS
Attach
Comp
lete
: Home Location Register : Multi-BSS Fast Packet Server : Mobile Station : General Packet Radio Service : Serving GPRS Support Node
93 / 306
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.
94 / 306
BSC
MFS
SGSN
GGSN
e PDP
Context
Reque
st
st
Con
Activa
te PDP
Conte
xt Acc
ept
: Gateway GPRS Support Node : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
Figure 15: Mobile Station-Originating Packet Data Protocol Context Activation 1. The mobile station sends an Activation Request to the SGSN.This request contains: Transaction Identifier Packet Data Protocol type Packet Data Protocol address Access Point Name Quality of Service requested Packet Data Protocol configuration options. 2. The SGSN verifies the mobile station subscriber data, creates a Tunnel Identifier (TID - a logical bi-directional tunnel between the mobile station and the GGSN), and sends the new Packet Data Protocol type and address to the GGSN. 3. The GGSN creates a context, sends an acknowledgment to the SGSN, which sends an acknowledgment to the mobile station. 4. The GGSN can now send data through the SGSN, and billing can begin.
95 / 306
Routin
g Info ACK
PDU N
otifica
tion R
eques
PDU N
vatio xt Acit n
otificatio
n Resp
onse
Reque
st PD
te P Con
PDP C
ontext
Activatio
: Gateway GPRS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Protocol Data Unit : Serving GPRS Support Node
Figure 16: GGSN-Originating Packet Data Protocol Context Activation 1. When the GGSN receives data, it sends a message to the HLR requesting the mobile station location. 2. The HLR sends the GGSN location information and the current SGSN IP address. 3. The GGSN sends a PDU Notification Request to the SGSN, which indicates a Packet Data Protocol context needs to be created. 4. The SGSN returns a PDU Notification Response to the GGSN, and sends a Request Packet Data Protocol Context Activation message to the mobile station. This message contains the Packet Data Protocol type and address. 5. The mobile station then begins a Packet Data Protocol context activation procedure as described above.
96 / 306
BSS
SGSN
2 3
RLC
PDU
5
PDU RLC ACK /N ACK
: Logical Link Control : Mobile Station : Protocol Data Unit : Radio Link Control : Serving GPRS Support Node : Temporary Block Flow : Uplink
Figure 17: Mobile-Originated Data Transfer When the mobile station has data to send: 1. An Uplink Temporary Block Flow is requested (either on the PRACH, if there is a master PDCH, or on the RACH). 2. An Uplink Temporary Block Flow is established. 3. Data is sent to the network through the Radio Link Control Protocol Data Units. 4. RLC PDUs are acknowledged by the network. 5. RLC PDUs are re-assembled into Logical Link Control PDUs and sent to the SGSN. 6. On receipt of the last RLC PDUs, an acknowledgment is returned and the Uplink Temporary Block Flow is released.
97 / 306
STAND BY
Pag PCH H or PPC Pack et Ch Requ annel est F L TB et U t Pack ignmen Ass ing P S
2 3
LLC
READY
LLC PDU
DL
: Downlink : Mobile Station : Logical Link Control : Paging Channel : Protocol Data Unit : Packet Paging Channel : Packet Switched : Serving GPRS Support Node : Temporary Block Flow : Uplink
98 / 306
When the network has data to send to the mobile: 1. The SGSN receives a downlink Packet Data Protocol PDU for a mobile station, and sends a paging request to the BSS. 2. The BSS sends packet paging requests to all the cells in the routing area, on the PPCH if there is a master PDCH in the cell, or on the PCH. 3. The mobile station requests the establishment of an uplink TBF from the BSS. 4. The uplink TBF is established, which allows the mobile station to send a Logical Link Control PDU to the SGSN in order to acknowledge the paging message. 5. The SGSN sends the data LLC-PDUs to the BSS. 6. The BSS establishes a Downlink TBF on receipt of the first LLC-PDU, and releases after sending of the last LLC-PDU.
99 / 306
100 / 306
101 / 306
102 / 306
103 / 306
GPRS faulty management: no DL Dummy TBF created for UL GPRS TBF The following rules now apply during the TBFs scheduling in each RT and NRT queue: A DL EGPRS block (whatever the MCS) can be scheduled on a PDCH if and only if there is no UL GPRS USF already scheduled or reserved block on this PDCH in this 20 ms period An UL GPRS USF can be scheduled on a PDCH if and only if no DL EGPRS block is scheduled on this PDCH in this 20 ms period A PDDCB can be sent on a PDCH with an UL GPRS USF but no useful DL CS block. Main principles of MAC algorithm: For any DL or UL TBF, RT or NRT TBF, there are 2 scheduling phases: The basic scheduling for which the credit or weight of the TBF must be greater or equal to the basic_scheduling_limit (current assumption =1) The extra scheduling for TBFs which credit or weight can be below the basic_scheduling_limit This leads to 4 scheduling phases for TBFs: RT basic scheduling NRT basic scheduling RT extra scheduling credit of RT TBF is decreased by 1 when scheduled in this phase NRT extra scheduling A basic scheduling phase Is stopped: Either when all resources (radio & transmission) are consumed Or when all the RT (resp. NRT) TBFs have a credit (resp. weight) < scheduling_limit Or when no RT (resp. NRT) TBF is schedulable anymore (e.g their (M)CS is higher than the available transmission resources) The scheduling of P0 to P2 TBF is not restricted by any credit nor weight (i.e still absolute). Some principles of the enhanced PDDCB solution are listed below: All NRT UL and NRT DL TBFs are managed in the same TBF queue, which leads to the TBF round robin applied between DL TBF and UL TBF All the RT UL and RT DL TBFs are managed in another common TBF queue No need to insert virtual dummy DL TBF for the UL GPRS TBF. Weight management for NRT TBF: The current_weight is initialised to the init_weight when the TBF is activated (or re-activated)
104 / 306
The current_weight is decreased by 1 each time the corresponding TBF is scheduled on one PDCH, unless the current_weight has reached the minimum limit The current_weight is set to null when an UL NRT TBF enters the extended mode or when a DL TBF enters the delayed mode Reset of current_weight" means the following:current_weight = MIN (current_weight + init_weight, maximum_credit_weight) Reset of DL NRT TBFs and UL NRT TBFs weights performed independently: reset of DL current_weights is performed when all the conditions are verified for DL NRT TBFs, even if the conditions are not satisfied for UL NRT TBFs; and vice versa Reset conditions are checked at the beginning of every 20 ms period (e.g to take into account the status change of a NRT TBF that may occur after the scheduling in the previous block period).
105 / 306
1
DeActi vate PD P Conte xt Request
3 4
Context te PDP Activa Accept
De
: Gateway GPRS Support Node : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
Figure 19: Mobile-Originating Packet Data Protocol Context De-activation 1. The mobile station sends a De-activate Packet Data Protocol Context Request to the SGSN. 2. The SGSN sends a Delete Packet Data Protocol Context Request to the GGSN, which contains the TID. 3. The GGSN deletes the Packet Data Protocol context, and sends a Delete Packet Data Protocol Context Response with the de-activated TID to the SGSN. 4. The SGSN sends a De-activate Packet Data Protocol Context Accept message to the mobile station, confirming the de-activation.
106 / 306
MS
BTS
BSC
MFS
SGSN
GGSN
Delete PDP Context Request
SGSNOriginating
3
Context te PDP Activa Request
De
4
DeActi vate PD P Conte xt Accept
GGSNOriginating
2
text PDP Con Request
vate DeActi
3
DeActi vate PD P Conte xt Accept
: Gateway GPRS Support Node : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
107 / 306
1. The SGSN sends a Delete Packet Data Protocol Context Request to the GGSN, which contains the TID. 2. The GGSN de-activates the Packet Data Protocol context and sends a Delete Packet Data Protocol Context Response to the SGSN. 3. The SGSN sends a De-activate Packet Data Protocol Context Request to the mobile station. 4. The mobile station de-activates the context, and returns a De-activate Packet Data Protocol Context Accept.
108 / 306
MS
BTS
BSC
MFS
SGSN
1
RR Susp end
Suspen
3
T3
Suspen
Suspend
Ack
Suspend
Ack
MFS SGSN
Figure 21: GPRS Suspend 1. The mobile station sends an RR Suspend (TLLI, RAI, suspension cause) message to the BSC. This is sent as soon as possible after entering the dedicated mode. If the GPRS suspension procedure was initiated during a GPRS transfer, the mobile station releases all its GPRS resources. 2. The BSC sends a Suspend (TLLI, RAI, suspension cause) message to the MFS, via the GSL link. The BSC stores TLLI and RAI in order to be able to request the SGSN (via the MFS) to resume GPRS services when the mobile station leaves dedicated mode. A timer is not necessary to monitor the Suspend Ack reception. If this acknowledgment is not received (i.e., no Suspend Reference Number (SRN) reception, see step 4 ), the Resume will not be sent at circuit-switched call completion. 3. The MFS sends a Suspend (TLLI, RAI) message to the SGSN. 4. The MFS receives aSuspend Ack from the SGSN, in which there is a Suspend Reference Number which is used in the GPRS resume process. The acknowledgment of the SGSN is supervised by a timer (T3). 5. The MFS sends a suspend acknowledgment to the BSC, with the Suspend Reference Number information.
109 / 306
MFS
SGSN
2
Resu me
T_GPRS_Resume
T4 3
Resu
4k c me A
Resu
me A
ck
5
RR Ch annel Relea se
6
Routing Area Up date Request
MFS MS RR SGSN
: Multi-BSS Fast Packet Server : Mobile Station : Radio Resource : Serving GPRS Support Node
Figure 22: GPRS Resume 1. The BSC determines that the circuit-switched radio channel must be released (typically upon circuit-switched call completion). If the BSC is able to request the SGSN to resume GPRS services (i.e., the suspend procedure succeeded and the BSC received the Suspend Reference Number, and no external handover has occurred), the BSC sends a Resume (TLLI, RAI, Suspend Reference Number) message to the MFS. After sending the Resume message, the BSC starts a guard timer (T_GPRS_Resume) and waits for a Resume Ack message from the MFS. The guard timer is set as short as possible, so as to be compatible with the usual RR connection release procedure, and therefore not delay the procedure. However, this message is not sent in the case of successful completion of an external handover. In this case, the BSC deletes any stored data or suspend/resume context related to that mobile station. 2. On receipt of a Resume message from the BSC, the MFS sends a Resume (TLLI, RAI, Suspend Reference Number) message to the SGSN, starts a guard timer (T4) and waits for a Resume Ack message from the SGSN. 3. The MFS receives a Resume Ack from the SGSN.
110 / 306
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 Resume Nack message from the MFS, the BSC stops the guard timer (T_GPRS_Resume). 5. The BSC sends an RR Channel Release (GPRS Resumption) message to the mobile station and deletes its suspend/resume context. GPRS Resumption indicates whether the BSS has successfully requested the SGSN to resume GPRS services for the mobile station, (i.e., whether the Resume Ack was received in the BSS before the RR Channel Release message was transmitted). The mobile station then exits dedicated mode. If the guard timer expired, or if a Resume Nack message was received by the BSC, the Channel Release message includes the GPRS Resumption indication equal to NOK. 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.
111 / 306
1
Detach Request
3 4
cept tach Ac GPRS De
: Gateway GPRS Support Node : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
Figure 23: Mobile Station-Originating GPRS Detach 1. The mobile station sends a GPRS Detach Request to the SGSN. This message contains: The type of Detach (GPRS or GPRS/IMSI) An indication if the Detach is due to a mobile station switch off. 2. The SGSN tells the GGSN to de-activate the Packet Data Protocol context. 3. The GGSN responds to the SGSN with a message that it has de-activated the Packet Data Protocol context. 4. The SGSN sends a Detach Accept message to the mobile station.
112 / 306
1
Cance l ion Locat
1
Request
tach GPRS De
4
Detach Accept
2
Cancel Location ACK
: Gateway GPRS Support Node : Home Location Register : Multi-BSS Fast Packet Server : Mobile Station : Packet Data Protocol : Serving GPRS Support Node
Figure 24: Network-Originating GPRS Detach Procedures A GPRS Detach can be initiated by both the SGSN and the HLR. An SGSN Detach is the most common network Detach. In this procedure: 1. The SGSN sends a Detach Request to the mobile station, which contains the Detach type. The Detach type tells the mobile station if it needs to re-attach and re-activate the Packet Data Protocol context previously used. 2. The SGSN tells the GGSN to de-activate the Packet Data Protocol contexts. 3. The GGSN responds to the SGSN with a message that it has de-activated the Packet Data Protocol context. 4. The mobile station sends the Detach Accept message to the SGSN. If the Detach is requested by the HLR: 1. The HLR sends a Cancel Location message to the SGSN, which initiates the above process. 2. The SGSN confirms the Packet Data Protocol context deletion by sending a Cancel Location Acknowledgment to the HLR.
113 / 306
114 / 306
Figure 25: Generic LCS Logical Architecture As depicted in the above figure: The GMLC is the first network element for external Location Application (LA) access in a GSM PLMN. The GMLC requests routing information from the HLR via the Lh Interface. After performing registration authorization, it sends positioning requests to the MSC or to the SGSN and receives final location estimates from the MSC or the SGSN via the Lg Interface The SMLC is the network element serving the mobile station. The SMLC manages the overall co-ordination and scheduling of resources required to perform positioning of a mobile station. It also calculates the final location estimate and accuracy. The SMLC controls to obtain radio Interface measurements enabling mobile station location in the service area. The SMLC is connected to the BSS (via the Lb Interface). It dialogs with other SMLCs (via the Lp Interface) to obtain measurements managed by another SMLC when the mobile station is at the border of the SMLC-covered area.
115 / 306
2.8.3.1 TA Positioning
TA Positioning delivers Cell ID, Timing Advance, and, optionally, Measurement Report information to the SMLC. TA Positioning regroups several distinct methods, depending on the availability and the relevance of the elementary information: The Time Advance (TA) Cell Id (CI), only in omnidirectional cells, the geographic co-ordinates of the BTS is returned instead of the real mobile station position. The TA value is used to determine the region as a circle or a ring Cell Id + Timing Advance (CI+TA). With the TA positioning method, no signaling exchange is required between the SMLC and the mobile station . The TA positioning applies to all mobile stations whether they support LCS or not.
116 / 306
4. When the mobile station is in dedicated mode (after a specific SDCCH establishment for location, or during an on-going call), the MSC sends the location request to the BSC in the existing SCCP connection for the current call, which forwards it to the SMLC. 5. The SMLC chooses a positioning method and triggers the appropriate procedure to locate the mobile station. Some message exchanges take place between the SMLC and the BSC.
6. The MSC then sends a response to the GMLC. The LCS-related messages exchanged between the BSC and the MFS are conveyed through current GSLs (same SAPI as for GPRS-related messages).
117 / 306
118 / 306
119 / 306
GCH Nibble Basic Abis nibble Extra Abis nibble PS capable TRX
Established TRX
Allocated PDCH
120 / 306
When a block is retransmitted with a given MCS, it can be retransmitted (if needed) via ARQ with a more robust MCS of the same family.
121 / 306
Two selective ARQ mechanisms are used for the transfer of EGPRS RLC data blocks in the acknowledged RLC/MAC mode: Type I ARQ mechanism: with this mechanism, when a RLC data block is retransmitted, the same or another MCS from the same family is selected Type II ARQ mechanism (also called Incremental Redundancy (IR): in this case a diiferent "puncturing scheme" is applied to the same MCS, if an error is detected. IR and re-segmentation are activated on a per cell basis. Recommendation: check that the 2 features are not activated at the same time. Four Coding Schemes are used for GPRS (CS1 to CS4). GPRS and EGPRS signaling always uses CS1. MCS1 to MCS4 are based on GMSK modulation, while MCS5 to MCS9 are based on 8-PSK modulation. The Alcatel BSS supports MCS5-MCS9 in both the uplink and the downlink direction. Coding Scheme Modulation Maximum rate [kbps] per radio time slot basis 59.2 54.4 44.8 29.6 22.4 17.6 14.8 11.2 8.8 21.55 (UL) 20 (DL) CS3 GMSK 15.75 (UL) 14.4 (DL) CS2 GMSK 13.455 (UL) 12 (DL) CS1 GMSK 9.2 (UL) 8 (DL)
MCS9 MCS8 MCS7 MCS6 MCS5 MCS4 MCS3 MCS2 MCS1 CS4
8-PSK 8-PSK 8-PSK 8-PSK 8-PSK GMSK GMSK GMSK GMSK GMSK
122 / 306
123 / 306
124 / 306
125 / 306
126 / 306
3 Call Set Up
3 Call Set Up
This section 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.
127 / 306
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.
Service Calls
Table 17: Types of Calls The channels used for calls are the SDCCH for signaling (static SDCCH), for traffic and signaling (dynamic SDCCH), and the traffic channel for user traffic (see The Air Interface (Section 1.7.9) for more information). These channels are associated with FACCH/SACCH. An SDCCH is always assigned for call set up, even if a traffic channel is later required for the call. The role of the BSS in call set up is to assign the correct channel for the call, and to provide and manage a communications path between the mobile station and the MSC.
128 / 306
3 Call Set Up
129 / 306
3 Call Set Up
Note:
A VGCS call initiated by a mobile station uses the same general call set up procedures as a standard mobile call; any exceptions are described in the relevant procedure descriptions below.
130 / 306
3 Call Set Up
The mobile station notes the random number and frame number associated with each Channel_Request message. These are used by the mobile station to recognize the response sent from the BSS. This response is sent on the AGCH, which can be monitored by many mobile stations. The mobile station decodes all messages sent on this AGCH, and only accepts a message with a random number and frame number matching one of the last three requests sent.
MS
Channel Request (RACH)
BTS
BSC
MSC
REF
Channel
Required
REF+RFN
+TA
SDCCH Allocation
TA+SD CCH+p ower
Channel
Activati
on Ack
gn te assi
command
TA+
+pow SDCCH
er+RF
N+REF
Immedia
Establish
SCCP Co nnect
es e Requ Servic
nnect SCCP Co
: Description of the allocated SDCCH (Standalone Dedicated Control Channel) : Initial Layer 3 message : Timing advance : Unnumbered 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.
131 / 306
3 Call Set Up
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. In order to establish a radio connection on a VGCH between a mobile station which is in group receive mode on that channel and the BTS, the mobile station sends an Uplink_Access message with the Subsequent_Talker_Uplink_Request parameter on the voice group call channel. The Uplink_Access message is similar to a Channel_Request message but is sent only on the group call channel uplink. The mobile station sends an Uplink_Access message when: a subsequent talker uplink is required The BTS performs any necessary contention resolution and grants the uplink to one mobile station by sending a VGCS_Uplink_Grant message to the mobile station in unacknowledged mode on the main signalling link. The BSS sends Uplink_Busy messages on the main signalling link in all cells of the group call area. There is a reply to an uplink access request.
Note:
For emergency VGCS calls, the Channel_Request message contains the Emergency_VGCS_Channel_Request parameter, which indicates that the fast call set up procedure should be initiated. See Immediate Assignment (Section 3.2.1.3) .
132 / 306
3 Call Set Up
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
wer
DCC
H+po
Chann
el Activ
ation A
ck
power SDCCH TA
: Mobile Station power or BTS power : Description of the allocated SDCCH (Standalone Dedicated Control Channel) : Timing advance
Figure 27: SDCCH Channel Activation For emergency VGCS calls, the immediate call set up procedure is used. If the O&M flag En_FAST_VGCS_SETUP is set to "disabled", when the BSC receives the Emergency_VGCS_Channel_Request message, it ignores the message. If .the O&M flag En_FAST_VGCS_SETUP is set to "enabled", when the BSC receives the Emergency_VGCS_Channel_Request message, it allocates the SDCCH. Once the SDCCH is established, the mobile station uses it to send an Immediate_Set_Up message to core network (this message is transparent for the BSS).
133 / 306
3 Call Set Up
BSC
MSC
Im
te a media
ssignm
ent (
) AGCH
Imm
ass ediate
Switch to SDCCH
REF+
RFN+
CCH A+SD
TA+S
DCC
wer H+po
+REF
+RFN
: Random access information value : Reduced frame number : Description of the allocated SDCCH (Standalone Dedicated Control Channel) : Timing advance
Figure 28: Immediate Assignment The BTS sends the Immediate_Assignment message to the mobile station on the AGCH. The mobile station checks the random number and frame number in the Immediate_Assignment message. If it matches those from one of its last three Channel_Request messages, the mobile station switches to the indicated SDCCH and sets its timing advance to the value indicated in the Immediate_Assignment message. When a mobile station requires an emergency VGCS call, it sends an Immediate_Setup message. When the BSC receives this message, it sends a SCCP_Connection_Request message to establish the dedicated SCCP connection. The user data field of this message contains the Immediate_Setup message. The call is then set up as for a standard voice and/or data call and a SCCP_connection_confirm message is sent, containing the Assignment_Request message in the user field.
134 / 306
3 Call Set Up
Therefore, the system implements a special Immediate_Assignment_Reject message when the following conditions are met: The BSC flag EN_IM_ASS_REJ is set to true. This flag is set on a BSC basis, and can be viewed but not modified from the OMC-R All SDCCHs in the cell are busy. The BSC receives a Channel_Required message from the BTS with one of the following establishment causes: Emergency call Call re-establishment Mobile station-originating call Location update Service Calls. The Immediate_Assignment_Reject message is contained in the information element of the Immediate_Assign_Command message. This message starts a timer in the mobile station which causes it to wait in idle mode until the timer expires, before sending new Channel_Request messages. The length of the timer is dependent upon the establishment cause, and can be set by the user. If an Immediate_Assign_Command message is received before expiration of the timer, it has priority and the mobile station will respond to it, thus connecting the call.
Note:
This message cannot be used when the mobile station is responding to paging, i.e., in the case of a mobile-terminated call. For VGCS emergency calls, when all SDCCH sub-channels in the cell are busy, the BSC sends an Immediate_Assignment_Reject message with "Wait Indication" corresponding to the GSM timer T3122, the value of which depends on the establishment cause in the Channel_Required message. The corresponding value for T3122 is usually equal to 2 seconds (which is the same value as for the establishment cause "emergency call" for the normal a point-to-point call).
135 / 306
3 Call Set Up
136 / 306
3 Call Set Up
BTS
BSC
MSC
UA
Service Request
SCCP Co nnecti
nnecti SCCP Co
irm on Conf
cm Service Request UA
: Classmark : Initial Layer 3 message including the mobile station identity and classmark : Unnumbered acknowledgment
Figure 29: Connection for Mobile-Originated Call For a mobile-originated call, the Layer 3 message from the mobile station contains: An Information Element indicating: CM service request (speech/data, SMS, emergency call) Location updating request (location updating procedure) CM re-establishment request (after a failure) IMSI detach indication (mobile station power off - see IMSI Attach-Detach (Section 3.3.5) for more information). The mobile station identity (see Authentication (Section 3.7) for more information) The mobile station classmark (see Classmark Handling (Section 3.6) for more information). The network uses this message to decide which call negotiation procedures are required and whether to assign a traffic channel.
137 / 306
3 Call Set Up
For VGCS calls, the BSS considers that there are three levels of contention resolution: At cell level The BTS immediately sends a VGCS_Uplink_Grant message as soon as it receives the first correctly decoded Uplink_Access message. Further Uplink_Access messages are ignored. The BTS sends only one Talker_Detection message to the BSC. At BSC level The BSC sends an Uplink_Busy message to all BTS (except the BTS that sent the first Talker_Detection message) in the BSC area involved in the VGCS call as soon as the BSC receives the first Talker_Detection message, in order to prevent too many incoming Talker_Detection messages. If another BTS has received an Uplink_Access message between the time the Talker_Detection message was received by the BSC and an Uplink_Busy message was received by other BTS, then the BSC manages a queue with an initial fixed size of 5. If the queue is full (the sixth Talker_Detection message is received), an Uplink_Release message is immediately sent to the respective BTS. The BSC sends an Uplink_Release message after the first Talker_Detection message has been received from any of the BTS. An Uplink_Release message is sent to all the BTS that have a Talker_Detection message in the queue (possibly 0 to 4), with the exception of the first BTS which sent the Talker_Detection message. The BSC then sends an Uplink_Request_Confirmation message to the MSC. At the network level If uplink requests have been made by more than one BSC, the contention resolution is performed by theMSC.
138 / 306
3 Call Set Up
Note:
When a mobile station makes an emergency VGCS call, it sends an Immediate_Setup message. When the BSC receives this message, it sends a SCCP_Connection_Request message to establish the dedicated SCCP connection. The user data field of this message contains the Immediate_Setup message.
139 / 306
3 Call Set Up
140 / 306
3 Call Set Up
If the BSC finds an error in the Assignment_Request message, it sends an assignment_failure message. If no error is detected, it starts the normal assignment procedure towards the mobile station.
MS
set up
BTS
(SDCCH) layer 3 CC
BSC
layer 3 CC
layer 3 CC
call proceeding
MSC
assignme
TCH allocation
physical
physical
cha
context
request
context co nfirm
power + TA
channel activati on
(SACCH
assign
mman ment co
CH d (SDC
release SDCCH
SABM ( FACCH
UA (F
assignme
ACCH)
Set transcoder
nt comp lete
(FACCH)
assignme
nt comp lete
layer 3 CC
layer 3 CC
layer 3 CC
layer 3 CC
connect acknowledgement
layer 3 CC
cipher cm DTX TA
: Encryption algorithm + ciphering key : Classmark : Discontinuous transmission flags : Timing advance
141 / 306
3 Call Set Up
142 / 306
3 Call Set Up
MS
BTS
MSC
power + TA
channel activati on
(SACCH
channel
activati
on acknow le
dge
assignme
: Encryption algorithm + ciphering key : Discontinuous transmission flags : Mobile Station : Timing advance : Traffic Channel
Figure 31: Channel Activation Process for the Traffic Channel The BSC sends a Channel_Activation message to the BTS. This contains: A description of the traffic channel to be used The mobile station timing advance to be applied The encryption algorithm and ciphering key (same as for SDCCH assignment) A Discontinuous Transmission indicator for uplink (not used) and downlink (see Speech Transmission (Section 4.4) for more information) The mobile station power to be used (see Radio Power Control (Section 4.5) for more information) The BTS power to be used. The BSC starts a timer, and waits for the BTS to acknowledge that it has activated the channel.
143 / 306
3 Call Set Up
The BTS initializes its resources for the traffic channel, sets the ciphering mode, sends timing advance and power information to the mobile station on the SACCH associated with the traffic channel, which is constantly monitored by the mobile station. At the same time, the BTS sends a Channel_Activation_Acknowledgment message to the BSC. The BSC stops its timer and sends an Assignment_Command message on the SDCCH to the mobile station. This instructs the mobile station to change to the traffic channel. When the mobile station receives the Assignment_Command message, it disconnects the physical layer, and performs a local release to free the LAPDm connection of the SDCCH. For VGCS calls, when the BSC receives a Channel_Activation_Acknowledgment message from the BTS, the BSC sends a VGCS_Assignment_Result message.
BTS
BSC
MSC
Set transcoder
h indica ti
on
assignme
nt comp lete
FACCH MS SABM UA
: Fast Associated Control Channel : Mobile Station : Set Asynchronous Balanced Mode : Unnumbered Acknowledgment
Figure 32: Channel Assignment Process for the Traffic Channel The mobile station then establishes the LAPDm connection (via the SABM on the FACCH) for the traffic channel. The BTS sends an Establish_Indication message to the BSC. It also sets the Transcoder and its radio link failure detection algorithm. The BTS sends a Layer 2 acknowledgment to the mobile station. The mobile station sends an Assignment_Complete message to the BSC. When the BSC receives the Establish_Indication message, it establishes a switching path between the allocated Abis and A Interface resources. When it receives the Assignment_Complete message, it sends an Assignment_Complete message to the MSC and initiates release of the SDCCH (see Call Handling for more information). For VGCS, a dedicated TCH is allocated: to the first calling mobile station to subsequent calling mobile stations to listening mobile stations moving into a cell where a VGCH has not been allocated.
144 / 306
3 Call Set Up
layer 3 CC
layer 3 CC
alerting
layer 3 CC
connect acknowledgement
layer 3 CC
connect
layer 3 CC
MS SDCCH
145 / 306
3 Call Set Up
MSC
(PCH)
comman paging
channel
request
(RACH)
channel required
: International Mobile Subscriber Identity : Mobile Station : Paging Channel : Random Access Channel : Temporary Mobile Subscriber Identity
146 / 306
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) .
147 / 306
3 Call Set Up
MS SDCCH
148 / 306
3 Call Set Up
149 / 306
3 Call Set Up
3.4 Paging
Paging is the procedure by which the network contacts a mobile station. For example, if the network needs to inform the mobile station of an incoming call, it pages the mobile station to prompt it to request a channel. After the immediate assignment procedure, the Service_Request message from the mobile station indicates that the connection is in response to a paging message. Paging messages are sent on the CCCH. The downlink CCCH carries the AGCH and the PCH. The PCH is divided into sub-channels, each corresponding to a paging group. To save the mobile station from monitoring every occurrence of the PCH, each mobile station is assigned a paging group calculated from the IMSI. Each mobile station calculates its paging group and monitors only that PCH sub-channel. This saves mobile station battery power. The number of paging groups and the CCCH organization varies for each configuration. The mobile station knows the CCCH organization from the information passed on the BCCH (sys_info 3 ). The AGCH sends the Immediate_Assignment message to the mobile station. A number of blocks can be reserved for the AGCH using the BS_AG_BLKS_RES parameter. If this parameter is set to 0, then the Immediate_Assignment message is sent on the PCH. The following figure shows a TDMA frame with nine CCCH blocks, three of which are reserved for the AGCH and the rest for the PCH. The parameter to reserve these blocks is set to BS_AG_BLKS_RES = 3.
TDMA Frame Cycle
CCCH0
CCCH1
CCCH2
CCCH3
CCCH4
CCCH5
CCCH6
CCCH7
CCCH8
150 / 306
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
151 / 306
3 Call Set Up
Error in IE
Table 19: Cell List Identifier and Paging Performed The BSC calculates the paging group of the mobile station for each cell and the CCCH time slot. It then sends a Paging_Command message to each BTS, indicating the CCCH time slot number, mobile station paging group and the mobile station identity (IMSI/TMSI).
152 / 306
3 Call Set Up
The BTS builds a Paging_Request_Type_x message to send to the mobile station. There are three types of paging request messages, as the BTS can page more than one mobile station at a time. The following table shows the relationship between the paging message type, the number of mobile stations to be paged and the mobile station ID used. Paging Request Message Type_1, identifying up to two mobile stations.
Mobile Station Identification IMSI or TMSI (for one mobile station) IMSI, IMSI or TMSI, TMSI or IMSI, TMSI (for two mobile stations) TMSI, TMSI, TMSI or TMSI, TMSI, IMSI TMSI, TMSI, TMSI, TMSI
Type_2, identifying three mobile stations. Type_3, identifying four mobile stations.
Table 20: Paging Request Message and Mobile Station Identification By using a combination of paging message types, several mobile stations can be simultaneously paged. This is done even if some mobile stations are paged using the IMSI and others are paged using the TMSI. The Paging_Request messages are stored in a buffer, while waiting to be sent on the relevant PCH sub-channel. If this buffer becomes full, the next Paging_Command message is discarded.
153 / 306
3 Call Set Up
When the mobile station receives the Paging_Request message, it sends a Channel_Request message to initiate the immediate assign procedure. The service request message following the immediate assign procedure indicates that the Channel_Request is in response to a Paging_Request message. This is shown in the following figure.
MS BTS BSC
paging t IE cell lis
MSC
paging
comm
and
st
chan REF nel re quire A d
+ RF
N+T
establi
sh ind
ication
: 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
154 / 306
3 Call Set Up
3.5 Congestion
To prevent an Assignment_Request or an external Handover_Request message being rejected, the BSS allows queueing of traffic channel requests. Congestion occurs when all traffic channels are busy for a particular cell and the message arrives at the BSC. Queueing is allowed if indicated by the MSC in the request message.
3.5.1 Queueing
Queueing is used to achieve a higher rate of successful call set up and external handover completion in cases of traffic channel congestion. This is achieved by queueing the request for a defined period of time. During this time a traffic channel can become available and the traffic channel assignment can then be completed. When all traffic channels of a cell are busy, assignment and external handover requests for traffic channel allocation can be queued, if: Requested by the MSC If the MSC allows queueing, this information and the priority of the request for queueing are sent in the Priority Information Element of the request. Configured in the BSC. The BTS can perform queueing if specified in the BSC configuration. BTS queueing can be enabled/disabled by an operator command through the OMC-R. Setting the BTS_Queue_Length parameter to 0 disables queueing. If either the MSC or BSC does not allow the request to be queued, the request is immediately rejected and an Assignment_Failure message is sent to the MSC.
155 / 306
3 Call Set Up
3.5.2 In-queue
If queueing is allowed, the request cannot be queued if one of the two queue limits is exceeded. These limits are: The maximum number of requests that can be queued per BTS if defined by the O&M parameter BTS_Queue_Length . The range is from 1 to 64. This can be individually set for each BTS The global limit of 64 queued requests in the BSS. The sum of all BTS queue lengths cannot exceed 64. When one of the queue limits is exceeded, the request may still be queued if there is a lower priority request in the queue. If the priority of the incoming request is higher than the lowest in the queue, the incoming request is queued and the oldest lowest priority request is then rejected. Once a request is queued, the BSC informs the MSC by sending a Queueing_Indication message. A timer is activated when the request is queued. If the timer expires or the request is preempted by a higher priority request, the request is rejected. Once in the queue, the request waits to be either accepted or rejected due to one of the following events: traffic channel availability or Forced Directed Retry.
156 / 306
3 Call Set Up
157 / 306
3 Call Set Up
3.5.3 Pre-emption
Pre-emption is an optional feature and is initiated during congestion periods. The feature allows radio resources in a cell to be allocated to those calls which are deemed to be the most important. The importance of the connection is given by the MSC to the BSC via signaling on the A Interface. During congestion periods, the BSC ensures that high priority transactions obtain the resources they require. The BSC performs a release of radio resources in order to obtain the radio resource for the higher priority call. For Phase 1 and Phase 2 GSM, the signaling for priority and pre-emption exists on the A Interface. The setting of this data on the A Interface is controlled by the MSC. The conditions under which the information is set is up to operator choices. For Phase 2+ GSM, the priority and pre-emption information is based on subscription data which is stored in the HLR and downloaded to the VLR via MAP protocols. This information can also be used by the MSC when setting the priority level and pre-emption attributes for the call. The pre-emption attributes of a call are defined by three bits: pci: The pre-emption capability indication indicates if the transaction can pre-empt another transaction pvi: The pre-emption vulnerability indication indicates if the transaction can be pre-empted prec: The pre-emption recommendation. This is needed in order to defer pre-emption until a suitable non-congested cell is found in the preferred cell list. The pre-emption recommendation is used when the old BSS recommends that another connection be pre-empted. Pre-emption is applied to the TCH only. The pre-emption feature is optional and controlled by the O&M parameter (EN_TCH_PREEMPT) on a per-BSC basis. The BSC provides pre-emption of TCH radio resources. This takes into account the priority of the call. The lowest lower priority call with the pvi bit set is pre-empted and thus released. Directed retry and/or forced handover in order to avoid pre-emption is not supported.
3.5.3.1 eMLPP
Enhanced Multi Level Priority and Pre-emption (eMLPP) is a supplementary service that allows a subscriber in the fixed or mobile network to initiate calls that have a priority and pre-emption attribute known to all the network elements. The eMLPP standardization provides the transportation of the subscription information for priority and pre-emption on MAP. This subscription information is stored in the HLR and the GCR and is transported to the VLR. This information is used for the following procedures: Paging TCH Assignment TCH Handover. Only TCH pre-emption is supported (i.e., only for circuit-switched services). Pre-emption for VGCS is possible for both the VGCH, in transmit and receive modes, and for the dedicated channel, in dedicated transmit mode.
158 / 306
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.
159 / 306
3 Call Set Up
3.6.1 Classmark IE
The Alcatel 900/1800 BSS supports classmark 1, classmark 2 and classmark 3 IEs. Classmark 1 IE is always sent to the BSS when the mobile station tries to establish communication. Classmark 1 The Classmark 1 IE contains: The revision Level The RF Power Level Support of A5/1 Encryption. Classmark 2 The Classmark 2 IE is defined in GSM to allow the coding of phase 2 capabilities such as the A5/2 ciphering algorithm and VGCS capability. The classmark contains the same elements as Classmark 1 IE, plus support of A5/2 encryption. Classmark 3 The Classmark 3 IE is defined in GSM to allow multiband mobile stations to indicate their capabilities. The classmark specifies the supported bands and the respective power classes.
160 / 306
3 Call Set Up
RF Power Level
161 / 306
3 Call Set Up
Action The classmark_enquiry message is never initiated by the BSC. The BSC always initiates a classmark update when it receives a location update request. The BSC only initiates a classmark update on reception of a location update request if A5/1 is not available. This is worked out from the classmark 1 IE.
Table 23: Classmark Configuration If the system requests a classmark update to a phase 1 mobile station, the mobile station is not able to respond. It considers the message an error and sends an RR_status message. This message is ignored by the BSS and is not passed to the MSC.
162 / 306
3 Call Set Up
MS
channel re quest
BTS
(RACH) channel requ ired
BSC
MSC
switch to SDCCH
SABM + rn + fn + cm
establish in dication
ACCH (FACCH/S
) classmar y k enquir
nnecti SCCP co
on
confirm
classmark change
classmark 2IE
classmark update
location update
classmark 2IE
(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 : Standalone Dedicated Control Channel : Timing advance
163 / 306
3 Call Set Up
1. The mobile station initiates a location update procedure by sending a Channel_Request message on the RACH. 2. The BSS performs the immediate assign procedure, as described in Mobile-Originated Call (Section 3.2) . 3. The mobile station establishes the LAPDm link and sends the location update request and classmark 1 IE. The BTS sends an Establish_Indication message to the BSC, containing the location update request and classmark 1 IE. 4. The BSC uses the classmark to send mobile station power control information to the BTS to start power control. It stores the classmark information and requests an SCCP connection with the MSC. 5. When the BSC receives an SCCP_Connection_Confirm message, it sends a classmark_enquiry message to the mobile station. 6. The mobile station responds with a classmark_change message containing the classmark 2 IE. This information is passed to the MSC in a classmark_updating message. If the mobile station is a phase 1 mobile station, it responds with an RR_status message which is ignored by the BSS. In this case, the BSS sets ciphering with the information available from the classmark 1 IE. 7. The MSC initiates the authentication procedure and on receipt of the authentication response message, initiates the ciphering procedure. Refer to Ciphering (Section 3.8) for more information about ciphering. 8. When ciphering is set, the MSC can accept the location update.
164 / 306
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.
3.7.1 IMSI/TMSI
When the subscriber accesses the network for the first time, the subscription is identified by the IMSI sent in the Location_Updating_Request message. When the NSS has performed authentication and set the ciphering mode, the VLR assigns a TMSI, in an encrypted format over the Air Interface. The next time the subscriber connects to the system, it uses the TMSI as its identification. If the mobile station has changed location area, it includes the old Location Area Identity. The new VLR interrogates the old VLR for the authentication information (IMSI and Ki value). The new VLR then assigns a new TMSI. This is shown in the figure below. New TMSIs can be assigned by the serving VLR at any time. The subscriber identity is secure because the TMSI is always ciphered and changed regularly.
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
165 / 306
3 Call Set Up
166 / 306
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.
167 / 306
3 Call Set Up
168 / 306
3 Call Set Up
169 / 306
3 Call Set Up
MSC
ciph
mo ering
de co
ciphe
ring
mod
mm e co
and
ption c
nd omma
ted a permit
lgorith
ms +
Kc
(SDCC
H)
algorithm or no encryption
cipher
ing mo
de com
te
MS SDCCH
170 / 306
3 Call Set Up
Note:
171 / 306
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
Figure 42: Example of TFO Establishment Referring to the figure above, the call establishment is as follows: 1. At call establishment, the BSC sends the Channel_Activation message to the BTS, containing information related to TFO. 2. TRAU frames are exchanged between the BTS and the Transcoder. PCM samples are exchanged between the TRAUs. One TRAU frame is stolen from the BTS by the Transcoder, to send TFO configuration information (in the con_req message). 3. As soon as the TRAUs receive the information that TFO is enabled in the con_req message, (and also the TFO configuration information), they send the tfo_req message, within PCM speech samples, to indicate that the TRAUs are TFO capable. Meanwhile, the TRAUs acknowledge the con_req message to the BTS with the dl_ack indication. 4. The TRAUs acknowledge that the tfo_req message has been received by sending a tfo_ack indication. 5. The same codecs are then used on both sides. The TRAUs can exchange TFO frames. 6. The BTS are made aware of the exchange of TFO frames by tfo_on . The BSC is informed via a tfo_report message on the Abis Interface.
172 / 306
3 Call Set Up
The Alcatel TFO implementation is fully compliant with the GSM standard and additionally provides: As an operator choice, the Alcatel BSS is able to force the distant BSS (Alcatel or not) to overcome ETSI codec choice rules, in order to optimize voice quality and load management. This mechanism is patented by Alcatel Codec optimization, to take into account that the two mobile stations may use the same codec, but a better codec is available on both parts.
173 / 306
3 Call Set Up
174 / 306
4 Call Handling
4 Call Handling
This section provides an overview of Call Handling and describes the supervision of a call in progress.
175 / 306
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.
Note:
A VGCS call uses the same general call handling procedures as a standard call; any exceptions are described in the relevant procedure descriptions below.
176 / 306
4 Call Handling
Note:
Changing the data rate of a fax call is not a true in-call modification procedure, as the teleservice is not changed (no dual-service negotiation). The main difference between the in-call modification procedure and a change of data rate for fax are as follows: The in-call modification procedure is triggered by a message from the mobile station The data rate change for fax is triggered by in-band signaling from the fax machine to the MSC. Both procedures use existing resources, therefore no new resources need to be allocated. All full-rate traffic channels can be used for speech or data at any of the defined data rates. Both procedures use the mode modify procedure to change the transmission mode. This is basically a normal assignment procedure but instead of a new channel being assigned, a new mode is assigned.
177 / 306
4 Call Handling
178 / 306
4 Call Handling
179 / 306
4 Call Handling
180 / 306
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
181 / 306
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.
182 / 306
4 Call Handling
183 / 306
4 Call Handling
To eliminate the noise side effects generally known as banjo noise, the operator can ban Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX, without hopping, for all types of BTS. This is achieved using the FORBID_DTXD_NH_BCCH parameter. The parameter can be set to one of two values: 0. This is the default value, and allows Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX 1. This bans Discontinuous Transmission on the downlink for all calls that are established on the BCCH TRX.
OMC-R Discontinuous Transmission_ DOWNLINK_ ENABLE (per BSC basis) True True
False False
OFF OFF
Table 25: Downlink Discontinuous Transmission Status in Channel Activation The MSC requests no downlink Discontinuous Transmission during mobile station-to-mobile station calls, where double clipping can occur if both ends perform Discontinuous Transmission. This can have a staccato-like effect on speech.
184 / 306
4 Call Handling
The BTS tells the Transcoder to perform Discontinuous Transmission by setting the Discontinuous Transmission bit in the speech frame. In the BSS, the Transcoder is responsible for Discontinuous Transmission operation. In the BTS, the information is processed in the FU in the following way: 1. When the Transcoder detects voice activity it informs the FU, using in-band signaling. The speech signaling flag is set in the speech frame. 2. Every 20 ms the FU receives either speech frames or SID frames containing background noise characteristics. 3. At the end of the speech period (four bursts of detected silence) the FU sends a SID frame over the Air Interface. 4. During speech inactivity, the last received SID frame is sent at regular 480 ms intervals rather than at 20 ms. Otherwise dummy bursts are sent. These dummy bursts are: Transmitted for traffic channels on the BCCH frequency, due to the need for constant transmission on the BCCH frequency Not transmitted for traffic channels on other frequencies.
Note:
The BTS uses the measurement_result message to inform the BSC that Discontinuous Transmission is operating. The BSC compensates for Discontinuous Transmission when calculating power control and handover.
185 / 306
4 Call Handling
Table 26: Operator Discontinuous Transmission Options The Transcoder detects that the mobile station is in Discontinuous Transmission mode by the reception of SIDs.
Note:
There is a small quality reduction due to the fact that VAD only starts sending speech when a user starts to talk. This can cut the start of each speech activity. Power control and handover are also affected, as the BTS has fewer incoming messages with which to calculate power and interference.
186 / 306
4 Call Handling
187 / 306
4 Call Handling
188 / 306
4 Call Handling
Table 27: Radio Link Measurements The statistical parameters of signal level and quality are obtained over a measurement period. This period is called the Reporting Period. The reporting period for a traffic channel is 104 TDMA frames (480 ms). The information is transmitted in the SACCH frames.
189 / 306
4 Call Handling
clear
a F ch
requ
est
c clear
omm
and
MIE
MS TX : Mobile Station : Transmitter
inclu
din
use g ca
valu
190 / 306
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
191 / 306
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
Table 28: Mobile Station Maximum and Minimum Power Ranges The maximum power setting of a mobile station is based on two factors: its classmark (its physical maximum power rating), and the maximum mobile station power setting for the cell. Each cell can limit the maximum power level for all mobile stations in the cell. For example, a 20 W mobile station can be limited to 5 W maximum power if that is the maximum mobile station power level allowed in the cell. However, a 1 W mobile station can never exceed 1 W, and can therefore never reach the 5 W maximum allowed in the cell. The BSC informs the BTS of the new power levels via the BS_power_control message. The BTS in turn transmits a power_command to the mobile station over the SACCH. Changing power from one power level to another happens gradually. The power level changes by 2 dB every 60 ms, until the desired level is reached.
192 / 306
4 Call Handling
4.6 Handover
A handover changes an active call from one channel to another channel. The new channel can be in the same cell or another cell. The types of handover are: Internal External Directed retry Incoming emergency Fast traffic UMTS to GSM. Handovers ensure a high level of call quality. They are performed when the BSS detects that the call quality has dropped below a defined level, and the call can be better supported by a different channel. The call quality can drop due to problems in the cell, such as an interface or an equipment problem. Call quality can also be affected simply because the mobile station has moved to an area where the radio coverage from another cell is better. The BSS detects the need for a handover by: Measuring the Air Interface channel quality, mobile station and BTS power outputs and the timing advance Using an algorithm to see if the received information conforms to the criteria for handover Selecting a more suitable channel from a list of target cells and their available channels. If the BSS decides that a handover is required, the exact sequence of events depends on the type of handover to be performed. In all cases: A new channel is assigned, ready to support the call The mobile station moves over to the new channel On successful completion of the handover, the system clears the resources for the old channel.
193 / 306
4 Call Handling
194 / 306
4 Call Handling
195 / 306
4 Call Handling
196 / 306
4 Call Handling
197 / 306
4 Call Handling
The figure below shows a graph of received signal level and received signal quality. The hatched areas show where power control is successful. The solid gray shaded areas show where power control fails to achieve the desired level/quality ratio. These areas are where the BSC detects the need for a handover.
High Quality
123456 123456789 123456789 123456 123456 123456789 123456789 Level 123456 Power Desired Power 123456789 Intercell 123456 Increase Quality Decrease to Handover to and Level 123456789 Conserve 123456 Improve Balance Resources 123456789 123456 Level (no action 123456789 and Minimize 123456 needed) Interference 123456789 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
198 / 306
4 Call Handling
199 / 306
4 Call Handling
200 / 306
4 Call Handling
BSS 1
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789
BSS 2
201 / 306
4 Call Handling
Macrocell with little traffic Minimum Dwell Time High minimum dwell time
202 / 306
4 Call Handling
203 / 306
4 Call Handling
Mobile station distance from target BTS Handover cause. The HO_MARGIN parameter is an O&M parameter set by the Network Operator. It is used to prevent a call being continually handed over between two cells. For example, following a power budget handover, the new cell immediately starts power budget calculations for its neighbor cells. It may find that the original cell is giving a better power budget reading and try to hand back immediately. This effect can be caused by slight climactic changes which affect the propagation of signals. It is known as the ping-pong effect. The HO_MARGIN parameter stops a call being handed back to a cell from which it has just been handed over. There is also an O&M parameter, W_PBGT_HO which can be set by the OMC-R operator, to add a weighting for the power budget parameters of cells controlled by another BSC. Refer to the A1353-RA Configuration Handbook for more information. The target cell chosen also depends on the mobile station classmark (see Classmark Handling (Section 3.6) ) and its compatibility with the BTSs ciphering capabilities (see Ciphering (Section 3.8) ). The procedures initiated to hand over a call depend on which cell has been chosen as the target cell.
204 / 306
4 Call Handling
205 / 306
4 Call Handling
Target BTS
(SACCH)
Serving BTS
Target BSC
Serving BSC
MSC
1
measurement results
2 3
channel activation
SACCH/FACCH
required
e+c l IDs+DTX+caus
d handover comman
handover command
handover detect
5
handover detect HO ref + TA handover detect
6
ack
establish indication
(FACCH)
clear command
: Discontinuous Transmission : Fast Associated Control Channel : Handover : Mobile Station : Set Asynchronous Balanced Mode : Slow Associated Control Channel : Timing advance
206 / 306
4 Call Handling
207 / 306
4 Call Handling
5. The mobile station releases its connection to the serving BTS. It synchronizes with the target BTS using the FCCH and SCH information. Once synchronized, the mobile station continually sends access burst on the uplink SACCH until it receives the Physical_Information message on the FACCH from the target BSC. When the target BTS receives an access burst, it checks the handover reference and calculates the timing advance. This is sent to the target BSC in the Handover_Detect message. The target BSC informs the MSC of the handover detection and establishes a switching path between the allocated Abis and A Interface resources. 6. When the mobile station receives the Physical_Information message, it sends its first frame on the new channel using the timing advance sent in the Physical_Information message. The target BTS acknowledges the mobile stations first frame and sends an Establish_Indication message to the target BSC, and an acknowledgment to the mobile station. On receipt of the acknowledgment, the mobile station sends a Handover_Complete message on the uplink FACCH to the target BSC. The target BSC informs the MSC that the handover has been performed. The MSC initiates the call clearing procedure towards the serving BSC.
208 / 306
4 Call Handling
Power Budget
Cause 21
Cause 23
Cause 24
209 / 306
4 Call Handling
210 / 306
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.
211 / 306
4 Call Handling
212 / 306
4 Call Handling
access classes have been barred. This forces the mobile station to camp on another cell
AUTO_BAR_EC enables/disables the automatic barring of emergency calls. EN_BSS_OVRL_CLASS_BARR enables/disables the ability of the BSC to
perform global action for BTS-to-BSC overload conditions. The number of access classes that can be barred and unbarred in one step can also be configured from the OMC-R.
213 / 306
4 Call Handling
214 / 306
5 Call Release
5 Call Release
This section provides an overview of Call Release and describes the procedures which ensure resource allocation to a call. This section also describes Remote Transcoder Alarms, and the processes used to break a connection and disconnect the resources, depending on the nature of radio transmission.
215 / 306
5 Call Release
5.1 Overview
The Call Release procedures ensure that resources allocated to a call are free for reuse when they are no longer required by the current call. Call Release procedures are required when: A call is finished and either the called or calling party hang up A mobile station is turned off A call is handed over and the resources for the original call are released A call is modified and the resources for the original channel are released There is operator intervention, such as a channel being blocked There is a failure There is a radio link failure The system detects an LAPDm failure. If a call is terminated normally, the Call Release procedures are triggered automatically. If the call is terminated abnormally, the system has to detect that the resources are no longer required and release them. For a complete Call Release, the following resources must be released: A Interface resources Abis Interface resources Air Interface resources MSC resources: Layer 3 for the A Interface SS7 signaling for the A Interface Layer 1 physical resources for the A Interface. BSC resources: 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 resources: 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 resources: Layer 3 for the Air Interface Layer 2 LAPDm for the Air Interface Layer 1 for the Air Interface.
216 / 306
5 Call Release
Note:
A VGCS call uses the same general call release procedures as a standard call; any exceptions are described in the relevant procedure descriptions below. For more information about special cases, including detailed behavior of the MSC, BSC, BTS and mobile station, refer to Call Release - Special Cases (Section 5.3) .
MS
disconne ct
BSS
(layer 3 CC)
MSC
request release
CC) (layer 3
release
complete
(layer 3 CC)
MS
: Mobile Station
Figure 53: Mobile Station Disconnecting a Call 1. Once the MSC has confirmation that the mobile station wants to disconnect and no longer requires the connection, it initiates the release procedure towards the BSC. This procedure: Releases the circuit (if applicable) Releases the SCCP connection. 2. The BSC responds to the MSC to clear the connection on the A Interface, and initiates the Call Release procedure toward the BTS and mobile station. This procedure releases the radio resources.
217 / 306
5 Call Release
3. This action triggers the mobile station to release the LAPDm connection (disc message) and the BSC to release physical resources allocated to the call. This is shown in the following figure.
MS BTS BSC
clear c omma nd
MSC
e va g caus lue
clu MIE in
chann el rele ase
at ctiv eS AC CH
din
dea
(to re
disc
lease
LAP
UA
dicati
SCCP
on
SCCP
releas
ed
phys
ical co
que ntext re
st
releas
e com
plete
physic
al con
Timer
text co releas nfirm
RF ch RF ch
annel
annel
Timer
releas e ack
: Link Access Protocol on the Dm Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Signal Connection Control Part : Transcoder : Unnumbered Acknowledgment
218 / 306
5 Call Release
1
clear command
value g cause
dea
cti
SAC ate
CH
clear co mplete
2 3
SCCP re lease
complete
: Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Signal Connection Control Part
Figure 55: Initiation of Normal Release by MSC 1. The MSC initiates the release procedure by sending a Clear_Command message to the BSC. This command can include a cause value in the Mandatory Information Element. 2. The BSC accepts the command even if no cause value is included. It immediately releases the A Interface resources for the call and replies to the MSC with a Clear_Complete message. 3. The BSC initiates the release of the Abis and Air Interface resources. It also sets a timer to ensure that the MSC releases the SCCP signaling resources. On receipt of the Clear_Complete message from the BSC, the MSC releases the resources associated with the A Interface and initiates the release of the SCCP signaling resources by sending the SCCP_released message to the BSC. 4. The BSC stops its timer and sends the SCCP_release_complete message. The SCCP resources are now released and can be used for another call. If the BSC timer expires before the SCCP_released message is received, then the BSC force releases the SCCP connection.
219 / 306
5 Call Release
The MSC also initiates two types of call release for VGCS calls: Uplink release requested by the BSS When the BSS detects that the mobile station is no longer connected, it sends the MSC an Uplink_Release_Indication message containing the Radio_Interface_Failure message. When the MSC receives this message, it initiates the release of the radio and terrestrial resources associated with the call. Uplink release requested by the MSC The MSC initiates the release of the radio and terrestrial resources associated with the call when it detects that the previous talking service subscriber is no longer talking, or that the talker has left the group call area. When a mobile station belonging to another BSC area has successfully sized the VGCH, the MSC informs the BSC. The BSS then notifies the other mobile stations that the channel is busy.
220 / 306
5 Call Release
3. When the BTS receives the Deactivate_SACCH message, it stops sending SACCH information and disables the remote Transcoder alarm detection. This stops the sending of Transcoder alarms to the BSC when the Transcoder detects inactivity on the channel. This is shown in the figure below. If the mobile station does not receive the Channel_Release message, it considers the stopping of SACCH information as a radio link failure and performs a local release.
MS BTS
1
BSC
clear c o d mman
MSC
lue
clud MIE in
chann el rele ase
dea ate ctiv SAC CH
ing ca
use va
2
(to re
disc
plete
lease
UA
releas
ed
relea
se in
dicati
on
SCCP
releas
e com
plete
: Link Access Protocol on the Dm Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Signal Connection Control Part : Transcoder : Unnumbered Acknowledgment
221 / 306
5 Call Release
Once the BSC considers the mobile station disconnected, it initiates release of the RF channel from the BTS. In a normal Call Release procedure, this occurs following the release of the mobile station from the Air Interface (as described earlier in this section). 4. Before releasing the RF channel, the BSC sends a physical_context message to the BTS and starts a timer to supervise the response. The response from the BTS is a physical_context_confirm message which contains the last LAPDm performance measurements for the RF channel. 5. On receipt of the physical_context_confirm message, or after the timer has timed out, the BSC sends an RF_Channel_Release message to the BTS and starts a timer to supervise the release. The BTS releases the level 1 and 2 resources for the channel and replies with an RF_Channel_Release_ack message. On receipt of the acknowledgment, the BSC releases all resources for the RF channel. This is shown in the following figure.
MS BTS BSC MSC
3
UA
releas
e indi cation
physical
context
4 request
Timer
confirm
physical
context
5
nel RF chan release RF chan nel
release
Timer
ack
MS UA
Figure 57: Normal Release Final Steps If the timer supervising the release times out, the BSC sends the RF_Channel_Release message again and restarts the timer. If the timer times out again, the BSC releases all resources locally. It also sends an O&M error report to the OMC-R with a cause value indicating that the RF channel release procedure has failed.
Note:
The RF channel can be released locally by the BTS and still be active. If the RF channel is still active, it is released when the BSC attempts to assign it to another call with a Channel_Activation message. The BTS replies with a Channel_Activation_Nack and the BSC releases the channel (refer to Call Set Up (Section 3) for more information). For VGCS calls, when the mobile station terminates the call, the VGCH is released and other mobile stations can attempt to seize the VGCH in order to become the subsequent talking mobile station in the VGCS call.
222 / 306
5 Call Release
Target BTS
Serving BTS
e
Target BSC
Serving BSC
MSC
handover complet
handover perform
ed
clear
chan
nel r
elea
se
tiva deac
te S
ACC
: Fast Associated Control Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel
223 / 306
5 Call Release
5.3.1.1 Reset
The MSC initiates Call Release when it has to release all calls associated with the BSS (Reset). The MSC sends a reset message containing a cause value to the BSC. The BSC then: Sends an alarm to the OMC-R Sends a block message to the MSC to block circuits Starts to clear all calls in the BSS. For each call, the procedure in Normal Release (Section 5.2.1) is repeated. For each SCCP connection on the A Interface, the BSC can send an SCCP_release message and release any A Interface resources associated with the SCCP. A timer allocates a certain amount of time for the calls to clear. When the timer expires, the BSC sends a reset_ack message to the MSC. Figure 59 shows the Call Release process after a reset is initiated.
224 / 306
5 Call Release
MSC
block
releas e com e
SCCP
circuits blocked
disc
SCCP
releas
plete
to relea
se LAP
Dm
channe
e l releas release in
xt req
SCCP re dication
SCCP releas
lease
plete
disc
a physic
l conte
uest
e com
to rele
ase L
APDm
physic al con text co nfirm rele indic ase atio l n RF channe release
RF channe l release ac k
confirm
RF cha
ase
RF chan
nel relea
se 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.
225 / 306
5 Call Release
MSC
st
rc clea
om
ma
nd
i MIE
nclu
din
u g ca
se v
alue
MIE MS
226 / 306
5 Call Release
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.
227 / 306
5 Call Release
228 / 306
5 Call Release
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.
229 / 306
5 Call Release
The BSC re-initializes the link with the frame unit and starts Call Release for the affected calls with the MSC. This sequence is shown in the following figure.
MS BTS Detection of LAPD failure. BTS stops sending SACCH frames.
disc
BSC
MSC
timer
disc
timer
disc
UA
UA
UA
cause
value
mmand clear co
: Frame Unit : Link Access Protocol on the D Channel : Mandatory Information Element : Mobile Station : Slow Associated Control Channel : Transmitter/Receiver Equipment : Unnumbered Acknowledgment
230 / 306
5 Call Release
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
connec tion f ailure indica ti on
cause
value
clear reques
h RF c
l anne
as rele
clea
mm r co
and
incl MIE
udin
us g ca
lu e va
MIE MS SACCH
Figure 62: Call Release due to Mobile Station-Initiated Radio Link Failure
231 / 306
5 Call Release
Alarm
con
nec
tion
failu
caus
re in
e va
dica
lue
tion
Fc
han
rele nel
ase
clea
r req
ues
clea
r co
mm
and
MIE
inc
g ludin
cau
se v
alue
MIE MS TC
232 / 306
5 Call Release
233 / 306
5 Call Release
234 / 306
235 / 306
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 BTS in its domain. Transmission provides the efficient use of the terrestrial links between the BSS components. Together these components perform the required encoding and rate adaptation procedures.
6.2 Speech
Speech is passed from the mobile station to the PSTN and from the PSTN to the mobile station. This section describes how speech is encoded from the mobile station to the PSTN, as shown in the following figure. Speech in the opposite direction follows the reverse process and so is not described.
Full Rate Speech TCH A 13 kbit/s CIM 13 kbit/s 64 kbit/s A/D
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
PSTN
Mobile Station A 6.5 kbit/s CIM 6.5 kbit/s 13 kbit/s 64 kbit/s A/D
Figure 64: Encoded Speech Transmission Across the BSS with A9120 BSC The scheme is similar in the BSS with A9130 BSC, excepting the BIE and SM A9120 BSC transmission components, which are supported by virtual processors.
236 / 306
6.2.1 Analog
The microphone converts speech to an analog signal. The analog signal is encoded into a digital signal depending on the type of traffic channel used: 13 kbit/s for a full-rate traffic channel (or enhanced full-rate) 6.5 kbit/s for a half-rate traffic channel. It is then transmitted on a 16 kbit/s (8 kbit/s for half-rate) radio time slot. 3 kbit/s and 1.5 kbit/s are used for signaling on full-rate and half-rate channels respectively.
237 / 306
BSC
SM
SM
TC
MSC
Figure 65: Multiplexed Ater Interface This scheme corresponds to A9120 BSC. For A9130 BSC there is no SM or Ater interface beside the BSC.
238 / 306
239 / 306
6.2.7 Half-Rate
Half-rate speech channels allow the operator to save time slots on the Air Interface when the number of available frequencies is very limited. Half-rate uses a different encoding algorithm than full-rate, in order to minimize any perceived loss of comfort by the subscriber. Use of the half-rate feature does create extra overhead on the A Interface. Half-rate is activated on a per-cell basis. In effect, the cell is capable of operating in Dual Rate mode, permitting either half-rate or full-rate traffic channels to be allocated. VGCS calls can be use either standard full-rate or half-rate channels. Half-rate can be applied to BSSs with the following equipment: BSC A9120 BSC A9130 G2 Transcoder A9125 Transcoder One of the following BTS: G1 BTS equipped with Dual Rate Frame Unit G2 BTS equipped with DRFU Evolium BTS.
240 / 306
241 / 306
242 / 306
AMR_SUBSET_HR
EN_AMR_CHANNEL_ADAPTATION
EN_AMR_HR
EN_AMR_FR
OFFSET_CA_NORMAL
OFFSET_CA_HIGH
RXQUAL_CA_NORMAL
RXQUAL_CA_HIGH
AMR_THR_3, AMR_THR_2, AMR_THR_1 AMR_HYST_3, AMR_HYST_2, AMR_HYST_1 Table 31: AMR Configuration Parameters
243 / 306
244 / 306
6.2.10 VGCS
Voice Group Call Service is a BSS feature that allows speech conversation for a predefined group of up to 6 mobile stations in half duplex mode on the Air Interface. VGCS enables a calling mobile station to establish a voice group call to destination mobile stations belonging to a predefined group call area and group ID. VGCS typically involves multiple group members in a small group call area, which is comprised of one cell or a cluster of cells. Group call areas are predefined in the network by the service provider, and co-ordinated by the network operator. The calling and destination mobile stations are any mobile stations that have subscribed to the related group ID or any dispatcher whose ID is pre-registered with the network. Destination mobile stations are all mobile stations or groups of mobile stations identified by the group ID which are currently located in the group call area, and pre-registered dispatchers. When a mobile station initiates a VGCS call, the group call area is uniquely identified by the actual cell in which the mobile station resides at the moment of VGCS call initialization, and by the group ID it sends. When a dispatcher initiates a VGCS call, the dispatcher is connected to a related predefined group call area. The entitlement of the dispatcher is checked by the MSC to verify the calling identity. Since a dispatcher may be registered to more than one group call area and group ID, an indication of the wanted group call area and group ID is given in form of a dedicated address called by the dispatcher. The service permit only one calling mobile station to talk at any moment; while up to five dispatchers can be talking simultaneously at one time. Dispatchers will hear all combinations of voices other than their own. Listening mobile stations will hear the combination of all voices. For more information about VGCS call set up, call management and call release, refer to: Call Set Up (Section 3) Call Handling (Section 4) Call Release Procedures in Normal Service (Section 5.2) .
245 / 306
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
246 / 306
Table 32: Circuit-Switched Data Rate Conversions Across the Air Interface
247 / 306
248 / 306
HMI
249 / 306
250 / 306
251 / 306
252 / 306
7 Cell Environments
7 Cell Environments
This section describes the cell environments available in the Alcatel 900/1800 BSS.
253 / 306
7 Cell Environments
7.1 Overview
The Alcatel BSS provides coverage suited to the needs of urban, rural and coastal areas by offering a variety of possible cell environments. The BSS supports a set of cell configurations to optimize the reuse of frequencies. The operator may choose to deploy a network using both GSM 900 and GSM 1800 bands. The parameters to define cells are grouped into five types: Cell dimension. This consists of macro up to 35 km (can be up to 70 km with extended cell), and micro up to 300 meters Cell Coverage. There are four types of coverage, single, lower, upper, and indoor Cell Partition. Two types of frequency partition exist, normal or concentric Cell Range. The cell range can be normal or extended Cell Band Type. A cell belongs to either the GSM 900 or GSM 1800 bands, or both in case of a multiband cell. For cells name you can use any combination of the following characters in the Name and Location Name fields: a-z, A-Z, 0 - 9, -, _ (hyphen, underscore). Blank spaces are permitted. Use the rules fromO&M Parameters Dictionary The LAC and CI fields accept up to five numeric characters.
254 / 306
7 Cell Environments
The following figure shows various configurations of the normal GSM 900 or GSM 1800 cell type. Each of the following sections explain the functional differences between the cell described and the single cell configuration.
Sectored Site Umbrella Cell Microcell Microcell Microcell Inner Cell Outer Limit Umbrella & Concentric Cell Microcell Microcell Microcell
Extended Cell
Overlap Zone
255 / 306
7 Cell Environments
256 / 306
7 Cell Environments
Sector 1
Cell 1
Cell 3
Sector 3
Antenna
257 / 306
7 Cell Environments
35 km max
Figure 70: Example of Extended Cell Topology There are two types of extended cell, the standard and the enlarged. They are described separately.
258 / 306
7 Cell Environments
259 / 306
7 Cell Environments
260 / 306
7 Cell Environments
Pedestrian area
261 / 306
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.
262 / 306
7 Cell Environments
Rescue Handover
Note:
If the low threshold is not used, the M_to_m Threshold value must be above the high threshold value.
263 / 306
7 Cell Environments
d B m
Figure 72: Example: Handovers due to Threshold Triggering Micro-Micro Handover (Case 1) 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). Macro-Micro Handover (Case 2) A mobile station turns a corner then moves indoors. 1. Call starts at (2). The signal level is normal. 2. The mobile station signal level drops below the high threshold level (3), e.g., when turning a corner. To protect the call, it is handed over to the macrocell until a better microcell is found. The call remains with the macrocell until a strong signal from another microcell is received (normal case). 3. If a strong signal from a microcell cannot be found, a weaker signal from a microcell with enough strength to be above M_to_m threshold level, but that remains below the high threshold is found (4). In this case, as long as the signal strength remains above the low threshold and there is not a better microcell, the call remains with that microcell (e.g., the mobile station is indoors). 4. The signal level drops below the low threshold (5). The mobile station is again passed to the macrocell (e.g., the mobile station moves further inside a building). The macrocell is used to ensure call quality. 5. The mobile station moves into a position where the mobile station reports a microcell signal level above the M_to_m threshold (6). The call is handed over to that microcell, e.g., the mobile station is still indoors, but has a stronger signal from a microcell.
264 / 306
7 Cell Environments
Upper layer
Lower layer
Indoor layer
Figure 73: Indoor Cell Example Network Hierarchy with Three Layers and Two Bands
265 / 306
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.
Note:
This feature only applies to BTS A9100. Each set of TRX in a certain BTS must have its own coupling. It is possible to combine the coupling output towards the same antenna through an additional duplexer, although this is a special installation. The fact that part of the sector is in another BTS does not increase the number of necessary antennae. For BTS A9100, each BTS can have one slave, but each slave can in turn have another slave, up to a maximum of three linked slaves for one master BTS. If linked BTS support part of the same cell, the linked BTS must be clock synchronized with each other (master/slave). With this feature, the operator can associate two physical sectors from different BTS into one shared sector. This shared sector can be mono or dual-band and it can support one cell as a normal sector. It takes the identity of one of the physical sectors, called the primary sector. The other physical sector is the secondary sector.
266 / 306
7 Cell Environments
267 / 306
7 Cell Environments
268 / 306
269 / 306
8.1 Overview
To ensure that the BSS operates correctly, O&M actions are implemented at all levels within the BSS. The O&M functions in the BSS are grouped into three categories: Configuration Management The main benefit of configuration management is the reduced time needed to perform operations and reduce telecom outages. This is achieved by having fewer operator commands and providing smooth migration and equipment configuration. The main functions of configuration management include radio configuration management and equipment management. Fault Management Fault Management is used to supervise and to repair the network when anomalies occur. This is done through a sequence of steps from detection to report and recovery. These are carried out by all the BSS/MFS subsystems, and are reported to the operator at the OMC-R. Performance Management. Performance Management is used to monitor the efficiency of the system and the telecom services. It is controlled entirely from the OMC-R and provides measurements and statistics about various traffic events and resource use in the BSS.
270 / 306
271 / 306
272 / 306
273 / 306
274 / 306
HMI Server
X.25 Network
OMCR Host n
Figure 74: Multiple HMI Access to OMC-Rs The implementation of this feature takes advantage of the distributed configuration of the OMC-R which usually consists of a host machine and distinct local or remote HMI servers.
275 / 306
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.
8.3.2 ACO
Alarm Call Out (ACO) is a process within the HMI server to perform alarm management tasks for a complete network. Alarms from the BSSs controlled by other OMC-Rs are directed to one OMC-R. These links are used to transfer alarm notifications from the controlled OMC-Rs to the ACO OMC-R as shown in the figure below. The ACO OMC-R collects alarms from these OMC-Rs, applies filters defined by the on-duty operator, sends the filtered results to a dedicated printer and sends e-mail to support technicians. ACO can be started and stopped from any OMC-R.
ACO OMCR Workstation
OMCR 3
OMCR 1
Area 3
Area 1
OMCR 2
Area 2
ACO : Alarm Call Out
276 / 306
OSI CPRA 2
: Common Management Information Service Element : Common Processor Type A : File Transfer Access and Management : High Speed Interface : Open System Interconnection
Figure 76: X.25 Without Redundancy Definition of the primary and the secondary links based on their hardware configuration can achieve various types of redundancy, such as: OMC-R-side redundancy BSC-side redundancy Complete redundancy. The following figure illustrates these redundancy types.
OMCR X.25 Network HSI Board 0 1 2 3 3 1 2 OSI CPRA 2 Secondary Link BSC Primary Link OSI CPRA 1
Secondary Link Configurations 1. OMCR side redundancy 2. BSC side redundancy 3. Complete redundancy
277 / 306
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.
278 / 306
279 / 306
280 / 306
8.4.5 Auto-Identification
Auto-Identification gives the BTS A9100 and the BTS A9110 the capacity to recognize their own hardware configuration, and to provide this information to the OMU and the BTS Terminal. The auto-identification procedure is triggered by the OMU in the following situations: BTS/SUM power up BTS reset OMU reset/auto reset Module initialization (on maintenance operator command, or during a Local Recovery Action or Hardware Extension, the auto identification takes place only for the module(s) concerned by the operation). The BTS A9100 and the BTS A9110 capabilities received by the OMU at auto-identification are stored and can be used internally by the OMU software or sent to the BSC at Hardware audit.
281 / 306
282 / 306
283 / 306
284 / 306
BSC Fault detection, fault correlation and fault localization on all devices controlled by the processor BSC reconfiguration in case of loss of the BCCH, Terminal Control Unit/FU or a Carrier Unit (G1 or G2 BTS) BSC reconfiguration in case of loss of the BCCH, TCU/TRE (BTS A9100/A9110). Through the TSC, the BSC also performs the following functions: Monitors the status of the Transcoder, SM and BIE modules Provides local access to configure the Transcoder, SM and BIE modules via an RS-232 connection to the BSC terminal Gives access to the fault localizing features of the TSC (for example, the ability to set up loop-back tests).
285 / 306
BTS Testing the equipment. This includes collecting alarms and reporting to the BSC. Fault detection, fault correlation and fault localization for the BTS Management of equipment states. This includes triggering BTS channel configuration in case of a failure. Provides access for local diagnostics and configuration of the BTS BTS power supply control Event report management. See Alarm Generation (Section 8.5.1) for further information concerning events.
MFS
MFS Collects all fault information for telecom and external alarms, the telecommunications hardware and the active server Records the fault information in a table Allows the IMT and the OMC-R access to the fault information Generates the ending alarm for pending alarms Manages the communications with the IMT.
Table 35: Fault Management Functions For additional information about fault management, refer to the descriptive documentation and Fault Management in the Operations & Maintenance Principles document.
286 / 306
8.5.2.1 Correlation
Correlation refers to the collection and analysis of all available fault indications for a particular problem. Fault correlation is performed to define where and why the fault occurred. An example of correlation is described below: 1. When several boards in the BTS report clock problems, these reports are correlated by the OMU. 2. The clock generator is faulty alarm is sent to the OMC-R via the BSC.
8.5.2.2 Filtering
Alarms are filtered to minimize the number of fault alarms reported and displayed to the operator and are displayed in order of severity. Refer also to Alarm Handling in the Operations & Maintenance Principles document. To reduce the number of alarms in the OMC-R, short end alarms are filtered. For these alarms a BEGIN is raised soon after the previous END. These END /BEGINs are not considered significant and are filtered. The operator sees fewer alarms and is informed that alarms are filtered, because the number of filtered alarms, if any, is indicated in AS.
287 / 306
8.5.2.3 Persistency
A fault is signaled only if there is no recovery after the timer expires. For example, for a LAPD failure of an RSL link, an alarm is only sent if the LAPD link has not recovered before the persistency timer has expired.
288 / 306
289 / 306
Note:
The BTS_TEL SBL describes the status of the GSM-defined BTS telecom functions. Its state is defined by operator commands, and correlation of the LAPD RSL states or of the different Carrier Units.
Fault Start RSL1 Persistency Correlation CPR Informed RSL State Change Alarm begin BTS_TEL ACTIVE INACTIVE Fault Start RSL2
CPR RSL
290 / 306
Note:
291 / 306
292 / 306
293 / 306
294 / 306
295 / 306
Note:
In the BTS A9100 or the BTS A9110, the SBLs FU and Carrier Unit have been merged into one indivisible SBL, called the TRE. At the BSC, however, all BTS A9100 and BTS A9110 TRE faults are mapped to the Carrier Unit to provide compatibility with G1 and G2 BTS. 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 BTS continue to be reported as such.
296 / 306
297 / 306
The following figure shows the redundancy process for a failed Carrier Unit with BCCH.
OMC BSC
BTS_TEL=IT
Resources blocked, BCCH reconfiguration possible
req ( Reco_ CU, F OS)
BTS
CU Fault
BTS_TEL=FIT
m( Alar
cell,
loss
of
gin) H be 4 BCC
BTS_C
ONF_
DATA
BTS_TEL=FIT
(2)
6 8
of BC CH en d)
BTS_C
SYS_IN
FO (1..6
Alarm
ss (cell, lo
9
gin)
Ala
ll, lo rm (ce
ss of T
CH be
BTS_TEL=FIT
BCCH CU TCH
Note:
The BTS_TEL SBL describes the status of the GSM-defined BTS telecom functions. Its state is driven by operator commands, or by correlation of the LAPD RSL states or of the different Carrier Units.
298 / 306
Note:
For performance reasons, each alerter type has a maximum limit of 16 alarms. For more information about BSC Alerters, refer to BSC Alerters in the Operations & Maintenance Principles document.
299 / 306
8.6.1 Traces
Trace management coordinates and triggers trace activities within the BSS. Tracing is originated from the MSC. There are two types of tracing: Call tracing IMSI tracing. Call tracing follows a specified transaction (subscriber call, location update, short message, etc.) inside the BSC. When the specified transaction ends, or the transaction changes to another BSC, the trace activity ends. IMSI tracing is not restricted to speech. It includes information about the radio resources set up for the mobile. This includes, for example, location updating, supplementary services, short messages, etc. For more information on trace management, refer to Trace Management in the Operations & Maintenance Principles document.
300 / 306
301 / 306
During the observation period, the BTS/FU keeps track of all the RMS statistics derived from the measurements reported by the mobile stations or measured by the BTS/FU itself on the TCH (SDCCH are not used with RMS). At the end of the observation period when the RMS data has been collected from the concerned BTS/FUs, the BSC builds a report (called the RMS result file). The transfer towards the OMC-R occurs via FTAM. In addition, it is possible during the observation period to apply MAFA (also called Extended Measurement Reporting). This procedure consists of sending an Extended Measurement Order (EMO) to the mobile stations. On receipt of the command, the mobile stations take one SACCH multiframe to perform measurements on specific frequencies. The measurements are reported via the EXTENDED_MEASUREMENT_REPORT message. The EMO is sent only once per call. The statistics related to MAFA are collected in the BTS and integrated in the RMS results. The statistics are based on the measurements performed at the BTS and the mobile station, on the TCH only. The statistics can be classified as follows: Radio related statistics. These can be classified as follows: Statistics related to the whole serving cell Statistics related to the TRXs. Voice quality statistics. Nine counters and indicators provide an overview of the communications quality (TCH only) for each TRX.
302 / 306
To allow operators to obtain information on BTS output power on a TRX basis, a new counter is implemented. This counter retrieves the GMSK TRX power level applied at the BTS antenna output connector in dBm. This counter reports on the BTS_MAX_OUTPUT_POWER variable, used for power control and path balance statistics. These RMS improvements help the operator to: Optimize speech quality using AMR Optimize network planning, through identification of resurgences and hot spots.
303 / 306
8.7 Audits
Audits can be automatic or initiated by an operator. They can be performed at several levels: From the OMC-R to the Transcoder, the BSC, or the MFS From the BSC to the BTS. More information on Audits can be found in the Operations & Maintenance Principles document. as follows: Configuration Management Audits in Configuration Management Audits/Resynchronization Fault Management Audits in Fault Management Audits . Using the IMT, it is possible to perform a radio re-initialization, or a radio resynchronization of the MFS.
Hardware Audit
Alarm Audit
State Audit
304 / 306
Two types of action are possible for the MFS: Re-initialize GPRS configuration Allows the OMC-R to force the logical configuration of the MFS, by deleting the current one, and then recreating one from scratch, using the current OMC-R configuration. This is roughly the equivalent of a Force configuration at the BSS side. However, it always induces some outages Resynchronize GPRS configuration. Allows the OMC-R to force the logical configuration of the MFS, by computing the differences with the current OMC-R configuration. It is the preferred synchronization action at the MFS side, as it minimizes the MFS outage. A suite of audits is automatically invoked by the OMC-R or the BSC to resynchronize the system. This is done: To perform a RESET/RESTART When there is a loss of links between subsystems. This ensures that the system databases are synchronized after autonomous operation while the link was down (i.e., the BTS_O&M was disabled). To make changes in the databases, without the possibility of aligning both subsystems To start a BSC Alarms-in-Force audit if the BSC alarm queue overflows To perform software database replacement. Audit information for the whole system is stored in the OMC-R.
305 / 306
306 / 306