O & M Handbook on 2G-3G Radio Networks ZTE TECHNOLOGY - 2016
(Version 2016.05-1.0) BSNL
O&M Handbook on ZTE Radio Technologies[Type text] O&M Handbook on ZTE Radio Technologies
Page 0
Message
AnupamShrivastava Chairman and Managing Director BSNL Board
I am happy to note that Consumer Mobility vertical has taken an initiative to provide a comprehensive, OEM technology wise, ‘Operations & Maintenance Handbook’ for routine operation and maintenance. In this series, this handbook on ZTE Technology will be extremely beneficial for use by our Technicians and Engineers in all 26 Telecom Circles and Telecom Districts. I feel that such a Ready compilation of day to day O & M activities, at one place will go a long way in helping our field units to learn from good practices being followed in other circles. I congratulate Director (CM) Shri R. K. Mittal and his team for this great initiative and efforts. I am looking forward for release of such O&M Handbooks for other technologies.
03.06.2016
O&M Handbook on ZTE Radio Technologies
(Anupam Shrivastava)
Page 1
Message
R. K. Mittal Director (CM) BSNL Board
I am very glad to see that the Handbook on CMTS Operation and Maintenance for ZTE technology has been made first time in BSNL. Availability of this comprehensive Handbook with the field engineers and technicians for carrying out day to day operation and maintenance activities is of paramount importance. I am sure that this Handbook will help and encourage operation and maintenance personals for constant monitoring and taking immediate remedial actions through OMC-R & OMC-S for improving QoS parameters. This Handbook will help to solve problems related to: handover issues; call drop issues; SDCCH/TCH congestion; SDCCH/TCH blocking; VSWR issues; call setup success rate; etc. Basic guidelines also on conducting Drive Test, Optimization, etc. has been provided for field personal who will immediately be able to start drive testing and RF optimization activities. This Handbook is only the beginning and suggestions for improvement may be sent by email to
[email protected] I thank Shri G S Thakur AddlGM PB Circle and other officers of North Zone Circles for their hard work and sincere efforts to bring out this much desired Handbook. I also thank Shri Shyam Narain, Dr S K Samanta, Shri Kishore Bhagtani, and other officers of BSNL CO for their valuable contribution.
03.06.2016
O&M Handbook on ZTE Radio Technologies
(R. K. Mittal)
Page 2
Preface A comprehensive handbook for O&M activities to be undertaken by the field engineers and technicians is one of the most critical pieces of document and is required in hand for smooth maintenance as well as speedy resolution of various issues. There has always been a need of one comprehensive book for resolving most of the day to day issues faced by network engineers and technicians in the field. This handbook is a result of an idea initiated by Shri R K Mittal, DIR (CM) BSNL Board and translated by teams of experienced officers of various levels both at BSNL Corporate Office and in the Circles. The final version is scrutinized by Dr. S K Samanta Addl.GM (NWO-CM) and Shri. Kishore Bhagtani DGM (NWO-CM) BSNL Corporate Office under the guidance of Sr.GM (NWOCM) BSNL CO and Dir. (CM) BSNL Board. This handbook has been developed for basic and most important guidelines for Operation and Maintenance of GSM and UMTS networks of ZTE technology deployed in BSNL in all zones. This O & M handbook provides a brief overview of 2G/3G BSS/RAN network elements, their functioning and alarm conditions, maintenance task schedules, KPI report generation, monitoring and optimization techniques. Brief guidelines on office documentation and site record maintenance have also been provided to cover the entire work profile of a radio engineer. This Handbook will not only help the existing officers, engineers and technicians in SSAs and circle offices, but will be very much useful to those new personnel, who will be posted for day to day operation and maintenance activities for CMTS networks of ZTE Technologies in the coming days.
O&M Handbook on ZTE Radio Technologies
Page 3
Acknowledgements Following officers of North Zone actively contributed for the preparation of this handbook under the guidance of Shri G S Thakur, Addl. GM (NWO-CM) PB Circle
HRCircle 1. 2. 3.
Sh. S.C.Badal, DGM (NWP-CM) Ambala E-Mail:
[email protected] , Ph.: 9416900079 Sh. Janak Sharma, DGM (NWO-CM) Ambala E-mail:
[email protected] , Ph.: 9416010059 Sh. Arvind Kumar, JTO (MSC) Ambala E-mail:
[email protected] , Ph.: 9416019900 Special thanks to Sh. R. C. Arya, CGMT Haryana and Smt. Alpana Aggarwal, Sr.GM(CM) Haryana, who provided the necessary resources for preparation of this handbook.
1.
HP Circle Sh. Mohan Lal, DGM (NWO-CM) Shimla E-mail:
[email protected] ,Ph.: 9418022800 UP-E Circle 1. Sh. V.S.Kushwaha, Addl. GM (NWP-CM) Lucknow E-mail:
[email protected] , Ph.: 9415100800 M/s ZTE Sh. Dinesh Paliwal and Sh. Ajaytaj Singh of M/s ZTE have provided valuable technical inputs and assistance in preparation of this handbook.
O&M Handbook on ZTE Radio Technologies
Page 4
TABLE OF CONTENTS ____________________________________________________________________________________ 1. CHAPTER-1 MOBILE NETWORK OVERVIEW 1.1 Brief Technical Introduction 1.2 Regulations & Guidelines 1.3 List of Documents to be Maintained at SSA/Circle Level 1.4 Site Information Display And Record keeping 1.5 Daily Routine Works at Office 1.6 Requirement of Tools for Site Maintenance 1.7 BTS/Node B Daily, Weekly, Monthly, Quarterly And Annual Maintenance task schedules 1.8 BSC and RNC Maintenance –Daily /Weekly/Monthly/ Yearly Maintenance Task Schedules. 1.9 Sample Site Visit Check List 2. CHAPTER-2 OMCR-NETNUMEN 2.1 Introduction 2.2 Accessing OMCR 2.3 Functionalities available in Netnumen 2.3.1 Fault Management 2.3.2 Performance Management 2.3.3 Configuration Management 31 2.3.4 Maintenance Management 2.3.5 Security Management 33 2.4 Broad OMCR-Daily, Weekly and Monthly Maintenance Tasks
10 12 17 18 19 19 20 24 28 29 29 30 30 31
33
34
3. CHAPETER-3 BTS/NODE B OVERVIEW 3.1 BTS Introduction 3.2 BTS Cabinet Structure 3.3 Node B Hardware 3.4 Functions of BTS Cards
35 36 37 37
4. CHAPTER-4 BTS/NODE B OPERATION AND MAINTENANCE 4.1 Introduction 4.2 Routine Functions Carried for BTS O&M 4.2.1 Checking Active Alarm in the BTS 4.2.2 Checking BTS CARD Status Visually 4.2.3 Resetting the Cards 4.2.4 Diagnosis the BTS Cards 4.2.5 Modifying the configuration of the BTS 4.2.6 Re-Loading the software in BTS 4.2.7 Loading of MO file in the BTS
44 44 44 45 46 46 47 48 49
5. CHAPTER-5 BSC HARDWARE DESCRIPTION 5.1 Introduction 5.2 Hardware Architecture 5.3 Board Description
51 51 52
5.4
Shelf Overview 5.4.1 Shelf Functions 5.4.2 Shelf Classification 5.4.3 Shelf Position
O&M Handbook on ZTE Radio Technologies
59 59 59 60
Page 5
5.4.4 5.4.5
Shelf Description(for Resource Shelf) Shelf Description(for GB Resource shelf)
61 68
6. CHAPTER-6 ZTE BSC (ZXG10) OPERATION AND MAINTENACE 6.1 Overview 6.2 Classification of Maintenance Activities 6.3 Daily Maintenance 6.3.1 Equipment Room Environment Check 6.3.2 BSC Running status check 6.3.2.1 Checking Board Indicator 6.3.2.2 Checking NE-NMS communication link 6.3.2.3 Querying BSC ’s current alarms 6.3.2.4 Querying the past 24-hour history alarms 6.3.2.5 Querying KPIs of BSC 6.3.2.6 Checking A-interface status 6.3.2.7 Checking Gb interface status 6.3.2.8 Checking Abis interface status 6.3.2.9 Checking board’s active/standby status 6.3.2.10 Querying BSC Operation Log 6.3.2.11 Checking Alarm Box 6.4 Weekly Maintenance 6.4.1 Cleaning Equipment 6.4.2 Checking BSC Clock Status 6.4.3 Checking OMP/OMP2/CMP/CMP2 6.4.4 Querying BSC Alarms Real-Time Statistics 6.4.5 Analyzing History Alarms of the Past Week 6.4.6 Analyzing Performance Indices 6.4.7 Checking Server Running Status 6.4.8 Checking Occupied Space of Database at NM Server 6.4.9 Configuration Data Backup 6.4.10 Virus Scanning 100 6.5 Monthly Maintenance 6.5.1 Checking Board Software Version 6.5.2 Checking Clock Synchronization 6.5.3 Checking Automatic Backup Clearing Function 6.5.4 Updating Operating System Patch 6.5.5 Checking Optical Interface Protective Cap 6.6 Quarterly Maintenance 6.6.1 Checking Power Supply 6.6.2 Checking Cable Connections 6.6.3 Checking Fan Plug-in Box Working Condition 6.6.4 Checking Anti-Static Wrist Strap 6.6.5 Checking Spare Materials and Parts 6.6.6 Checking Grounding Conditions 6.6.7 Cleaning Air Filter
100 100 102 103 104 104 104 104 104 105 105 105 105 106
7. CHAPTER-7 RNC HARDWARE 7.1 RNC H/W Overview 7.2 Cabinet 7.2.1 Cabinet Types 7.2.2 Cabinet Structure 7.2.3 Rack 7.2.4 Sub-Rack 7.3 Shelf 7.3.1 Shelf Configuration 7.3.2 Control Shelf 7.3.3 Switching Shelf 7.3.4 Resource Shelf
107 108 108 108 109 109 110 110 111 112 113
O&M Handbook on ZTE Radio Technologies
75 75 76 76 76 76 77 77 81 84 86 87 88 89 90 92 93 93 93 94 94 95 97 97 98 99
Page 6
7.4
7.5 7.6 7.7
Board 7.4.1 Board Definition 7.4.2 Board Classification 7.4.3 Board Structure 7.4.4 Board Indicator 7.4.5 Front Boards 7.4.6 Rear Boards Backplane Cable Accessories
8. CHAPTER-8 ZTE RNC(ZXWR) EMERGENCY MAINTENANCE 8.1 Overview 8.1.1 Basic Principles of Emergency Maintenance 8.2 Emergency Maintenance Flow 8.2.1 Flow of Emergency Maintenance 8.2.2 Checking Services 8.2.3 Fault Records 8.2.4 Initial Location and Analysis of Fault Causes 8.2.5 Service recovery 8.2.6 Service Observation 8.3 Emergency Maintenance on Abnormal Services 8.3.1 Handling Service Interruption Caused by Board Abnormality 8.3.2 Handling Service Interruption Caused byTransmission Abnormality 8.3.2.1 Methods for Handling Transmission Alarms 8.3.2.2 Causes for transmission Alarms 8.3.3 Analyzing RNC Fault Coverage 8.3.4 Handling RNC Service Abnormality and Interruption 8.3.4.1 Handling Iu Interface Faults 8.3.4.2 Handling Clock System Faults 8.3.4.3 Handling Call Failures 8.3.4.4 Handling mute Calls 8.3.4.5 Handling Download and Webpage Access Failures after Activating PS Services 8.3.5 Handling Node B Service Abnormality and Interruption 8.3.5.1 Handling Large-Scale Cell Outages 8.3.5.2 Handling Absence of Cell Signals and Low Success Rate of RRC Establishments 8.3.6 Handling OMM/NetNumen U31 Abnormality/Interruption 8.3.7 Handling Overload 8.4 Data Backup and Recovery
115 115 115 115 116 116 130 135 139 139 143 143 144 144 145 145 146 146 147 147 147 148 150 150 151 152 152 153 154 155 157 158 158 158 159 160 162
9. CHAPTER-9 RF OPTIMIZATION 9.1 Optimization and Drive Test 9.2 Need for Optimization 9.3 Optimization process inputs 9.4 Optimization Process 9.4.1 Statistical Analysis 9.4.2 Drive Testing 9.4.3 OMC Tools 9.4.4 Site Visit 9.5 Optimization Solutions 9.6 Frequency Planning for 2G BTSs 9.6.1 Frequency Channel Allocation 9.6.2 BSIC Planning 9.6.3 Frequency Band Allotted To BSNL
163 163 164 165 165 167 173 174 174 176 176 177 179
10. CHAPTER-11 2G NETWORK KPI OPTIMIZATION 10.1 Introduction
180
O&M Handbook on ZTE Radio Technologies
Page 7
10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10
SDCCH Congestion and Solutions SDCCH Assignment Analysis TCH Assignment Failure and Solutions TCH Call Drop and Solutions Handover Problems and Solutions Paging Problems and Solutions Interference and Solutions Coverage Problem and Solution Data KPI Improvement
180 181 182 183 184 185 187 189 189
11. CHAPTER-11 3G NETWORK KPI OPTIMIZATION 11.1 Overview 11.2 KPI Monitoring Process 11.3 KPI Analysis Methods 11.4 KPI Optimization Analysis 11.4.1 CS Call Drop Optimization 11.4.2 PS Call Drop Optimization 11.4.3 Optimization of Accessibility Indicators 11.4.3.1 Definition of Access Failure 11.4.3.2 Analysis on RRC Connection Failures 11.4.3.3 Analysis on RAB/RB Setup Failures 11.5 Practical Scenarios of KPI Improvements 11.5.1 Call Setup Failure Scenarios 11.5.2 Call Drop Scenarios 11.5.3 KPI Definitions 11.5.4 AMR CS Call Phases 11.5.5 Call Setup Failure Analysis 11.5.5.1 Call setup Failures-Missing Neighbour 11.5.5.2 Call setup Failure Analysis-Block B 11.5.5.3 Call Setup Failure-System issue BTS-C 11.5.5.4 Call setup Failure Analysis-C 11.5.5.5 Call Failure Analysis-D 11.5.5.6 Call Failures-System Issue RNC-D 11.5.6 Low in CSSR 11.5.6.1 Call setup Success Rate (CSSR) 11.5.6.2 RRC Connection Set Up Failure 11.5.6.3 Call Setup Failures 11.5.7 Call Drop Analysis Process 11.5.7.1 Drop Call Analysis Process- SHO Analysis 11.5.7.2 Drop Call Failures – RF issue 11.5.7.3 Drop Call Failures Scrambling Code Conflict 11.5.7.4 Drop Call Failure – System Issue RNC or BTS 11.5.8 3G Node-B Optimization / Tuning Guide
191 192 196 202 202 204 204 205 206 210 214 215 215 216 216 217 217 217 219 219 220 221 221 221 222 223 224 224 224 224 224 225
12. CHAPTER- 11 ZTE NEC-iPasolink 200 MINI LINK INSTALLATION 12.1 Introduction 12.2 ODU Interface 12.3 IDU Interface 12.4 Installation Modes for ODU 12.5 Change the Polarization of Antenna 12.6 ODU Installation 12.6.1 ODU Grounding Cable Installation 12.6.2 IF Cable Installation 12.6.3 Grounding IF Cable 12.7 Indoor Unit Installation 12.7.1 Installing the Rack 12.7.2 IDU Installation 12.7.3 Power Cable 12.7.4 IDU Grounding
228 228 229 230 230 231 234 235 237 239 239 240 240 241
O&M Handbook on ZTE Radio Technologies
Page 8
12.7.5 E1 Cable connection for 120 ohm Unbalance interface 12.7.6 Labeling
242 244
13. Appendix – A Frequently Asked Questions
245
14. Appendix – B Daily Health Check-up Tasks in BSC/RNC
252
Chapter 1 Mobile Network Overview ____________________________________________________ 1.1.
Brief Technical Introduction
A mobile network consists of: a) a access part - Base Station Subsystem (BSS); and b) a core part Network Subsystem (NSS). BSS Networks consists of: Base Transceiver Stations (BTS) and Base Station Controller (BSC). NSS Networks consists of: Mobile Switching Centre (MSC), Home Location Register (HLR), Visitor Location Register (VLR), IN and Billing & Customer Care Systems (B&CCS).
BSS Networks
O&M Handbook on ZTE Radio Technologies
Page 9
The main components of BSS networks consists of two parts: i) Radio - BTS, BTS-BSC links, BSC and ii) Infra - Tower, Diesel Generator (DG), Air Conditioners (AC) or Free Cooling System (FCS), -48 Volt Battery and Power Plant. BTS to BSC links are either provided through OFC networks (i.e. CPE, ADM. MADM, LAN Switches , Routers etc) or through Digital Microwave (i.e. Mini Link).
Schematic Diagram of a BSS Base Transceiver Stations (BTS): BTS or access nodes provides connection to a user through a wireless local loop, with authorisation for access and call managed by HLR, VLR, IN and B&CCS. The wireless loop is only used when a call is in progress and is shared among the BTS users served in a geographical area; this typically covers a radius up to 20km (if there is no obstruction e.g tall buildings) but in dense urban area coverage is 0.5 to 1.0 km and in Rural areas upto 5 km. The traffic from several BTS’s is multiplexed at the Base Station Controller (BSC) which relays to the Mobile Switching Centre (MSC) thus providing the connection between users. A BTS is designed according to: minutes of call, number of messages and amount of Data to be provided in a specific time period. Assuming a BTS is designed to handle 1000 minutes of calls per hour, it could provide 200 users with 5 minutes or alternatively 500 users with 2 minutes of calls. It is clear there can be more users if the call duration is less. This is not the case in a wire line network where a dedicated connection from the access node is provided for each user. This characteristic of mobile networks suggests a different strategy be folowed in providing desired Quality of Services (QoS) to Mobile users. A successful call/connection uses two links for transport of information: 1) originating links: and 2) terminating links. When both the links of a call are provided by the same BTS it is defined as intra BTS call otherwise it is called inter BTS call. Both the intra BTS and inter BTS call passes through BSC and is switched at MSC. When a call is terminated in a network managed by a different operator it is routed via a Gateway MSC (GMSC). Authorisation for access to the mobile network to a user is done by allocating a unique mobile number against the subscribers’ Service Identity Module (SIM) and creating a matching data base in the HLR. The Mobile Equipment (ME) with the SIM inserted in it is generally called the Mobile Station (MS) and communicates to HLR through BTS, BSC and MSC to get access to the network. Components such as the BTS, BSC and their interconnections are used for the transport of all services, whereas components like MSC and links between BSC-MSC and MSC-GMSC are only used for voice and low speed Data such as the Short Message Service (SMS). For message services like SMS and Multimedia Message Services (MMS) additional nodes such as Short Message Service Centre (SMSC) and Multimedia Message Service Centre (MMSC) are used to store and forward the message. Traffic such as a voice call is carried through a Traffic Channel (TCH) which transports information usually measured in kbps (kilo bits per second). For a full rate voice call each TCH carries 12.2 kbps whereas the Data rate per TCH can be up to 59.2 kbps depending on the modulation scheme and technology e.g. GPRS or EDGE. A BTS configured with 4 carriers per sector i.e. total 96 channels is generally connected to a BSC with a 2 Mbps (Millions of bits per second) link i.e. 1E1. This 2Mbps is not sufficient for high Data usage customers in urban areas and therefore 2 nos of 2Mbps links i.e. 2E1 per BTS to BSC is required.
O&M Handbook on ZTE Radio Technologies
Page 10
Smart Phone users heavily uses Data services such as e-mail, browsing, download and audio/video streaming and these services do not use elements such as the MSC and BSC-MSC links. Technologies such as General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), third Generation (3G) and forth Generation (4G) are generally employed for these Data services. It uses Packet Handling Nodes (PHN) such as Packet Controller Units (PCU), Serving GPRS Support Nodes (SGSN), Gateway GPRS Support Nodes (GGSN) and Routers in place of MSCs. The resources of BTS, BSC and interconnected links are used to update the location by each active mobile set even in the idle state. The volume of such traffic is small but adequate no of communication channels need to be defined. The authorisation to access a mobile network is controlled by elements such as the HLR, the Authentication Centre (AuC), the Equipment Identity Register (EIR), the VLR and IN/B&CCS. HLR, AuC and EIR is normally configured in the same hardware and in general there are two systems (1 + 1) for each geographical area ( circle ) for redundancy purposes. An HLR can provide access to the tune of 10.0 million subscribers and can be connected to more than one MSC. Each MSC is paired with a VLR which temporarily stores the data for the customers who visits the area under the radio coverage of the BTSs connected to the MSC. The staff of BSNL is expected to be well familiar with operational and maintenance issues of the 2G/3G networks. This includes important routine works, Logs and records maintenance for BSS /RNS network elements and other works to be carried out by O&M personnel. All field engineers/technicians are expected to meet organizational process requirement and service QOS obligations set by TRAI/TERM Cell/DoT.A list is provided to meet this requirement; field engineers need to be aware of all possible aspects of O&M works. Major Aspects of O&M Work Guidelines and regulations Types of documentation in organization and importance of the same Report generation, availability and Records to be maintained Knowledge of KPIs, Alarms, Faults, Test Points/Parameters. Escalation matrix for reporting identified incidents, troubles and/ or emergencies e.g. system failures ,fire and power failures Knowledge of spare management and repair & return process for faulty Equipment –AMC Safety Measures at Work Place 1.2.
Regulations and Guidelines TRAI Guidelines for Voice and Data Services
Voice Services 1. Regulation 20march 2009 - regulation 2. 3G-voice-for-finalisation 07. 05. 2012 – Amendment for 3g Services 3. 3. Final modified_regulations_8.11.12 – On penalty for not meeting Regualtion limits 4. Regl 12 of 2014 English --------- Amendment – Modification in parmeter and Benchmark 5. Regulation_8of2015 – On Penalty Data Services 1. Wireless Data Service Regulation 2012
1.2.1 TRAI Guidelines for 2G Voice services
O&M Handbook on ZTE Radio Technologies
Page 11
2G Voice
THE STANDARDS OF QUALITY OF SERVICE OF BASIC TELEPHONE SERVICE (WIRELINE) AND CELLULAR MOBILE TELEPHONE SERVICE REGULATIONS, 2009 (20 March 2009)
Quality of Service parameters in respect of which compliance reports are to be submitted to the Authority Serial Number A (i)
Name of Parameter
Benchmark
Averaged over a period
Network Service Quality Parameters: Network Availability a) BTSs Accumulated downtime (not available for service)
≤ 2%
One Month
(b) Worst affected BTSs due to downtime
≤ 2%
One Month
(a) Call Set-up Success Rate (within licensee’s own network)
≥95%
One Month
b) SDCCH/ Paging Channel Congestion
≤ 1%
One Month
is the TCH Congestion
≤ 2%
One Month
(a) Call Drop Rate
≤ 2%
One Month
(b) Worst affected cells having more than 3% TCH drop (call drop) rate
≤ 3%
One Month
is the connections with good voice quality
≥95%
One Month
(iv)
Point of Interconnection Congestion ( on individual POI)
≤ 0.5 %
One Month
B
Customer Service Quality Parameters:
(v)
Metering and billing credibility – post paid
Not more than 0.1% of bills issued should be disputed over a billing cycle
One Billing Cycle
(vi)
Metering and billing credibility –pre-paid
Not more than 1 complaint per 1000 customers i.e. 0.1% complaints for metering, charging, credit, and validity
One Quarter
(vii)
(a) Resolution of billing/ charging complaints
≥ 98% in 4 Weeks and 100% within 6 Week
One Quarter
(ii)
(iii)
Remarks
Connection Establishment (Accessibility)
Connection Maintenance (Retainability)
(POI)
O&M Handbook on ZTE Radio Technologies
Amendment 21 Aug 2014 : Previously 100% within 4 weeks
Page 12
(b) Period of applying credit/ waiver/ adjustment to customer’s account from the date of resolution of complaints
within 1 week of resolution of complaint
One Quarter
≥ 95%
One Quarter
(b)Percentage of calls answered by the operators (voice to voice) within 90 seconds
≥95%
One Quarter
(ix)
Termination/ closure of service
≤ 7 days
One Quarter
(x)
Time taken for refund of deposits after closures
100% within 60 days
One Quarter
(viii)
Response Time to the customer for assistance (a) Accessibility of call center/ customer care
Amendment 21 Aug 2014 : Previously 60 Sec and ≥90%
Quality of Service parameter in respect of which compliance is to be monitored by the service provider 1
Service Coverage
For In-door coverage the signal strength at street level shall be ≥ -75 dBm and In-vehicle shall be ≥ -85 dBm.
1.2.2 TRAI Guidelines For 3G Voice services
1.2.2 TRAI Guidelines For 3G Voice services
3G Voice
1
THE STANDARDS OF QUALITY OF SERVICE OF BASIC TELEPHONE SERVICE (WIRELINE) AND CELLULAR MOBILE TELEPHONE SERVICE (AMENDMENT) REGULATIONS, 2012 (07May 2012) Amendments to 2G QoS Parameters Node Bs Accumulated downtime (not available for Same as 2G methodology and Benchmark service):
2
Worst affected BTSs and Node Bs due to downtime
3
Call Set-up Success Rate
Same as 2G methodology and Benchmark This parameter is same for 2G Networks as well as 3G Networks. However, the network elements involved in both the networks are different. Call Set-up Success Rate is defined as the ratio of Established Calls to Call Attempts. For establishing a call in 3G Networks, User Equipment (UE) accesses the Universal Terrestrial Radio Access Network (UTRAN) and establishes an RRC connection. Once RRC connection is established the Non Access Stratum (NAS) messages are exchanged between the UE and the Core Network (CN). The last step of the call setup is the establishment of a Radio Access Bearer (RAB) between the CN and the UE. However, any RAB abnormal release after RAB Assignment Response or Alerting/Connect message is
O&M Handbook on ZTE Radio Technologies
Page 13
to be considered as a dropped call.
4
SDCCH/Paging Channel and RRC Congestion:
This is same as signaling channel congestion in 2G Networks. The existing parameter provides for assessment of the SDCCH congestion in GSM network and Paging Channel congestion in CDMA network. This parameter has been amended to include RRC Congestion in 3G Networks.
5
TCH and Circuit Switched RAB Congestion
Circuit Switched RAB congestion is similar to Traffic Channel Congestion.
6
Call Drop and Circuit Switched Voice Drop Rate
RAB abnormal release after RAB Assignment Response or Alerting/Connect message is to be considered as a dropped call.
7
Worst affected cells having more than 3% TCH drop (call drop) and Circuit Switched Voice Drop Rate:
Worst affected having more than 3% CSV Drop Rate
1.2.3
cells
TRAI Quality of Service parameters for wireless data services
1.2.3 TRAI Quality of Service parameters for wireless data services Serial Number
Name of Parameter
3.1
Service /Provisioning
3.2
Successful data download attempts
transmission
3.3
Successful data upload attempts
transmission
Activation
Benchmarks
Averaged over a period
Within 4 hrs. with 95% success rate.
One Month
>80%
One Month
>75%
One Month
O&M Handbook on ZTE Radio Technologies
Page 14
3.4
Minimum download speed
3.5
Average Packet data
3.6
Latency
3.7
PDP Context Success Rate
3.8
Drop rate
Throughput
To be measured for each plan bythe service provider and reported to TRAI for
>75% of the subscribed speed. Data View Current Alarms, as shown in . Figure 6.1 Querying Current Alarms
O&M Handbook on ZTE Radio Technologies
Page 78
2. Current Alarm Query Conditions tab appears, as shown in Figure 6.2. Figure 6.2 Current Alarm Query Conditions Tab
3. In the Current Alarm Query Conditions tab, click in the toolbar, Query Current Alarm dialog box pops up, as shown in Figure 6.3. 3-8 Figure 6.3 Query Current Alarm Dialog Box
O&M Handbook on ZTE Radio Technologies
Page 79
4. Select query conditions according to actual requirement, and click OK. The system starts the current alarm query and displays the query result in the View Current Alarms tab, as shown in Figure 6.4. Figure 6.4 Current Alarm Query Result
Abnormality Handling Perform the following operations to handle abnormalities. 1. In the View Current Alarms tab, double-click an alarm or right-click an alarm, and click Detailsin the pop-up menu, as shown in Figure 6.5. Figure 6.5
O&M Handbook on ZTE Radio Technologies
Page 80
2. In the Details dialog box, select the Details tab to view detailed information of the alarm, as shown in Figure 6.6. User can click buttons on the right (Pre, Next, Acknowledge, Unacknowledged, Clear, Forward, Comment) to perform corresponding operations. In the Maintenance Suggestion tab, user can customize the maintenance suggestion and save it. Figure 6.6 Details Of Current Alarm
3-13 6.3.2.4 Querying BSC’s past 24-Hour History Alarms Background Knowledge The newly-generated alarm information exists in the form of current alarm. If user performs the clearing operation, the current alarm becomes history alarm. Operation Guide Perform the following steps to query the past 24-hour history alarms of BSC. 1. In the Fault Management tab, select Query > View History Alarms, as shown in Figure 6.7 Figure 6.7 Selecting View History Alarms
O&M Handbook on ZTE Radio Technologies
Page 81
2. History Alarm Query Conditions tab appears, as shown in Figure 6.8. Figure 6.8 History Alarm Query Conditions Tab
3. In the History Alarm Query Conditions tab, click in the toolbar Figure 6.9 Query History Alarm Dialog Box
O&M Handbook on ZTE Radio Technologies
Page 82
b. In the Query History Alarm dialog box, select Happen Time. Time options appear on the right, as shown in Figure 6.10. Figure 6.10 Time Options for History Alarms
c. Select By Relative Time, enter 1 in the Latest spin box or click until 1 appears in the spin box, as shown in Figure 6.11
O&M Handbook on ZTE Radio Technologies
Page 83
Figure 6.11
Note:As shown in Figure 6-16, users can also select By Time Range and set Begin Time and End Time. By default, the duration between Begin Time and End Time is the past 24 hours. d. In the Query History Alarm dialog box, after setting Happen Time, click OK. The system starts query and displays the query result as a list in the View History Alarms tab, as shown in Figure 6.12 Figure 6.12
6.3.2.5 Querying BSC KPIs
O&M Handbook on ZTE Radio Technologies
Page 84
Operation Guide Perform the following steps to query the Key Performance Index (KPI) of BSC. 1. In the Performance Management tab, click Performance Management > Performance Data Query, or click in the toolbar, as shown in Figure 6.13. Figure 6.13 Selecting Performance Data Query
Note: Important KPI data are reported to the NMS from the NE, users need not change any settings. Six types of KPI values should be especially noticed: call drop rate, congestion rate, availability rate, handover success rate, CPU load, and traffic call drop ratio. 2.
Query dialog box pops up, as shown in Figure 6.14 Figure 6.14
3. In the Query Index tab of Query dialog box, select BSC Function in Object Type drop down menu, and check CPU Load Measurement check box, as shown in Figure 6.15
O&M Handbook on ZTE Radio Technologies
Page 85
Figure 6.15 Selecting CPU Load Measurement
4. Set the query time in Query Time tab, set the query object in the Query Object tab, and click OK in the Query dialog box. 5. Click in the toolbar to save the query result. 6. In the Query Index tab of Query dialog box, select Cell Function in Object Type drop down menu, and check KPI Index check box, as shown in Figure 6.16. Figure 6.16 SELECTING KPI INDEX
7. Set the query time in Query Time tab, set the query object in the Query Object tab, and click OK in the Query dialog box. 8. Click in the toolbar to save the query result.
O&M Handbook on ZTE Radio Technologies
Page 86
Abnormality Handling Analyze KPI values. If a KPI value exceeds the normal range, perform troubleshooting immediately. 6.3.2.6 Checking A-Interface Status Operation Guide Perform the following steps to query A-interface status. 1. Enter Topology Management, right-click on the NE to be checked in Physical View, and click NE Management > Status Management. The BSC Status management tab is shown in Figure 6.17 Figure 6.17
2. Select No. 7 Signaling Management tab to query the link status. 3. Select A PCM Management tab to query the PCM status. Select A Trunk Management tab to query status of all timeslots. 4. If IP A-interface is adopted, select IP A Management tab to query the user plane sub-unit status. Reference Standard The configured LINK is in the status of being activated or signaling occupation. The configured voice channel is in the status of being occupied or being idle. The user plane sub-unit status is normal. Abnormality Handling Perform the following operations to handle abnormalities. 1. BSC self-test a. Judge whether BSC is normal. During A-interface interconnection, if the No. 7 signaling link is disconnected, check BSC and ensure that BSC has no problem. b. Check the running status of all boards in BSC and ensure that all indicators are in normal status. c. According to configuration data, find out s where the No. 7 signaling link is located. d. Perform self-loop test for these PCMs, and observe the status of SPB/SPB2 and DTB indicators. After the self-loop test is performed, if the E1 indicator on SPB/SPB2 and DTB flashes rapidly, it indicates that no problem exists inside BSC; otherwise, it indicates that some problem exists inside BSC.
O&M Handbook on ZTE Radio Technologies
Page 87
2. BSC internal problem troubleshooting a. Data problem The probability of data configuration error is low. The configuration should be performed very carefully. b. Hardware problem These problems include board problems and internal cable connection problems. Some common fault symptoms are: board fault, E1 line position being inconsistent with the configured serial number, etc. For No. 7 signaling fault, check the boards where No. 7 signaling passes through, unplug and plug these boards one by one to locate the fault. 3. If no problem exists inside the BSC, check the interconnection data and ensure that they are correct. 4. Check external connections to ensure they are correct. 6.3.2.7 Checking Gb Interface Status Operation Guide According to whether Gb interface uses IP or E1, the operation steps for checking Gb Interface statuses are divided into two types:
Gb interface uses IP
1. In the Status management tab, double-click the BSC Status management node in the left Configuration Resource Tree. BSC Status management tab is shown in Figure 6.18 Figure 6.18 BSC Status Management Tab
2. Select the IP GB Management tab to query the end node status, NSVC status and dynamic end node status. 3. If Flex Gb interface is adopted, select SGSN Office Management tab to query the SGSN status.
Gb interface uses E1
1. In the Status management tab, double-click the BSC Status management node in the left ConfigurationResource Tree. BSC status management tab. 2. Select the NSVC Management tab to query the NSVC status. 3. If interface is adopted, select SGSN Office Management tab to query the SGSN status. Reference Standard The configured NSVC is in the status of being occupied or being idle, without
O&M Handbook on ZTE Radio Technologies
Page 88
Congestion or being blocked. At least one SGSN’s status is enabled and unblocked. The cell has no congestion. Abnormality Handling Perform the following operations to handle abnormalities. 1. BSC self-test a. Judge whether BSC is normal and ensure that BSC has no problem. b. Check the running status of all boards in BSC and ensure that all indicators are in normal status. c. Perform self-loop test for PCM, and observe the status of SPB /SPB2 indicators. After the self-loop test is performed, if the E1 indicator on SPB/SPB2 flashes rapidly, it indicates that no problem exists inside BSC; otherwise, it indicates that some problem exists inside BSC. 2. BSC internal problem troubleshooting a. Data problem The probability of data configuration error is low. The configuration should be performed very carefully. The correctness of data configuration is checked by comparing ZDB files of the NMS with those of the NE. b. Hardware problem These problems include board problems and internal cable connection problems. Some common fault symptoms are: board fault, E1 line position being inconsistent with the configured serial number, etc. If no problem exists inside the BSC, check the interconnection data and ensure thatthey are correct. 3. Check external connections to ensure they are correct 6.3.2.8 Checking Abis Interface Status Operation Guide Perform the following steps to query Abis interface status. 1. Enter Topology Management, right-click on the NE to be checked in Physical View, and click NE Management > Status Management. The BSC Status management tab is shown in Figure 6.19 Figure 6.19 BSC status Management Tab 3-36
2. On the BTS Equipment Management tab, select Abis Interface Time Slot Managment. 3. On the Abis Interface Time Slot Managmenttab, query the time slot usage of Abis interface.
O&M Handbook on ZTE Radio Technologies
Page 89
4. On the Abis Interface Time Slot Managmenttab, query the time slot status of Abis interface, including PCM status, DSP status, and trunk circuit status. 5. If all time slots are idle for a long time, check the signal time slot status. 6. If there is no abnormality, stop checking Abis interface state. If there is abnormality, perform BSC selftest. Reference Standard The time slots are occupied or idle. The link is not congested or blocked. The communication is normal. The voice time slots are occupied or idle. Abnormality Handling Perform the following operations to handle abnormalities. 1. BSC self-test a. Make sure that BSC has no problem. b. Check the running status of all boards in BSC and ensure that all indicators are innormal status. c. Perform self-loop test for these PCMs, and observe the status of SPB/SPB2 and DTB indicators. After the self-loop test is performed, if the E1 indicator on SPB/SPB2 and DTB flashes rapidly, it indicates that no problem exists inside BSC; otherwise, it indicates that some problem exists inside BSC. 2. BSC internal problem troubleshooting a. Data problem The probability of data configuration error is low. The configuration should be performed very carefully. The user can compare the ZDB file of the NMS and NE to find the data problem. b. Hardware problem These problems include board problems and internal cable connection problems. Some common fault symptoms are: board fault, E1 line position being inconsistent with the configured serial number. 3. External lines Check external connections to ensure they are correct. 6.3.2.9 Checking Board’s Active-Standby Status Prerequisite Prior to performing this task, make sure that: Net Numen U31 client is running normally. Connection between the client and server is normal. Network element management of relevant NEs is started successfully. Operation Guide Perform the following steps to check the board’s active/standby status. 1.In the Status Management tab, select and double-click the rack where the board is located. The rack view appears on the right, as shown in Figure 6.20
Figure 6.20 Checking Board’s Active/Standby Status
O&M Handbook on ZTE Radio Technologies
Page 90
2. Check the color of the board in the rack view. As shown in the Legend tab in Figure 6.20, green represents that the board is active while blue represents that the board is standby. Reference Standard For details of the active and standby status of all boards, refer to the Legend tab on the right side of rack view. Abnormality Handling Perform the following operations to handle abnormalities. 1. Check the active/standby status indicator on the board to ensure that it is consistent with that displayed on the NM interface. 2. If the active/standby status of all boards is unknown, check the communication link between the NMS and NE. For operation details, refer to Checking NE-NMS Communication Link. 3. If the active/standby status of some boards is unknown, enter Fault Management to view alarm details. For operation details, refer to Querying BSC’s Current Alarms. 6.3.2.10 Querying BSC Operation Log Background Knowledge The operation log of BSC records the BSC operation details, which is often used to locate the fault. Browsing and saving the operation log every day helps to find the abnormality in system running and operation. Operation Guide Perform the following steps to query the operation log of BSC. 1. Enter Topology Management, right-click on the NE to be checked in Physical View, And click Query NE Log > Operation Log in the pop-up menu, as shown in Figure 6.21. Figure 6.21 Entering Log Management
O&M Handbook on ZTE Radio Technologies
Page 91
2. In the Query Operation Log dialog box, user can set query conditions to perform the query, as shown in Figure 6.22 Figure 6.22 Query Operation Log Dialog Box
3. The query result of operation log is shown in Figure 6.23
O&M Handbook on ZTE Radio Technologies
Page 92
Figure 6.23 Operation Log Query Result
4. Double-click an operation log to view the operation log details. Reference Standard The operation log does not contain any unknown data configuration operation and resetting operation, and the log information is normal. Abnormality Handling l If the operation log contains data configuration operation, check whether the peration is correct and who performs the operation. l If the operation log contains the following maintenance operations, find out the reason why they are included in the log: Resetting board Board changeover Blocking link Deactivating No. 7 link Disabling signaling point and subsystem Port loopback 6.3.2.11 Checking Alarm Box Operation Guide Perform the following steps to check the alarm box: 1. In the Fault Management tab, click Setting > Alarm Box Setting and check whether the link between the alarm box and the server is established. 2. Query the past 24-hour history alarms of BSC to see whether the alarm box has any alarm. For operation details, refer to Querying BSC’s Past 24-Hour History Alarms. 3. Check whether the critical alarm that satisfies the reporting conditions can be correctly sounded and displayed on the alarm box. Reference Standard The RUN indicator on the alarm box flashes regularly. The alarm level indicated by the alarm indicator is consistent with the current alarm displayed in Fault Management. The suppressed alarm is not displayed on the alarm box.
level
Abnormality Handling
O&M Handbook on ZTE Radio Technologies
Page 93
Perform the following operations to handle abnormalities. 1. If the alarm box has alarm, enter Fault Management at client to check the alarm details. For operation details, refer to Querying BSC’s Past 24-Hour History Alarms. 2. Check the cable connection and connectors between the alarm box and NM server and ensure that they are normal. Check whether the HUB and the switch is power-down and ensure that they work normally. 3. Check the alarm box configuration to ensure that the configuration is correct.
6.4 Weekly Maintenance 6.4.1 Cleaning Equipment Operation Guide In the equipment room, check the equipment and ensure that there is no cobweb or dust. Reference Standard The equipment should be clean and tidy. Abnormality Handling Clean the equipment in times especially, the dust-proof plug-in box. 6.4.2 Checking BSC Clock Status Operation Guide Perform the following steps to checkBSC clock status. 1. Check the status ofCLKG/ICM panel indicators, and make sure that external connections of the CLKG/ ICM’s rear board are normal. 2. Enter Fault Management to check whether there is any clock alarm for. Operation details refer to Querying BSC’s Current Alarms. 3. Check whether the system clock of boards is normal and whether the clock data of the NE is consistent with that of the NMS. Reference Standard ZXG10iBSC has three types of clock generating boards:
CLKG(CLKG)
CLKG(ICM)
ICM
6.4.3 Checking OMP/OMP2/CMP/CMP2
O&M Handbook on ZTE Radio Technologies
Page 94
Operation Guide Perform the following steps to check OMP/OMP2/CMP/CMP2. 1. Check whether the link between the NMS and the NE is established successfully, and check whether the active/standby status of OMP/OMP2/CMP/CMP2 is normal. 2. Enter Status Management and open the BSC rack view. Right-click OMP/OMP2 or CMP/CMP2 and click CPU1 or CPU2 in the pop-up menu, and click Query CPU occupation rate in the pop-up menu. The CPU occupancy is displayed in the Operation Result dialog box. 3. Check whether OMP/OMP2/CMP/CMP2 has any abnormal alarm. 4. Obtain the equipment printing file to check whether Exc_Omp.txt file and Exc_pp. txt file are updated. a. Execute the ftp command at OMM to connect OMP/OMP2. Both the user name and the password are zte, and the specified port is 21. b. Execute the cd/DOC0 command to enter the DATA0 directory. c. Execute the get command to get Exc_Omp.txt file and Exc_pp.txt file. d. Download the file to OMM server, then use ftp tool (such as CUTEFTP) to transmit the file to client. Reference Standard The link between the NMS and the NE is established successfully. There is no abnormal alarm. It is recommended that CPU occupancy is not larger than 80%. Neither Exc_Omp .txt file nor Exc_pp.txt file has newly added information about abnormal resetting. Abnormality Handling Perform the following operations to handle abnormalities: 1. If the board’s CPU occupancy is too large, check whether there is any traffic peak. If CPU occupancy exceeds 95%, unplug some LAPD boards to reduce the traffic. 2. Enter Fault Management at client to view alarms. For operation details, refer to Querying BSC’s Current Alarms. 3. If the board’s active/standby status is unknown, check the the link between the NMS and NE. Ensure that the link is normal. Check connections and connectors between the NMS server, NE, and OMP/OMP2 (or CMP/CMP2), and ensure that they are normal. Check whether the HUB and the switch is power-down, and ensure that they work normally. 4. Check the data and version configuration of OMP/OMP2 (or CMP/CMP2) on the NMS and NE, and ensure that the configurations on the NMS and NE are consistent. 5. Perform OMP/OMP2 or CMP/CMP2 active/standby changeover. 6. Reset OMP/OMP2 or CMP/CMP2. 7. Unplug and plug OMP/OMP2 or CMP/CMP2 and ensure that the board is plugged in properly. If problem still exists, replace the board. 6.4.4 Querying BSC Alarms Real-Time Statistics Operation Guide Perform the following steps to query the real-time statistics of BSC alarms. 1. Enter Fault Management, right-click the NE to be checked. Select Show current alarms > Show all current alarms in the pop-up menu, as shown in Figure 6.24
Figure 6.24 Selecting Show All Current Alarms
O&M Handbook on ZTE Radio Technologies
Page 95
2. Click in the toolbar to pop up the Save dialog box. Reference Standard Real-time alarms of BSC are saved successfully. 6.4.5 Analyzing History Alarms of the Past Week Operation Guide Perform the following steps to analyze history alarms of the past week. 1. Enter Fault Management and click Query > History Alarm Statistics. 2. Report Management tab appears, as shown in Figure 6.25 Figure 6.25 Report Management Tab
3. Create a new report template and then double-click the new template, or double-click an existing template. The report parameter input interface pops up, as shown in Figure 6.26 Figure 6.26 Report Parameter Input Interface
O&M Handbook on ZTE Radio Technologies
Page 96
4-19 4. In the Parameter Input Box – Statistics Frequency By Alarm Code dialog box, as shown in Figure 44, select appropriate parameters, set Happen Time to be the past week, and click OK. 5. The statistics result is generated automatically, as shown in Figure 6.27 Figure 6.27
Abnormality Handling Analyze history alarms according to actual requirements 6.4.6 Analyzing Performance Indices Operation Guide Perform the following steps to analyze performance indices:
O&M Handbook on ZTE Radio Technologies
Page 97
1. Enter Performance Management, and establish the performance statisticsmeasurement task. 2. Perform the measurement task. There are two types of measurement tasks. KPI data statistics KPI data are reported to the NMS from the NE. Operators do not need to do anysetting. Performance measurement statistics Check the collected performance measurement data, and terminate unnecessary performance measurement tasks. 3. Implement the performance data query, and the query time is the past week. 4. Export the data. Select appropriate export options and save the performance data query result. Reference Standard KPI data can be reported to the NMS. For details of KPI performance data, refer to Performance measurement data can be reported correctly. The performance statistics result can be generated into report, and all indices in the report are normal. Abnormality Handling o Check and ensure that the data configuration is correct. o Check and ensure that the hardware is not faulty. 6.4.7 Checking Server Running Status Prerequisite Prior to performing this task, make sure that: NetNumen U31 client is running normally. Connection between the client and server is normal. Operation Guide Perform the following steps to check the server running status: 1. Click View > System monitoring, to enter System monitoring. 2. In the System monitoring tab, select Self Office:OMCnode and click ApplicationServer> Server Performance, 3. The server performance query interface pops up, as shown in Figure 6.28 Figure 6.28 Server Performance Query Interface
6.4.8 Checking Occupied Space of Database at NM Server Operation Guide
O&M Handbook on ZTE Radio Technologies
Page 98
Perform the following steps to check the occupied space of database at NM server. 1. Click Maintenance > System monitoring to enter System monitoring. 2. In the System monitoring tab, log in the database. 3. Select the Oracle node, and click Database Server > View Database Resources, as shown in Figure 6.29 Figure 6.29 View Database Resources
4. View Database Resources dialog box pops up, as shown in Figure 6.30 Figure 6.30 View Database Resources Dialog Box
5. In View Database Resources dialog box, pay attention to the following table spaces and calculate the percentage of remaining space of each table space: l Table space that begins with MINOS_RNS_PM, such as MINOS_RNS_PM, MINOS_RNS_PM_DAY, and MINOS_RNS_PM_HUR. l UEP
O&M Handbook on ZTE Radio Technologies
Page 99
l UEP_CAF_FM
56.4.9 Configuration Data Backup Operation Guide Perform the following steps to implement configuration data backup. 1. Enter Configuration Management and log in the database. 2. Perform configuration data backup.
Manual backup a. Click Maintenance > System Backup and restore > Backup basic data, as shown in Figure
6.31 Figure 6.31 Selecting Data Backup
a. Data Backup dialog box pops up, as shown in Figure 6.32 Figure 6.32 Data Backup Dialog Box
c. Set Storage path and select the Network Element (NE) to backup from the tree in the Select managed elements to backup area, and click OK d.Data Backup Result dialog box pops up, as shown in Figure 6.33
O&M Handbook on ZTE Radio Technologies
Page 100
Figure 6.33 Data Backup Result Dialog Box
Automatic backup
By default, the system automatically performs backup for OMM configuration data every day. 6.4.10 Virus Scanning Background Knowledge Virus scanning is mainly performed at client. If SBCX/SBCX2 adopts WINDOWS/LINUX operating system, virus protection must be implemented. Operation Guide Perform the following steps to implement virus scanning: 1. Make sure that the automatic update function of the antivirus software is enabled, or update the virus library periodically. 2. Make sure to customize the periodical virus-scanning task and real-time virus monitoring task. Reference Standard The virus library is updated successfully. The periodical virus-scanning task and real-time virus monitoring task are performed normally 6.5 Monthly Maintenance 6.5.1 Checking Board Software Version Operation Guide Perform the following steps to check software version of the board. 1. Enter Topology Management, right-click on the NE to be checked in Physical View, and click NE Management > Software Version Management. 2. In the Software Version Management tab, double-click the BSC rack node in the left Configuration Resource Tree. BSC rack tab appears on the right. Right-click the board of which the software version is to be checked, and click Software version query (BSC) in the pop-up menu, as shown in Figure 6.34 Figure 6.34 Querying Software Version of Board
O&M Handbook on ZTE Radio Technologies
Page 101
3. Appointed Board Running Version Query dialog box pops up, as shown in Figure 6.35 Figure 6.35 Appointed Board Running Version Query Dialog Box
3.
Double-click the BSC software management node in the left Configuration Resource Tree, and select BSC general software tab on the right to view the information of BSC general software, as shown in Figure 6.36 Figure 6.36 Board Database Version Information
O&M Handbook on ZTE Radio Technologies
Page 102
5. Select the BSC specific software tab to view the information of some specific software version. 6. Compare the board’s database version information and the board’s running version information. Abnormality Handling Upgrade the software if the following two cases are encountered: BSC’s running software version is inconsistent with the configured software version. The site’s running software version is inconsistent with the database configuration Information. 5-36.5.2 Checking Clock Synchronization Operation Guide Perform the following steps to check whether the clock is synchronized. 1. Check the Clock check setting of each shelf and ensure that the Clock check drop down menu is set to Yes for UIM/GUIM/GUIM2 board in each shelf, as shown in Figure 6.37 Figure 6.37 Setting Clock Check Property
2. Check A-interface configuration of SPB /SPB2/DTB/SDTB/SDTB2. Check input cables of the clock board and make the external standard clock extracted by SPB/SPB2/DTB/SDTB/SDTB2 reach the clock board
O&M Handbook on ZTE Radio Technologies
Page 103
Abnormality Handling Perform the following operations to handle abnormalities: 1. Check indicators on the CLKG/ICM board panel to decide the running status of CLKG/ICM. If the FREE indicator is green and ON, it indicates that the board is in free oscillating status and it is required to reset the corresponding A-interface E1 circuit. 2. Check and ensure that the external cable connections of the CLKG/ICM’s rear board RCKG1 and RCKG2 are normal. 3. Perform CLKG/ICM active/standby changeover and check the board working status. 4. Replace the CLKG/ICM board if the board is faulty. 5-4 6.5.3 Checking Automatic Backup Clearing Function of Database Operation Guide Perform the following steps to check the automatic backup clearing function of database. 1. Check the configuration management backup files under /home/gomcr/ums-svr/ Backup /sys manager/cm at the OMM server and ensure that there is no backlog of files. 2. Check the fault management backup files under /export/home/omc/ums-svr/backup/sysmanager/fmat the server and ensure that there is no backlog of files. 3. Check the performance management backup files under /export/home/omc/ums -svr/backup/sysmanager/pm at the server and ensure that there is no backlog of files. 4. Check the log management backup files under /export/home/omc/ums-svr/bac kup/sys manager/log at the server and ensure that there is no backlog of files. 5. Check the performance configuration management backup files under /export/home/omc/umssvr/backup/sys manager/ueppmat the server and ensure that there Is no backlog of files? Reference Standard There is no backlog of backup files. Abnormality Handling If backup files are not deleted in time, then perform the following operations to delete backup files periodically: lClick Database Server > Table Collection Operations, as shown in Figure 6.38, to set the backup file to be deleted periodically. Figure 6.38 Table Collection Operations
6.5.4 Updating Operating System Patch Background Knowledge The operating system patch upgrade includes:
O&M Handbook on ZTE Radio Technologies
Page 104
Upgrading NM server’s patch Upgrading NetNumen U31 client’s patch
Operation Guide ZTE Corporation issues technical notice periodically. Upgrade the operating system patch with the aid of local ZTE office. 6.5.5 Checking Optical Interface Protective Cap Operation Guide Check the idle optical interface of the board and ensure that it has the protective cap. 6.6 Quarterly Maintenance 6.6.1 Checking Power Supply Operation Guide Perform the following steps to check the power supply: 1. Check and ensure that the AC power of server and client is normal. 2. Check and ensure that the -48 V power supply of rack equipment is normal. 3. Check and ensure that the standby battery (if there is any) is normal. 4. Check the batteries and ensure that there is no leaking liquid, and make sure that the cable connections are reliable. 5. Keep the batteries clean. For long-term storage, charge the battery periodically. Reference Standard The power supply for the server, the client, and BSC rack is normal. There is no power alarm. The power cable is not old. There is no corrosion at the connection point. 6.6.2 Checking Cable Connections Category BSC internal cables
BSC external cables
Type Clock cable Control-plane interconnection cable User-plane interconnection cable PD485 cable and fan monitoring cable Power supply system cable Grounding system cable Monitoring system cable Transmission system cable Power system cable Grounding system cable NM Ethernet cable
Operation Guide Perform the following steps to check cable connections. 1. Check and ensure that the cable layout (such as power cable, grounding cable, transmission cable, and jumper) is clean and tidy. Make sure that the label is stuck on the cable firmly. 2. Make sure that the cable connections are correct. Abnormality Handling If the cable label falls off, stick the label to the cable in time. The equipment name (ID) and detailed interface position should be marked on the label as: Rack number – Shelf number – Board number – Interface number, or, Equipment name (ID) – Interface number.
O&M Handbook on ZTE Radio Technologies
Page 105
6.6.3 Checking Fan Plug-in Box Working Condition Background Knowledge The fan plug-in box monitors and performs automatic rate adjustment, forming a closed wind channel through which wind comes in from the bottom and goes out from the top in the cabinet. The fan plug-in box cools the equipment with wind flow. Operation Guide Perform the following steps to check the running conditions of fan plug-in box. 1. Check whether there is any fan plug-in box alarm. 2. Check the running condition of each fan in the fan system and ensure that there is no abnormality such as abnormal sound or the vane touching the cabinet. 3. Clean the fan system periodically. Reference Standard The fan plug-in box has no alarm and all fans work normally. Abnormality Handling If abnormality is found in the fan, replace the faulty fan. For operation details, refer to If abnormality is found in the fan, replace the faulty fan. 6.6.4 Checking Anti-Static Wrist Strap Background Knowledge In dry environment, the static electricity accumulated in human body might cause high-voltage static electricity. If the operator touches the electronic devices with static electricity in the body, the device might be damaged. Wearing the anti-static wrist strap can discharge the static electricity in human body and avoid device damage. Therefore, the operator must wear the anti-static wrist strap before touching the equipment, and holding the board, circuit board, or IC chip. The other end of the anti-static wrist strap must be well grounded. Operation Guide Check the anti-static wrist strap of each rack and make sure that they are installed in correct positions and have good contact. 6.6.5 Checking Spare Materials and Parts Operation Guide Perform the following steps to check the spare materials and parts: 1. Check the spare materials and parts with the list of spare materials and parts. 2. For common spare materials and parts, supplement them in time if they are used up. Reference Standard The spare materials and parts are sufficient and not damaged. 6.6.6 Checking Grounding Conditions Operation Guide Perform the following steps to check grounding conditions: 6-3 1. Check various grounding cables (PGND, -48 VGND), user grounding-connector-bar connections, and DDF grounding cables, and ensure that they are safe and reliable. 2. Use the grounding resistance tester to measure the grounding resistance and recordthe value. Reference Standard All connections are safe and reliable, and there is no corrosion at the connection point. The grounding cable is not old. The grounding connector bar has no corrosion. The corrosion protection is performedappropriately.
O&M Handbook on ZTE Radio Technologies
Page 106
The joint grounding resistance is less than 1 Ω.
Abnormality Handling Perform the following operations to handle abnormalities. 1. Check the grounding connector bar and ensure that it is normal. 2. Check the grounding cable. If it is old, replace the grounding cable. 3. Check the connector. If it has corrosion, remove the corrosion. If the corrosion is critical, replace the relevant part. 4. Measure the joint grounding resistance and ensure that it is less than 1 Ω. 6.6.7 Cleaning Air Filter Background Knowledge The air filter must be cleaned periodically, usually once a month or once a quarter, according to the equipment room environment conditions. There are two types of air filters: lThe air filter which is added to the air intake at the rack bottom: it uses ABS plastic as the frame, with nylon net inside. The air filter is flexible. lThe door air filter: it uses metal as the frame, with polyurethane second foaming plastic inside. Both types of air filters can be reused after cleaning, and are easy for installation and disassembling. Operation Guide Perform the following steps to clean the air filter. 1. Remove the fixing screws of the dust-proof plug-in box on the rack and then pull the dust-proof plug-in box out of the rack, as shown in Figure 3.39 Figure 6.39 Pulling Dust-Proof Plug-In Box Out Of Rack
2. Disassemble the dust-proof plug-in box and take out the air filter. 3. Clean the air filter with lukewarm water (less than 40 ºC) and dry it. 4. Install the air filter into the dust-proof plug-in box. Note: The air filter installation is the reverse of the process of taking the air filter out. The air filter must be dried before being installed into the dust-proof plug-in box. 5. Install the dust-proof plug-in box into the rack. The dust-proof plug-in box installation is the reverse of the process of taking the dust-proof plug-in box out. 6. For the door air filter, the cleaning process is similar to that of the air filter inside the dust-proof plug-in box. 6-5
Chapter 7 ZTE RNC Hardware O&M Handbook on ZTE Radio Technologies
Page 107
___________________________________________________ 7.1 RNC H/W Overview Cabinet Appearance The ZXWR RNC cabinet complies with the Compact PCI standard. Its cabinet appearance, see Figure 7.1 Figure 7.1 Cabinet Appearance
Hardware Composition ZXWR RNC is composed of the following module: l Cabinet l Sub-Rack l Shelf l Board l Auxiliary equipment
7.2 Cabinet 7.2.1 Cabinet Types
O&M Handbook on ZTE Radio Technologies
Page 108
There are two types of ZXWR RNC cabinet, the differences between the two types of cabinet is shown in Table 7-1 Table 7-1 Cabinet Types Differences
New Cabinet
Old Cabinet
2000 mm × 600 mm × 800 mm
2000 mm × 650 mm × 800 mm
(H × W × D) 19” cabinet
(H × W × D) 19” cabinet
Power Distribution Sub-rack
adopting new power distribution sub-rack, providing two independent power outputs for each shelf in the cabinet
adopting old power distribution sub-rack, providing one independent power output for each shelf in the cabinet
Shelf
adopting new shelves, supporting two independent power inputs
adopting old shelves, supporting one power input
Bus-bar
providing two –48 V busbars
providing one –48 V busbars
Dimension included)
(side
door
7.2.2 Cabinet Structure For the ZXWR RNC cabinet structure, see Figure 7.2 Figure 7.2 Cabinet Structure
1. 2. 3. 4.
Cover Filter Wire reel Front door
5. 6. 7. 8.
Service sub-rack Fixing base Rear door Bus-bar
9. 10.
Side door Rack
O&M Handbook on ZTE Radio Technologies
Page 109
ZXWR RNC Hardware Description
7.2.3 Rack The rack is composed of the top shelf, bottom shelf, post, adjustable rail, and side door. For its structure, see Figure 7.3. Figure 7.3 Rack Structure
1. Top shelf 2. Post
3. 4.
Adjustable rail 5. Side door
Bottom shelf
7.2.4 Sub-Rack 7.2.4.1 Sub-Rack Classification ZXWR RNC sub-racks include the following types:
Power distribution sub-rack
2-2 O&M Handbook on ZTE Radio Technologies
Page 110
Fan sub-rack Service sub-rack Dustproof sub-rack
7.2.4.2 Sub-Rack Layout The layout of all ZXWR RNC Sub-Racks in the cabinet is as shown in Figure 7.4 Figure 7.4 Sub-Rack Layout
1. PDM Sub-Rack 3. 2. Fan Sub-Rack 4.
1 U dummy panel Service Sub-Rack
5. Dustproof Sub-Rack
7.3 Shelf 7.3.1 Shelf Configuration
The typical 3 rack with full shelf configuration is shown in Figure 7.5
O&M Handbook on ZTE Radio Technologies
Page 111
Figure 7.5 Shelf Configuration
7.3.2 Control Shelf 7.3.2.1 Control Shelf Definition The control shelf deals with the control plane signaling, operates and maintains the system, and provides the global clock.
7.3.2.2 Control Shelf Functions Operates and maintains the system Deals with the control planesignaling Provides the global clock
7.3.2.3 Control Shelf Position Requirements The control shelf with ROMB must be configured on the layer No.2 of rack No.1. Other control shelves can be configured on any layer of the rack.
7.3.2.4 Control Shelf Configuration Principles The configuration principles of the control shelf are shown in Table 7-2. Table 7-2 Configuration Principles of Control Shelf Board
Qty.
Slot
Recommended
Configuration
Slot
Principles
Front Boards
7.3.2.5 Control Shelf Typical Configuration
The typical configuration of control shelf is shown in Figure 7.6
O&M Handbook on ZTE Radio Technologies
Page 112
Figure 7.6 Typical Configuration of Control Shelf
7.3.3 Switching Shelf 7.3.3.1 Switching Shelf Definition The switching shelf is the core switching subsystem of ZXWR RNC, providing necessary message transport channel between internal/external functional units. When 3 or more than 3 resource shelves are configured in ZXWR RNC system, the switching shelf is needed to interconnect these resource shelves.
7.3.3.2 Switching Shelf Functions The switching shelf is to perform the data interaction, including timing, signaling, voice service and data service. The switching shelf provides the level-1 IP switching platform for the system, for the interconnection of multiple resource shelves with the interface shelf, and the expansion of user planes between resource shelves.
7.3.3.3 Switching Shelf Position Requirements There is no restriction about the position of switching shelf. Usually, it is configured on the Layer 4 of Cabinet No.2. . 7.3.3.4 Switching Shelf Typical Configuration The typical configuration of the switching shelves is shown in Figure 7.7.
O&M Handbook on ZTE Radio Technologies
Page 113
Figure 7.7 Typical Configuration of Switching Shelf
7.3.4 Resource Shelf 7.3.4.1 Resource Shelf Definition The resource shelf is one type of ZXWR RNC shelf. It provides the user plane processing pool and Iu/Iur/Iub interfaces.
7.3.4.2 Resource Shelf Functions The resource shelf performs the following functions: l
User plane protocol processing, Gateway, and interface bottom-layer processing
l
IP access (high-speed IP) and ATM access through Iu interface IP access (high-speed IP) and ATM access through Iub interface IP access (high-speed IP) and ATM access through Iur interface. At present, Iur interface and Iu interface have the same access mode.
l
7.3.4.3 Resource Shelf Position Requirements There is no restriction about the position of resource shelf. Usually, it is configured on the Layer 1, Layer 3 and Layer 4.
7.3.4.4 Resource Shelf Typical Configuration The typical configuration of resource shelf is shown below: 1.
The typical configuration of the resource shelf providing Iu interface with ATM access is shown in Figure 7.8
O&M Handbook on ZTE Radio Technologies
Page 114
Figure 7.8 Typical Configuration of Resource Shelf 1
2.
The typical configuration of the resource shelf providing Iu interface with IP access is shown in Figure 7.9.
Figure 7.9 Typical Configuration of Resource Shelf 2
3.
The typical configuration of the resource shelf providing Iu interface with IP access and Iub interface with ATM CSTM-1 access is shown in Figure 710.
Figure 7.10 Typical Configuration of Resource Shelf 3
O&M Handbook on ZTE Radio Technologies
Page 115
7.4 Boards in RNC 7.4.1 Board Definition A board refers to an integrated circuit board that can fulfill a specific function.
7.4.2 Board Classification The boards of ZXWR RNC fall into 3 types:
Front boards Rear boards Backplanes
7.4.2.1 Front Board Definition The front board is the board inserted in the front slot of the shelf.
7.4.2.2 Rear Board Definition The rear board is the board inserted in the rear slot of the shelf. The main function of the rear board is providing interfaces for its front board.
7.4.2.3 Backplane Definition The backplane is a kind of board which providing slots for the front board and the rear board to interconnect with each other.
7.4.3 Board Structure The board structure is shown in Figure 7.11. Figure 7.11 Board Structure
1. Front board panel 2. Front board 4.
3. Slot
Backplane 5. Rear board 6. Rear board panel
O&M Handbook on ZTE Radio Technologies
Page 116
7.4.4 Board Indicators 7.4.4.1 Indicator Classification The indicators on the board panel fall into 2 types: 1.
Common indicators The common indicators exist on all boards.
2.
Special indicators Except for the common indicators, most boards have their special indicators.
7.4.4.2 Indicator Statuses The statuses of the indicators on the board panel are listed in Table 7-3 Table 7-3 Indicator Statuses Type
Status
Description
1
ON
The LED indicator is ON.
2
OFF
The LED indicator is OFF.
3
Flashing 5 Hz
at
ON for 0.1 second and OFF for 0.1 second.
4
Flashing 2 Hz
at
ON for 0.25 second and OFF for 0.25 second.
5
Flashing 1 Hz
at
ON for 0.5 second and OFF for 0.5 second.
6
Flashing 0.5
at
ON for 1 second and OFF for 1 second.
Hz 7.4.5 Front Boards 7.4.5.1 Front Board Structure
The structure of the front board is shown in Figure 7.12 Figure 7.12 Structure of Front Board
1. Extractor
3.
PCB
5.
Lead sheath
2. Panel of front board
4.
Plug
6.
Reinforcing rib
O&M Handbook on ZTE Radio Technologies
Page 117
7.4.5.2 APBE Board 7.4.5.2.1 APBE Board Definition The APBE is the ATM processing board of ZXWR RNC. 7.4.5.2.2 APBE Board Functions The APBE board provides STM-1 accessing and ATM processing function. APBE board is composed of the following units: 1. 2. 3.
Optical interface unit including the optical unit and PHY chip. It implements the STM-1 access function. ATM layer processing controlling the cell streams, handover and forwarding. Processing unit of the media plane and control plane including AAL2/5 SAR subsystem and CPU daughter card. After SAR processing, AAL2/5 SAR subsystem falls into two parts: media plane cell whose stream is send out directly by AAL2/5 SAR subsystem, and control plane cell whose stream is processed and sent out by CPU daughter card. 7.4.5.2.3 APBE Board Rear Board The rear board of the APBE is RGIM1.
7.4.5.3 DTA Board 7.4.5.3.1 DTA Board Definition The DTA is the ATM digital trunk board of ZXWR RNC. 7.4.5.3.2 DTA Board Functions The DTA board provides channelized ATM E1/T1 accessing and IMA, ATM processing function. 7.4.5.3.3 DTA Board Rear Board The rear board of the DTA is the RDTA.
7.4.5.4 DTI Board 7.4.5.4.1 DTI Board Definition The DTI is the IP digital trunk board of ZXWR RNC. 7.4.5.4.2 DTI Board Functions The DTI board provides channelized IP E1/T1 accessing and PPP, MLPPP processing function. . 7.4.5.4.3 DTI Board Rear Board The rear board of the DTI is RDTA.
O&M Handbook on ZTE Radio Technologies
Page 118
7.4.5.5 ET3A Board 7.4.5.5.1 ET3A Board Definition The ET3A is the E3/T3 ATM interface board of ZXWR RNC. 7.4.5.5.2 ET3A Board Functions ET3A performs ATM E3/T3 accessing and ATM processing function. 7.4.5.5.3 ET3A Board Rear Board The rear board of the ET3A is RLIB.
7.4.5.6 ET3I Board 7.4.5.6.1 ET3I Board Definition The ET3I is the E3/T3 IP interface board of ZXWR RNC. 7.4.5.6.2 ET3I Board Functions ET3I performs IP E3/T3 accessing and IP processing function. 7.4.5.6.3 ET3I Board Rear Board The rear board of the ET3I is RLIB.
7.4.5.7 GIPI3 Board 7.4.5.7.1 GIPI3 Board Definition The GIPI3 is the Gigabit Ethernet interface board 3 of ZXWR RNC. 7.4.5.7.2 GIPI3 Board Functions The GIPI3 Board provides GE interface accessing and IP processing function. 7.4.5.7.3 GIPI3 Board Rear Board The rear board of the GIPI3 is RGER2.
7.4.5.8 GIPI4 Board 7.4.5.8.1 GIPI4 Board Definition The GIPI4 is the Gigabit Ethernet interface board 4 of ZXWR RNC. 7.4.5.8.2 GIPI4 Board Functions The GIPI4 board supports GE access, IP processing, and synchronous Ethernet. 7.4.5.8.3 GIPI4 Board Rear Board The rear board of the GIPI4 is RGER2.
O&M Handbook on ZTE Radio Technologies
Page 119
7.4.5.9 GLI4 Board 7.4.5.9.1 GLI4 Board Definition The GLI4 is the Gigabit line interface board 4 of ZXWR RNC. 7.4.5.9.2 GLI4 Board Functions The GLI4 board provides the interconnecting of the media plane between resource selves function. The schematic diagram of the GLI4 is show in Figure 7.13 Figure 7.13 The Schematic Diagram of the GLI4
GLI4 board is composed of 5 units: 1. 2. 3. 4. 5.
Optical interface unit, which provides GE optical port to support physical backup. Logical unit, which implements all the logical processing functions. Ethernet interface unit, which implements GE PHY and MAC functions. Service processing unit, which implements bi-directional IP packet table look-up, fragmenting, forwarding and traffic management. Queue management unit, which implements bi-directional queue management. Description of the data flow of the board:
1. 2.
GLI4 board receives the media plane data from the resource shelf/GE resource shelf through the optical port. The data from GE optical port to the board is processed by the service processing unit and then reach the switching side interface. After that, the data is send to the PSN switch fabric card. From PSN to GLI4, the data is processed by the service processing unit and is framed. After that the data is sent out via the corresponding optical port. 7.4.5.9.3 GLI4 Board Rear Board The GLI4 board has no rear board.
7.4.5.10 GUIM Board 7.4.5.10.1 GUIM Board Definition The GUIM is the Gigabit universal interface module of ZXWR RNC. 7.4.5.10.2 GUIM Board Functions GUIM performs the following functions:
O&M Handbook on ZTE Radio Technologies
Page 120
l l
Providing 32 K circuit switching for the 1 G resource shelf and the switching HUB, falling into the control plane and the user plane. Providing the clock drive on the resource shelf, inputting 8 K and 16 M signals, distributing the clock to all slots on the resource shelf after locking the phase and driving, and providing 16 M and 8 K clock for the resource boards. The principle of the GUIM is as show in Figure 7.14 Figure 7.14 The Schematic Diagram of the GUIM
GUIM is composed of the following four units: 1. 2. 3. 4.
CPU unit, which connects with the time-slot switching unit, logical unit and ethernet switching unit. It implements the configuration and management of the switching unit, logical unit and GE resource shelf. Logical unit, which implements all the logical processing functions. Time-slot switching unit, which has the capability of 16 K circuit switching. It provides an internal circuit switching network for the GE resource shelf. Ethernet switching unit, which implements the ethernet switching function of the user plane and control plane in a GE resource shelf. Description of the data flow of the board: 1. The external data, which is from each board of the shelf containing the GUIM, goes into the ethernet switching unit or the time-slot switching unit for switching processing, and then sent to the destination board or the level-1 switching interface board. 7.4.5.10.3 GUIM Board Rear Board The rear boards of the GUIM are RGUM1 and RGUM2.
O&M Handbook on ZTE Radio Technologies
Page 121
ZXWR RNC Hardware Description
7.4.5.11 GUIM2 Board 7.4.5.11.1 GUIM2 Board Definition The GUIM2 is the Gigabit universal interface module 2 of ZXWR RNC. 7.4.5.11.2 GUIM2 Board Functions The GUIM2 board has the same function as the GUIM board. 7.4.5.11.3 GUIM2 Board Rear Board The rear boards of the GUIM2 are RGUM1 and RGUM2.
7.4.5.12 ICM Board 7.4.5.12.1 ICM Board Definition The ICM is the integrated clock module of ZXWR RNC. 7.4.5.12.2 ICM Board Functions ICM performs the following functions:
l
Receiving the signals from GPS satellite, extracting and generating IPPS signals and the corresponding navigation messages (TOD message), and with this IPPS signal as the base phase-locked, generating PP2S, 19.6608MHz and system 8 K clock base required for the RNC/BTS Supporting BITS, one channel of line (8 K), two channels of GPS8K (one is from the local board and the other is from external GPS), and UIM8K as the local clock base Exporting Level 3 or Level 2 clock Selecting the clock base manually
l
Judging the clock loss and input base clock degrading
l
l
The principle of the ICM is show in Figure 7.15 Figure 7.15 The Schematic Diagram of the ICM
7.4.5.12.3 ICM Board Rear Board 5-18 O&M Handbook on ZTE Radio Technologies
Page 122
The rear boards of the ICM are RCKG1 and RCKG2.
7.4.5.13 POSI Board 7.4.5.13.1 POSI Board Definition The POSI is the POS interface board of ZXWR RNC. 7.4.5.13.2 POSI Board Functions The POSI board provides IP STM-1 interface accessing and IP processing function. 7.4.5.13.3 POSI Board Rear Board The POSI board has no rear board.
7.4.5.14 PSN Board 7.4.5.15.1 PSN Board Definition The PSN is the packet switched network board of ZXWR RNC. 7.4.5.15.2 PSN Board Functions The PSN board provides the interconnecting of GLI4 boards function. The schematic diagram of the PSN is show in Figure 7.16 Figure 7.16 The Schematic Diagram of the PSN
PSN board is composed of the following three units:
O&M Handbook on ZTE Radio Technologies
Page 123
1.
2. 3.
CPU unit, which connects with the UIMC of the switching shelf through FE to implement operation and maintenance. It also connects with the matrix switching unit through the internal control bus to implement the basic configuration and management. Logical unit, which implements the logical adaptation in the board. Matrix switching unit, which provides high-speed serial link to the external devices. It connects with GLI4 to make a data switching channel. Description of the data flow of the board: The data from each GLI4 board is sent to the matrix switching unit through the high-speed serial links on the backboard. It is switched and then sent to the destination GLI4 board. 7.4.5.14.3 PSN Board Rear Board The PSN board has no rear board.
7.4.5.15 RCB Board 7.4.5.15.1 RCB Board Definition The RCB is the control plane processing board of ZXWR RNC. 7.4.5.15.2 RCB Board Functions RCB falls into the following two types: l l
When RCB serves as RCP (RNC Control plane Processor), it processes the control plane signaling, No. 7 signaling, and GPS positioning that correspond to Iu, Iub, Iur, and Uu interfaces. When RCB serves as RSP (RNC Signaling Processor), it processes the IP signaling protocol on Iu, Iub and Uu interfaces. The schematic diagram of the RCB is shown in Figure 4.17 Figure 4.17 The Schematic Diagram of the RCB
RCB board is composed of three units: 1.
CPU unit.
The board has two set of CPU units:
CPU unit A and CPU unit B.
O&M Handbook on ZTE Radio Technologies
Page 124
2. 3.
Each CPU unit provides control plane FE electrical interface, active/standby board communication FE electrical interface, and RS232/RS485 interfaces to communicate with other units. CPU_A is at the bottom of the board and implements the main control function of the board. Logical unit, which implements all logical processing functions. Power management unit, which implements power management and distribution. 7.4.5.15.3 RCB Board Rear Board The RCB board has no rear board.
7.4.5.16 ROMB Board 7.4.5.16.1 ROMB Board Definition The ROMB is the Operating & Maintenance board of ZXWR RNC. 7.4.5.16.2 ROMB Board Functions ROMB performs the following functions: l
Serving as a master processing module and performing the global processing of ZXWR RNC.
l
Serving as a ZXWR RNC O&M agent, managing board statuses, collecting information, and maintaining global static data. In addition, OMCR communicates with the system devices through ROMB. RPU that is in charge of the route protocol processing can run on ROMB. The schematic diagram of the ROMB is shown in Figure 4.18 Figure 4.18 The Schematic Diagram of the ROMB
ROMB board is composed of three units: 1.
CPU unit.
The board has two sets of CPU units: CPU unit A and CPU unit B. Each CPU unit provides control plane FE electrical interface, active/standby board communication FE electrical interface, and RS232 and RS485 interfaces to
O&M Handbook on ZTE Radio Technologies
Page 125
2. 3.
communicate with other units. CPU_A is at the bottom of the board and implements the main control function of the board. Logical unit, which implements all logical processing functions. Power management unit, which implements power management and distribution. 7.4.5.16.3 ROMB Board Rear Board The rear board of the ROMB is RMPB.
7.4.5.17 RUB Board 7.4.5.17.1 RUB Board Definition The RUB is the user plane processing board of ZXWR RNC. 7.4.5.17.2 RUB Board Functions RUB deals with the radio user plane protocols, CS service FP/MAC/RLC/IUUP/RTP/RTCP protocol stack FP/MAC/RLC/PDCP/IUUP, GTP-U protocols.
including and PS service
The schematic diagram of the RUB is shown in Figure 7.19 Figure 7.19 The Schematic Diagram of the RUB
RUB board is composed of six units: 1. 2.
Circuit switching unit, which connects the serial ports of multiple-chip DSP with the circuit switching network. CPU unit, which manages the board and processes the signals from the Iub interface. It provides the control plane FE interface externally.
O&M Handbook on ZTE Radio Technologies
Page 126
3. 4. 5. 6.
DSP unit, which includes multiple DSP chips. It implements the functions of transcoding, rate adaptation or data packet conversions. Ethernet switching unit, which implements the Ethernet connections for multiple-chip DSP and provides the user plane FE interface externally. Clock unit, which provides necessary clock signals for the units on the board. Logical unit, which implements all logical processing functions. 7.4.5.17.2 RUB Board Rear Board The RUB board has no rear board.
7.4.5.18 SBCX Board 7.4.5.18.1 SBCX Board Definition The SBCX is the X86 server board of ZXWR RNC. 7.4.5.18.2 SBCX Board Functions SBCX performs the following functions: # Storing the log # Storing the performance data. # Local NM of the RNS. The schematic diagram of the SBCX is show in Figure 7.20 Figure 7.20 The Schematic Diagram of the SBCX
SBCX board is composed of the following five units: 1. 2. 3. 4.
CPU dual-core system, which includes CPU, memory controller and primary storage system. Peripheral interface unit, which provides multiple kind of interfaces, such as PS/2, USB and VGA. External interface unit, which provides 4 FE interfaces and 2 GE interfaces. SAS controller, which provides SAS hard disk interface and implements SAS RAID 0/1.
O&M Handbook on ZTE Radio Technologies
Page 127
5.
SAS hard disk which is in charge of the service data storage. 7.4.5.18.2 SBCX Board Rear Board The rear board of the SBCX is RSVB.
7.4.5.19 SDTA2 Board 7.4.5.19.1 SDTA2 Board Definition The SDTA2 is the ATM optical digital trunk board 2 of ZXWR RNC. 7.4.5.19.2 SDTA2 Board Functions The SDTA2 board provides the CSTM-1 interface accessing and IMA, ATM processing function. 7.4.5.19.3 SDTA2 Board Rear Board The SDTA2 board has no rear board.
7.4.5.20 SDTI Board 7.4.5.20.1 SDTI Board Definition The SDTI is the SONET/SDH digital trunk IP process board of ZXWR RNC. 7.4.5.20.2 SDTI Board Functions The SDTI board provides the IP CSTM-1 interface accessing and PPP, MLPPP processing function. 7.4.5.20.3 SDTI Board Rear Board The SDTI board has no rear board.
7.4.5.21 THUB Board 7.4.5.21.1 THUB Board Definition The THUB is the trunk hub board of ZXWR RNC.
7.4.5.21.2 THUB Board Functions The THUB provides control plane convergence between all shelves and the control shelf. Resource shelves are connected with the THUB through two FE interfaces (control stream). The THUB is connected with the UIMC board in the local shelf through GE electrical interface. The capacity of shelves can be expanded by adding FE trunks. Further capacity expansion can be achieved by connecting the GE optical interface to the GE switch.
O&M Handbook on ZTE Radio Technologies
Page 128
The schematic diagram of the THUB is shown in Figure 7.21 Figure 7.21 Schematic Diagram of the THUB
The THUB consists of the following three units: 1. CPU, which connects with the logic unit and the Ethernet switching unit through control bus and is used to configure the switching chip. The CPU also provides RS232 and RS485 serial ports externally for debugging. 2. Logic unit, which provides all logic processing functions. 3. Ethernet switching unit, which provides Ethernet switching and control-plane convergence functions. Data flow of the THUB board: 1. The control-plane data from all shelves is sent to the Ethernet switching unit of the THUB. 2. The data is sent to the UIMC board in the control shelf through GE and is then distributed to the CMP board for processing. 7.4.5.21.3 THUB Board Rear Board The rear boards of the THUB are RCHB1 and RCHB2.
7.4.5.22 UIMC Board 7.4.5.22.1 UIMC Board Definition The UIMC is the universal interface module for control plane of ZXWR RNC. 7.4.5.22.2 UIMC Board Functions UIMC performs the following functions: l Switching UIMC performs Ethernet level-2 switching inside the control shelf and the switching shelf. It also manages the control shelf. UIMC provides an internal GE electrical interface to cascade THUB inside the control shelf. l Clock distribution
O&M Handbook on ZTE Radio Technologies
Page 129
ZXWR RNC Hardware Description
UIMC provides the clock drive inside the control shelf and the switching shelf respectively. These shelves input 8 K and 16 M signals. After the phase lock and drive, the signals are distributed to each slot, providing 16 M and 8 K clock for boards. The principle of the UIMC is as show in Figure 7.22 Figure 7.22 The Schematic Diagram of the UIMC
UIMC board is composed of the following four units: 1. CPU unit, which connects with the time-slot switching unit, logical unit and ethernet switching unit. It is in charge of the configuration and management of the switching unit, logical unit and GE resource shelf. 2. Logical unit, which implements all the logical processing functions. 3. Time-slot switching unit, which has the capability of 16 K circuit switching. It provides an internal circuit switching network for the GE resource shelf. 4. Ethernet switching unit, which implements the Ethernet switching function for the user plane and control plane of the resource shelf. Description of the data flow of the board: 1. The external data, which is from each board of the shelf, goes into the Ethernet switching unit or the time-slot switching unit for switching processing, and then sent to the destination board. 7.4.5.22.3 UIMC Board Rear Board The rear boards of the UIMC are RUIM2 and RUIM3. 7.4.6 Rear Boards 7.4.6.1 Rear Board Structure The structure of the rear board is shown in Figure 7.23 Figure 7.23 Structure of Rear Board
5-28 O&M Handbook on ZTE Radio Technologies
Page 130
1. Extractor
3.
PCB
2. Panel of rear board
4.
Plug
5.
Plug
7.4.6.2 RCHB1 Board 7.4.6.2.1 RCHB1 Board Definition The RCHB1 is the CHUB rear board 1 of ZXWR RNC. 7.4.6.2.2 RCHB1 Board Functions RCHB1 performs the following functions:
Providing the external interface for THUB, at most 46 × 100 M Ethernet interface (eleven groups of 4 FE TRUNK ports) Providing one 232 debugging serial port Providing interface
one
debugging
Ethernet
7.4.6.3 RCHB2 Board 7.4.6.3.1 RCHB2 Board Definition The RCHB2 is the CHUB rear board 2 of ZXWR RNC. 7.4.6.3.2 RCHB2 Board Functions RCHB2 performs the following functions:
Providing the external interface for THUB, at most 22 × 100 M Ethernet interface Providing one 232 debugging serial port Providing one debugging Ethernet interface
7.4.6.3.3 RCHB2 Board Front Board The front board of the RCHB2 is THUB. 7.4.6.4 RCKG1 Board 7.4.6.4.1 RCKG1 Board Definition The RCKG1 is the CLKG rear board 1 of ZXWR RNC. 7.4.6.4.2 RCKG1 Board Functions
O&M Handbook on ZTE Radio Technologies
Page 131
RCKG1 provides six channels of clock output ports and two kinds of clock bases (one channel of 8 K input and one channel of BITS reference input) and one RS232 debugging serial port input interface for ICM. 7.4.6.4.3 RCKG1 Board Front Board The front board of the RCKG1 is ICM.
7.4.6.5 RCKG2 Board 7.4.6.5.1 RCKG2 Board Definition The RCKG2 is the CLKG rear board 2 of ZXWR RNC. 7.4.6.5.2 RCKG2 Board Functions RCKG2 provides six channels of clock output ports and two kinds of clock bases (one channel of RITS reference input) and one RS232 debugging serial port input interface for ICM. 7.4.6.5.3 RCKG2 Board Front Board The front board of the RCKG2 is ICM.
7.4.6.6 RDTA Board 7.4.6.6.1 RDTA Board Definition The RDTA is the rear board of DTA/DTI. 7.4.6.6.2 RDTA Board Functions The RDTA provides 32 external E1/T2 physical interfaces for the DTA board and the DTI board. 7.4.6.6.3 RDTA Board Front Board The front boards of the RDTA are DTA and DTI. 7.4.6.7 RGER2 Board 7.4.6.7.1 RGER2 Board Definition The RGER2 is the rear board of Giga Ethernet interface board for BGSN of ZXWR RNC. 7.4.6.7.2 RGER2 Board Functions RGER2 provides the following functions: l Providing GE electric interfaces for the GIPI3/GIPI4 l Providing one RS232 debugging interface and one Ethernet debugging interface 7.4.6.7.3 RGER2 Board Front Board
O&M Handbook on ZTE Radio Technologies
Page 132
The front board of the RGER2 is GIPI3 and GIPI4.
7.4.6.8 RGIM1 Board 7.4.6.8.1 RGIM1 Board Definition The RGIM1 is the general rear interface module 1 of ZXWR RNC. 7.4.6.8.2 RGIM1 Board Functions RGIM1 provides the following functions: # Providing a RS232 debugging interface for the APBE # Providing a 8 K clock output interface for the APBE 7.4.6.8.3 RGIM1 Board Front Board The front board of the RGIM1 is APBE.
7.4.6.9 RGUM1 Board 7.4.6.9.1 RGUM1 Board Definition The RGUM1 is the rear board of Gigabit universal interface module 1 of ZXWR RNC. 7.4.6.9.2 RGUM1 Board Functions RGUM1 provides the following functions:
Providing two control plane external cascading Ethernet ports for GUIM/GUIM2 Providing one debugging interface Providing one clock input interface to connect ICM.
7.4.6.9.3 RGUM1 Board Front Board The front boards of the RGUM1 are GUIM and GUIM2.
7.4.6.10 RGUM2 Board 7.4.6.10.1 RGUM2 Board Definition The RGUM2 is the rear board of Gigabit universal interface module 2 of ZXWR RNC. 4.4.6.10.2 RGUM2 Board Functions RGUM2 provides the following functions:
Providing two control plane external cascading Ethernet ports for GUIM/GUIM2 Providing one debugging interface Providing one clock input interface to connect ICM
7.4.6.10.3 RGUM2 Board Front Board The front boards of the RGUM2 are GUIM and GUIM2.
O&M Handbook on ZTE Radio Technologies
Page 133
7.4.6.11 RLIB Board 7.4.6.11.1 RLIB Board Definition The RLIB is the rear low speed interface card of ZXWR RNC. 7.4.6.11.2 RLIB Board Functions The RLIB board provides E3/T3 physical interfaces for the ET3A board and ET3I board. 7.4.6.11.3 RLIB Board Front Board The front boards of the RLIB are ET3A and ET3I.
7.4.6.12 RMNIC Board 7.4.6.12.1 RMNIC Board Definition The RMNIC is the MNIC rear board of ZXWR RNC. 7.4.6.12.2 RMNIC Board Functions The RMNIC provides the FE interfaces for the GIPI3/GIPI4. 7.4.6.12.3 RMNIC Board Front Board The front boards of the RMNIC are GIPI3 and GIPI4.
7.4.6.13 RMPB Board
7.4.6.13.1 RMPB Board Definition The RMPB is the MPB rear board of ZXWR RNC. 7.4.6.13.2 RMPB Board Functions RMPB provides external interfaces for the ROMB. 7.4.6.13.3 RMPB Board Front Board The front board of the RMPB is ROMB.
7.4.6.14 RSVB Board 7.4.6.14.1 RSVB Board Definition The RSVB is the rear board of server board of ZXWR RNC. 7.4.6.14.2 RSVB Board Functions RSVB provides external interfaces for the SBCX. 7.4.6.14.3 RSVB Board Front Board
O&M Handbook on ZTE Radio Technologies
Page 134
The front board of the RSVB is SBCX.
7.4.6.15 RUIM2 Board 7.4.6.15.1 RUIM2 Board Definition The RUIM2 is the UIM rear board 2 of ZXWR RNC. 7.4.6.15.2 RUIM2 Board Functions RUIM2 performs the following functions:
Providing five Ethernet ports for UIMC Providing one clock input interface to connect ICM Providing one RS232 debugging
interface Providing one Ethernet debugging interface
7.4.6.15.3 RUIM2 Board Front Board The front board of the RUIM2 is UIMC.
7.4.6.16 RUIM3 Board 7.4.16.1 RUIM3 Board Definition The RUIM3 is the UIM rear board 3 of ZXWR RNC. 7.4.16.2 RUIM3 Board Functions RUIM3 performs the following functions: l Providing five Ethernet ports for UIMC l Providing one clock input interface to connect ICM l Providing one RS232 debugging interface l Providing one Ethernet debugging interface. 7.4.6.16.3 RUIM3 Board Front Board The front board of the RUIM3 is UIMC.
7.5 Backplane 7.5.1 Backplane Function The front board and the rear board are inserted on the backplane. The boards on the same shelf are connected through the printing printed circuit cable on the backplane, thus greatly reducing the cables on the back of the backplane and increasing the reliability of the whole equipment.
O&M Handbook on ZTE Radio Technologies
Page 135
7.5.2 Backplane Structure The structure of the backplane is shown in Figure 7.24. Figure 7.24 Backplane Structure
4. Connector
7.5.3 BCTC Board 7.5.3.1 BCTC Board Definition BCTC is the backplane of the ZXWR RNC control shelf.
7.5.3.2 BCTC Board Functions BCTC performs the following functions: 1. Control Ethernet: The backplane provides 46 × 100 M + 1 × 1000 M control stream Ethernet access, thereinto, GE port (1 × 1000 M): To interconnect UIMC and THUB on the local shelf Outward control Ethernet gathering: THUB provides forty-six Ethernet interfaces for all resource shelves and level-1 switching shelf, for the system control stream Ethernet gathering 2. Clock reception, extraction and distribution a. Extracting 8 K clock base from a interface board and sends to ICM through the cable b. Sending the clock to UIMC through the backplane and distribute the system clock to all service slots on the shelf through the backplane c.
Providing fifteen sets of the system clock to ICM and sends to all resource subsystems through the cable
3. Power supply and ground Providing -48 V socket and -48 VGND/GND/GNDP ground
O&M Handbook on ZTE Radio Technologies
Page 136
7.5.3.3 BCTC Board Structure The structure of BCTC board is shown in Figure 7.25. Figure 7.25.BCTC
O&M Handbook on ZTE Radio Technologies
Page 137
ZXWR RNC Hardware Description
7.5.4 BGSN Board 7.5.4.1 BGSN Board Definition BGSN is the backplane of the ZXWR RNC resource shelf. 7.5.4.2 BGSN Board Functions BGSN performs the following functions: 1.
Control Ethernet The backplane provides 24 × 100 M control stream Ethernet access.
2.
User plane Ethernet The backplane provides 24 × 100 M and 21 × 1000 M user plane Ethernet access.
3.
TDM bus The backplane provides 32 K TS slot bus.
4.
Clock reception and distribution ICM sends the clock to GUIM through the cable and sends to all service slots on the 1 G resource shelf through the backplane.
5.
Power supply and ground Providing -48 V socket and -48 VGND/GND/GNDP ground. 7.5.4.3 BGSN Board Structure The structure of BGSN board is shown in Figure 7.26.
O&M Handbook on ZTE Radio Technologies
Page 138
7.5.5 BPSN 7.5.5.1 BPSN Board Definition BPSN is the backplane of the ZXWR RNC switching shelf. 7.5.5.2 BPSN Board Functions BPSN performs the following functions: 1.
Control Ethernet The backplane provides 24 × 100 M control stream Ethernet access.
2.
Clock reception and distribution a. The backplane receives the clock from ICM b. The backplane distributes the system clock to all service slots through UIMC main control board
3.
Power supply and ground Providing -48 V socket and -48 VGND/GND/GNDP ground 7.5.5.3 BPSN Board Structure The structure of BPSN is shown in Figure 7.27. Figure 7.27 BPSN
O&M Handbook on ZTE Radio Technologies
Page 139
O&M Handbook on ZTE Radio Technologies
Page 140
ZXWR RNC Hardware Description
7.6 Cable
7.6.1 Cables Overview The cables used in the ZXWR RNC system include:
Cabinet power cable Cabinet grounding cable Clock cable Ethernet cable E1/T1 cable E3/T3 cable Monitoring cable Single mode optical fiber
7.7 Accessories 7.7.1 GPS Active Antenna and Lightening Arrester
1.
7.7.1.1 Model The model of GPS active antenna is MBGPS-38, as shown in Figure 7.28. Figure 7.28 Appearance of GPS Active Antenna
1. GPS antenna 2. Installation clip
2.
3. 4.
Installation pipe 5. Feeder 6.
Pole 7. Cabling Pole Components
The lightening arrester is in grey and is made of die casting aluminum. The appearance of the model CSPIII-006 is shown in Figure 7.29
O&M Handbook on ZTE Radio Technologies 5-38
Page 141
Figure 7.29 Appearance of GPS Antenna Lightening Arrester
7.7.1.2 Functions GPS antenna lightening arrester uses two frequency-divided coaxial cable protectors. The lightening protection device is installed where the communication devices connects with the coaxial cable, or between the two communication devices. It can effectively prevent the damage on the communication device by the temporary over-voltage due to the lightening induction. This device uses high-frequency filter and take Level-3 protection on the DC feeder path. The product has less RF insertion loss, large current capacity, and low limited voltage. In addition, it has all functions of the frequency divider. It is the ideal protection device for all common antenna communication devices.
7.7.1.3 Connection Description The connection description of ICMG and GPS antenna lightening arrester (fixed on the cabinet top) or GPS antenna is shown in Figure 7.30 Figure 7.30 Connection Description of ICMG and GPS Active Antenna/Lightening Arrester
1.
GPS antenna 2. GPS antenna lightening arrester
7.7.2 Alarm Box 7.7.2.1 Compositions Alarm system gives users quick and timely information on the defective issues occuring to the equipments. In the case of a failure with the communication system or any improperly operating status of the system, the equipment sends the alarm information to the background
O&M Handbook on ZTE Radio Technologies
Page 142
server through which users may review the current alarm or historic alarm. Also the server sends the alarm information to the alarm box which makes audio and visual alarms as well as sending alarm message to the cell phone number predefined. The alarm system consists of the alarm server (usually the OMC server) and the alarm box, as shown in Figure 7.32.
Figure 7.32 Alarm System
l l l
The alarm server allows the administrators to set such parameters as the levels of alarms to be sent to the alarm box, the mobile phone numbers to send alarm SMS messages. The alarm server sends alarm messages to alarm box through TCP/IP protocol, and the mobile phone module in the alarm box delivers the alarm SMS messages to the mobile phone number as specified. The alarm box then displays the alarms on LCD screen with alarm indicators, alarm server indicators and alarm sounds.
7.7.2.2 Functions The alarm box is connected to the alarm server through the hub to receive alarm data from the server. It reports alarms with alarm indicators and sounds for different alarm severity. Meanwhile, it displays alarm messages on the LCD. l
l l
l
l
l
Through proper settings on the alarm server, the built-in mobile phone module in the alarm box sends current alarms to the mobile phones of the maintenance staff. Alarms can be set according to preset severity levels. Alarm box supports CDMA or GSM system, but not both. Audio alarm: the built-in speaker of the alarm box reports alarms with beeps and the current alarm severity with real voices. Alarm Indicator: alarms of different severity levels are indicated by LEDs of different colors (yellow, amber, blue and red in the ascending order of alarm severity). Alarm server indicator: the alarm box panel has 10 LED indicators that are connected to 10 groups of alarm servers (usually 10 servers). The indicators report the status of each group of alarm servers, such as link status, alarm status, etc. LCD display of alarm information: the alarms from alarm server are displayed on the LCD screen of the alarm box. Users may press the alarm menu and panel buttons to set the alarm box parameters, such as the IP address, the UIP port number, button sound switch control, and backlight control. Remote access: the alarm box can connect to a server in the same network segment, or a remote server in a different network segment. In the latter case, a route on the alarm box is needed. Therefore, the alarm box need not be placed in the computer room. It can be placed in the office or the meeting room, which increases its flexibility. Multiple office integration: the alarm box supports up to 128 alarm servers, which can be classified into 10 groups. Usually, these servers are not in the same network segment, so this function needs support from the remote connection function.
O&M Handbook on ZTE Radio Technologies
Page 143
l
l
l l l
Support inter-VLAN alarm servers: the alarm box may be connected to the alarm servers in different VLANs through the layer-2 switch. This cross-VLAN connectivity eliminates the need for a high-cost layer-3 switch, while ensuring the separation of alarm servers from each other. Network storm detection and alarm: proper setting of the network storm threshold on the alarm box helps you to avoid network congestion caused by data broadcast. Alarm group identification: the alarm box confirms alarms on the per-group basis. Static query of the alarm information: the alarm box can query the statistical data of alarms of different severity levels on connected alarm servers. Permanent muting: user may mute the alarms according to their severity levels on the alarm box. Remote operation: users may log in to the alarm box with Telnet, and complete alarm server configuration, router configuration, VLAN configuration, SMS parameter configuration and time parameter configuration with MML command
Chapter 8 ZTE RNC (ZXWR) Emergency Maintenance O&M Handbook on ZTE Radio Technologies
Page 144
___________________________________________________ 8.1 Overview Emergency maintenance is to deal with the emergent faults. When some emergent faults occur on the system or the equipment, to remove the faults quickly, to restore the system or the equipment, the emergent measures help to retrieve or to reduce the loss. During the operation, due to the external or internal causes, critical faults may occur on some parts and functions of ZXWR RNC. In these cases, do start the emergent fault troubleshooting flow immediately. According to the prompt message, signaling trace (that is, calling trace), and error logs, determine the fault range, find the fault cause, and deal with the faults.
8.1.1 Basic Principles of Emergency Maintenance
Emergency maintenance is to recover the normal running of the equipment quickly. The premise is that the system runs normally before an emergent accident occurs. Observer the following basic emergency maintenance principles: l In the routine maintenance, the operators can refer to ZXWR RNC emergency maintenance documents, past fault analysis and experience in handling the faults. l Operators should, on a regular basis, organize related management personnel and maintenance personnel for study and drill. Related maintenance personnel should know more about the system in the routine maintenance, especially the common exception information of OMC alarm and the flashing of ZXWR RNC panel indicators. They should skillfully use the common tools such as data backup and recovery tool. When the emergent accident occurs, the maintenance personnel should keep a sober mind first. Check whether the hardware and transmission of ZXWR RNC is normal, and judge whether this accident results from ZXWR RNC. If so, deal with the fault according to the emergency accident handling plan or refer to the related procedures provided in this manual. l Before/During/After handling the emergency, the maintenance personnel should collect the equipment alarm information related to this accident and send relevant fault handling report, equipment alarm file and log file to ZTE CORPORATION for fault analysis and location, so that it can provide better after-sales services for carriers. l When major faults occur on the site, recover the services within as short time as possible. Meanwhile, before performing the switch, reset, and reboot, open the fault positioning analysis tools, such as, NM alarm and signalling tracing, keep the information that the fault positioning and analysis need.
O&M Handbook on ZTE Radio Technologies
Page 145
8.2 Emergency Maintenance Flow 8.2.1 Flow of Emergency Maintenance
The flow of the emergency maintenance is as shown in Figure 8.1. Figure 8.1 Flow of Emergency Maintenance
It involves the following steps: 1. 2. 3. 4.
Check services. Record abnormalities and output Abnormality Record Table. Make initial location and analysis of faults. Launch the emergency aid, record and send Equipment Emergency Maintenance Requisite. 5. Recover services. 6. Observe services. 7. Make records of information and fill in Troubleshooting Record Table.
8.2.2 Checking Services Context When an emergency fault occurs, check the services according to the following steps: 1. Go to the cabinet immediately to check the power supply. If the power failure occurs in large area, inform the power supply maintenance persons to recover the power supply.
O&M Handbook on ZTE Radio Technologies
Page 146
Shut down the power supply of the cabinets one by one. Power on after the power supply is stable. 2. If the external power supply is normal, after reading the users’ complaints, observe the calling status of all offices from the performance statistics console. Determine the fault occurrence range, in all offices or in some offices. If the fault occurs only in some offices, contact the personnel in the offices, checking the interface state and link state, positioning the fault range, and determining whether the fault is on the local office. If not, deal with the peer office. If so, go to Step 3. 3. Check whether the indicator status on the hardware boards is normal. Check whether the physical connection and link with other element is normal. If so, contact the maintenance personnel of other element for the troubleshooting, or find the possible source by referring to the emergency maintenance manual of other element. 4. If there is no obvious hardware fault on the boards, check whether the software and the data has problem. After observing OMC client alarm information, check whether there is alarm of the board abnormality or link abnormality. If all is normal, check whether the radio resource cell status is normal, whether the physical connection and link with other element is normal. Try to recover quickly: Checking the operation logs, checking whether the system is down due to data mis-modification or deletion (through checking MML operation logs and alarm time, judging the relativity of the operation and fault). IF so, recover the data. 5. If all is normal, contact the personnel of other element (such as, Node B, CN) for the troubleshooting, or find the possible source by referring to the emergency maintenance manual of other element.
8.2.3 Fault Records Before/During the start of the emergency recovery plan or the fault recovery, make records of the running version and phenomena in the abnormality table. Back up OMC configuration data properly. The abnormality record is very useful in emergency aid and the subsequent problem analysis and summary. Therefore, be sure to fill a complete abnormality record.
8.2.4 Initial Location and Analysis of Fault Causes
Pick up relevant data about alarm, performance, and printing, and analyze obvious phenomenon about network fault. Observe the information of equipment operation, and board indicator. Check the fault caused by ZXWR RNC equipment or other reasons, and determines its involved scope.
O&M Handbook on ZTE Radio Technologies
Page 147
If the fault is located as being caused by the ZXWR RNC equipment, you shall analyze field alarms, performance, signaling, and printing log, and do troubleshooting after finding proper fault point. Locate and analyze the fault based on the following three aspects: 1. Service faults often begin with user complaints, so you shall register the user number. Analyze the base station where the complaint user is located in accordance with different tools at radio and CN sides, to locate and analyze the fault. l Use signaling trace and probe to find out CN, RNC, or Node B where the complaint user is located, to locate and determine fault related equipment. l If you can't determine the location of complaint user at the RNC side, you shall search for help from the CN side. 2. Determine fault scope through the analysis of KPI index. Query relevant indices in KPI to determine the affected base station scope about the fault. l Determine whether it is a global fault based on the faulty base station. l Determine whether it is associated with the module and specific board based on the faulty base station. 3. Test arrangement. If possible, arrange test at specific area, and provide more accurate information on emergency maintenance.
8.2.5 Service Recovery If the methods provided in this manual and remote emergency aid cannot help to locate faults and recover services, switch, reset and replace boards to recover the system service. These operations may give a great impact.
Board handover, reset and replacement may have a great influence on the system running. Make records of the current status before any board handover and physical location change. Make records of each step and symptom occurring in the service recovery on the site.
8.2.6 Service Observation After the service recovery, make a further check to see whether the system has recovered completely, to avoid any other problems. Observe by referring to ZXWR RNC (V3.07.310) Radio Network Controller Trouble Shooting and ensure the normal running of the services. In addition, arrange attendants in the period of service peak to make sure to solve the problem in time (if any problem occurs).
O&M Handbook on ZTE Radio Technologies
Page 148
8.3 Emergency Maintenance on Abnormal Services
The following describes procedures to check ZXWR RNC emergency faults. The handling procedure can change with specific situation. For example, skip Steps 3 and 4 if there are no modifications on the configuration data. 1. 2. 3. 4. 5. 6.
Check the power supply. Handle the user service interruption caused by ZXWR RNC board fault. Check the system clock working status. Handle the user service interruption caused by abnormal transmission. Handle the user service interruption caused by abnormal radio cell. Handle the user service interruption caused by the wrong modification of ZXWR RNC radio configuration data.
8.3.1 Handling Service Interruption Caused by Board Abnormality This section describes several types of board that have a close tie with the normal running of services. They are to facilitate rapid location and troubleshooting of faults. 1. Interface unit: APBE, DTA, DTT, SDTT, GIPI4, SDTA2, and GIPI3, which mainly provide the data access of ZXWR RNC Iu/Iub/Iur interface and are the termination of AAL2/AAL5/ATM and IP over E1 link layer processing. Here, APBE provides the optical fiber access (STM-1), and the optical interface SD on the panel indicates its connection status. DTA/DTT supports E1 access and E1 indicator on the panel indicates E1 connection status. SDTI and SDTA2 provide channelized CSTM-1 access.GIPI4 is the Giga IP interface board of ZXWR RNC and provides IP access and OMCB gateway. 2. Switching unit: PSN, GLI, UIMC, UIMU, CHUB, THUB, and GUIM, which provide the inter-board service exchange platform. 3. Processing unit: RCB and RUB, which process the upper layer protocols of ZXWR RNC control plane and user plane. Generally, the alarm function of OMC client and the flashing status of ZXWR RNC rack board can help to judge the failed board and its causes. 1. Log on to OMC unified client and click Tool > Alarm Management. Check OMC alarm function of ZXWR RNC NM, and then check whether there is any board alarm the type of the alarm board. 2. Observe other indicators of the board. The following is examples for the flashing of common indicators. a. Check ENUM on the board. In normal cases, it is solid OFF. If the indicator is solid ON or flashes, the board is out of position. Unplug and plug it to observe the status again.
O&M Handbook on ZTE Radio Technologies
Page 149
b. If RUN indicator slowly flashes (frequency: 1 time/s) and ALM is solid OFF, the board is running normally. If other indicators flash, the board is not running normally at this time. If RUN is solid OFF, the board fails in self-test. If both RUN and ALM flash slowly (1 time/s), this board is under active/standby changeover. Wait for a while to see whether the board recovers to its normal status. c.
Check ACT on the board. If it is solid ON, this board is an active board while if it is solid OFF, the board is a standby one. This indicator is to locate active/standby changeover failure.
Proposals for handling such fault: 1. The alarm management information of ZXWR RNC OMC NM generally indicates the alarm causes and recommended operation to eliminate this alarm. Perform related operations according to such information. 2. Wait for ZXWR RNC board to recover to its normal status, and observe whether the user service restores to normal. If indicators flash abnormally for long during the board running and the NM alarm still exists, try the following operations: 1. Reserve the alarm information. 2. Reset the alarm board or replace the board.
Resetting ZXWR RNC boards may have a huge influence on services. Such as, if you reset RUB, it is necessary to re-create all cells and user services on this board. if you reset the interface board, it is necessary to re-create all bearers allocated on this board. Therefore, please proceed with caution. 8.3.2 Handling Service Interruption Caused by Transmission Abnormality
Check with the following methods to judge the user service interruption caused by abnormal transmission: 1. On OMC unified UMS client, check the status of the transmission links, such as NCP, CCP, ALCAP, MTP3B links, association and see whether it fails. 2. On OMC unified UMS client, check whether there is any resource alarm for the cell public transmission channel, No.7 link, NCP, CCP, and association. Check whether the alarm exists constantly and cannot recover. 3. In the case of ATM transmission mode, check the optical interface SD and E1 indicator of the interface board, to judge the transmission line for normality. a. For APBE, check the optical interface SD. The indicator is solid on during the normal communication. Otherwise, there may be faults with the optical fiber. b. For DTA, check and make sure that the E1 indicator is slowly flashing (1 time/s) during the normal communication; otherwise, there might be something wrong with the E1 connection.
O&M Handbook on ZTE Radio Technologies
Page 150
c.
For DTT, check and make sure that the E1 indicator is slowly flashing (1 time/s) during the normal communication. Otherwise, there may be faults on the connection. For example, solid on indicates E1 link configuration but blocked.
4. In the case of IP transmission mode, check GIPI, GIPI3, and DMP. DMP is to deal with the system signaling processing data. GIPI4 provides ZXWR RNC external IP interface. When the fault occurs on GIPI, the communication between ZXWR RNC and other elements disconnects. Check with the following methods to judge the working status between GIPI4, GIPI3, and DMP. a. Check RUN on the panel. When the communication is normal, RUN is flashing slowly (one/1 s). If it is abnormal, check whether the IP cable connection is normal first, and then check to see if there is any failure alarm about the port on the GIPI4. b. Check whether ALM on the panel is ON. c.
Query whether GIPI4/DMP CPU occupation ratio reaches 100% on the cabinet diagram on Equipment Resource Management of NMS.
Proposals to handling the link resource faults: 1. Check whether the data to be negotiated by such external NEs as Node B, CN and ZXWR RNC are consistent (such as NCP, CCP, MTP3B link, ATM address, and IP address). If there is any abnormal configuration data, the cause may be local NE or other NEs have modified the configuration data. Make confirmation and modify them. 2. If there is not abnormality, perform the self-loop on optical interface or IMA group at ZXWR RNC side. 3. If the conditions allow (for example, the distance between NEs is very small), perform the self-loop at the corresponding remote NE according to link fault location. For example, for Iub link, perform the self-loop on the optical interface of the interface board at Node B side. For Iu interface, perform the self-loop on the optical interface of the interface board at CN side. 4. If the fault disappears after the local self-loop, the cause may be the abnormal running of the peer NE. If the peer NE becomes normal after the self-loop, the cause is transmission network configuration fault. 5. If the fault still exists after the self-loop, check the optical fiber for damages and exposing. 6. For IP network, when all equipment is running normally, if the global services disconnect, the maintenance personnel should examine whether IP network is running normally first. a. Check the association status in NM configuration management. If the association is not in service status, recreate the association. If the creation fails, connect the cable from the interface to the debugging machine. Set the IP address of the debugging machine as the local interface IP address and check the IP network through PINGing the peer interface IP address. b. In the performance counter, check the office IP link type QoS statistics. Know the accessibility of the peer IP address according to the packet loss rate.
O&M Handbook on ZTE Radio Technologies
Page 151
c.
With the dedicated instrument or software, test the transmission delay, error bit rate, jitter of the IP network, confirming whether such faults as network blocking, network thunderstorm, and virus attack, occur in the IP network.
7. If the problems fail to be solved with all above methods, launch the emergency aid, or reset the interface board.
8.3.2.1 Methods for Handling Transmission Alarms l Determine the fault type through comparison When the alarm exists on some interface boards, if allowed, change the boards or connect cables to determine whether the alarm is related to the board or office. l Locate the fault through loopback OMCR test management interface provides different loopback settings for the interface board, including line loopback of optical path, test loopback of optical path, line loopback of optical path at the system side, line loopback of E1, and test loopback of E1. 8.3.2.2 Causes for Transmission Alarms l LOS, LOF The cause may be that the REG device directly connecting the interface board is faulty or the pigtail/flange between the local-end ODF and the equipment is faulty. AU-AIS, AU-LOP, HP-UNEQ, HP-PLM The cause is that the SDH transport network does not enable/configure the higher order path. l TU-AIS, TU-LOP, LP-UNEQ, LP-PLM The cause is that the lower order path is not established in SDH transport network or the DXC configuration does not meet the requirement of networking. l E1-AIS, E1-LOF The cause is the connection fault between the opposite exchange and the SDH transport device, such as, E1 cable connection fault. l RS-TIM,HP-TIM,LP-TIM The cause is that the values of local J0, J1, and J2 are inconsistent with the configurations of SDH transport device. Alarms of these three types do not affect the services. To eliminate the alarms, obtain the values of J0, J1, and J2 related to the transport device through the query opposite configuration and then modify the values in the database. l RS-FERF, HP-FERF, LP-RDI, E1-RAI Check whether there are near-end alarms on the corresponding layer first. If there are, eliminate the near-end alarms on the opposite, eliminate them first.
O&M Handbook on ZTE Radio Technologies
Page 152
Specially, for E1-RAI alarms, contact the maintenance personnel of the opposite exchange to confirm whether the E1 frame format is same as the local end. E1-SLIP If E1–SLIP occurs when the board is running normally, the cause is the clock fault. 8.3.3 Analyzing RNC Fault Coverage
How to analyze the RNC fault coverage is described in Table 8.2. Table 8.2 RNC Fault Coverage Analysis Fault Coverage
Possible Causes
Recommended Solutions
All CS and PS services in the whole network are blocked.
Power failure
Check the power supply.
CN-side failure
Check the CN side.
All CS services in the whole network are blocked.
CN-side failure
Check the CN side.
All PS services in the whole network are blocked.
CN-side failure
Check the CN side.
All CS and PS services in a single RNC are blocked.
APBE fault
Check
Incorrect configurations corresponding to the office at the CN side
replace it if necessary.
APBE fault
Check
SS7 link fault
replace it if necessary.
All CS services in a single RNC are blocked.
the
board
Modify office configurations. the
and
direction
board
and
Check SS7 configurations. All PS services in a single RNC are blocked.
APBE fault
Check
the
board
SS7 link fault
replace it if necessary.
and
Check SS7 configurations. All services of a resource shelf are blocked.
UIM fault
Check the UIM and replace
GLI fiber fault
it if necessary.
CHUB connection fault
Check the GLI fiber and the GLI port. Check the CHUB connection and the CHUB port.
All services of a module are blocked.
CMP
RCB fault
O&M Handbook on ZTE Radio Technologies
Switch over the RCB. Replace the failed RCB.
Page 153
All services of an IMA are blocked.
IMA fault
Check the IMA and replace
Media plane fault
it if necessary. Take further measures as required according to the media plane test.
Fault Coverage
Possible Causes
Recommended Solutions
All services of an SDTA2/SDTI are blocked.
SDTA2/SDTI fault
Check the SDTA2/SDTI and
Fiber channel fault
replace it if necessary. Check the fiber channel to which the SDTA2/SDTI corresponds.
All services of a DTA/DTI are blocked.
DTA/DTI fault
Check the
DTA/DTI and
RDTA fault
replace it if necessary. Check the RDTA replace it if necessary.
All services of a Node B are blocked.
and
IMA group fault
Check the IMA group and
Node B fault
analyze the symptoms. Check the Node B.
All services of a cell are blocked.
Incorrect cell configurations
Check cell configurations.
Manual blocking
Unblock the cell.
8.3.4 Handling RNC Service Abnormality and Interruption 8.3.4.1 HandlingIu Interface Faults Iu interface faults mainly include: a) the SS7 cannot reach the Iu interface; b) services cannot be connected; c) calls cannot be got through; d) downloading or browsing cannot be activated; and e) the “signaling point unreachable” alarm occurs in the background. Iu interface faults are basically signaling link faults, which are usually caused by incorrect data modifications, board failures or transmission link abnormalities. How to analyze Iu interface faults are described in Figure 8.3. Figure 8.3 Analyzing Iu Interface Faults
1. Many calls cannot be got through, or the Internet cannot be accessed and the terminal cannot be activated. 2. Check alarms on the background NM alarm management interface to see if there is any “office direction unreachable” alarm, and if the alarm occurs in all RNCs. If so, the fault lies in the CN. If the fault only occurs in one or several RNCs, it is possibly caused by RNC-side problems.
O&M Handbook on ZTE Radio Technologies
Page 154
Recommended Solutions 1. Check to see if all tables are synchronized for the data modifications of the whole network or a single RNC. If so, recover the data. 2. Check to see if there is any alarm about inaccessible calls or unreachable signals in all RNCs. If so, check the CN side. 3. Check to see if there are frequent SSCOP link establishments and disconnections (The message is “BGN, END”.) Make sure that the PVC bandwidth and the PVC type of both sides of the Iu interface are identical. 4. Check the optical interface indicator of the RNC interface board. If the SD indicator is off, check to see if the fiber connection is correct. If yes, reset or replace the APBE and the interface board. If the SD indicator still off, check the CN side. 5. If the SD indicator is on, replace the interface board. If the problem still exists, check the CN side.
8.3.4.2 Handling Clock System Faults Fault Analysis 1. The “clock reference lost” alarm occurs on the background NM alarm management interface. The indicator on the clock board is not in the tracing or holdover status. 2. The “16M clock lost” alarm or the “clock drive lost” alarm occurs on the UIM/interface board of the resource shelf. The UIM alarm indicator is always on. How to analyze the clock system faults is described in Figure 8.4.
Figure 8.4 Analyzing Clock System Faults
O&M Handbook on ZTE Radio Technologies
Page 155
Recommended Solutions 1. If the “clock reference lost” alarm occurs on the clock board, check to see if the clock output connection on the RGIM is correct and if the connection is loose. 2. Conduct an active/standby changeover to the interface board or the optical interface. 3. If the alarm still exists after step 2, conduct an active/standby changeover to the CLK clock board. 4. If the alarm remains after the above three steps, replace the rear board of the CLK clock board and replace RGIM. 5. If the resource shelf reports the 16M clock driving alarm, take the following measures: a. Check the clock cables on the rear board of the UIM to see if they are connected correctly and if there is any loose connection. b. Conduct an active/standby changeover to the UIM, with the driving clock being provided by the standby UIM. c.
Replace the UIM, or replace the board whose driving clock fails.
8.3.4.3 Handling Call Failures
Call failures can be caused by many reasons, including faults arising from RCB/RSB control plane and signalling processing, Iu interface board, and the CN side. It is recommended to identify the fault coverage of call failures according to subscribers’ complaints, on-site test, and signalling tracing. If the CS service cannot be connected in only a few cells, the fault is possibly local. If no call can be got through in all cells of the Node Bs in an RNC, it is probable that the Iu interface fails possibly due to RNC interface board fault or CN processing fault. If the CS service cannot be processed in only a single cell, it is recommended to fix it through routine maintenance and troubleshooting. How to analyze call failures is described in Figure 8.5
Figure 8.5 Analyzing Call Failures
O&M Handbook on ZTE Radio Technologies
Page 156
1. If no call can be got through in many RNCs or throughout the network, the problem lies in the CN side. If the failure only occurs in some areas, the problem lies in the RNC. 2. Check the SS7 link and the AAl2 channel (Iu office direction) through the background dynamic management interface to see if they are in normal condition. 3. Check to see if the APBE operates normally. Check the background alarm management interface to see if there is any APBE fault alarm. 4. Check the background alarm management interface to see if there are many alarms about failed common channels or out-of-service cells. 5. Check to see if the cells in which no call can be got through belong to the same interface board or RCP. 6. Check to see if call failures occur regularly. If the call fails once per several times of calls, it is possible that one of the AAl2 channels at the Iu interface fails. Recommended Solutions 1. Check to see if the RNC data configuration is modified before the failure occurs. If so, recover the configuration by importing the backup data. 2. Check the SS7 link. If it is abnormal, handle it by following the criteria to analyze RNC fault coverage. 3. Reset or replace the interface board. 4. If step 3 doesn’t work, conduct an active/standby changeover between No.3 and No.4 module, setting the active module to the standby board. 5. Reset the interface board to which the failed cell belongs.
8.3.4.4 Handling Mute Calls Fault Description Unilateral or voiceless conversations occur during speech calls. These faults can be caused by any failure arising from UE, air interface, Node B, RNC user plane, and CN. In unilateral conversations, data packets cannot be transmitted correctly between the calling party and the called party, resulting in that only one party can hear the voice. It is difficult to find the problem because there are many network elements involved. Generally, such a problem can be located by two means. One is to check statistics; the other is to make a CS loopback test. How to analyze mute calls is described in Figure 8.6. Figure 8.6 Analyzing Mute Calls
O&M Handbook on ZTE Radio Technologies
Page 157
Fault Analysis 1. When either party or both parties cannot be heard in a speech call, replace the UE first, and then make a test call in the same environment. If the fault does not occur any more, the problem probably lies in the UE. 2. If unilateral conversations still occur after testing different brands of UEs for many times, the problem possibly lies in the system. 3. Use two UEs to make a test call, and do an uplink loopback test and a downlink loopback test on the calling party or the called party in the signalling tracing system. If you can hear your voice from the calling UE during the uplink loopback test, it means that there is no problem from the UE to the RNC, and the problem possibly lies in interface board or the CN side. If not, the problem possibly lies in the user plane or the Iub interface. Recommended Solutions 1. Check to see if a global data modification is made before the failure occurs. If so, recover to the pre-modification data. 2. Replace the UE. If the failure does not occur any more, the problem lies in the UE. Report it to the UE maker for solution. 3. Reset APBE (Iu interface board). 4. If the fault still exists after step 3, reset the RUB where services are bourne (To check the RUB, enter the command UcpmcGetInstNo “IMSI” in the RDS to get the “inst No”, and then enter the command “UcpmcShowInstNo, 3” (instNo is the instance number) to find the slot of the RUB corresponding to the instance number). 5. Reset the IMA/APBI/DTA to which the failed cell belongs. 6. If the problem remains after all these steps, contact personnel at the CN side for troubleshooting.
8.3.4.5 Handling Download and Webpage Access Failures after Activating PS Services Fault Analysis 1. When a data card or a mobile phone processes PS services, it cannot open webpages or download data through FTP after the PS service is activated. Through the signalling tracing system, it is found that the signalling service can run correctly. No webpage can be accessed through the UE. There is no alarm on the background alarm management interface. If the webpage access failure occurs in all cells, the problem possibly lies in the Iu-interface user plane. If the failure only occurs in several cells, the problem possibly lies in the poor quality of the air interface. It is recommended to handle it by following the instructions in troubleshooting manuals. 2. Make a packet transmission test to the UE by using the tool in the signalling tracking system. If the UE downloads data at a normal rate during the test, it means that there is no problem from the UE to the RNC user plane. 3. Make a ping packet test. If no problem is found during the test, the problem possibly lies in the Iu interface, or the IP packet limitation made at the CE/CN side. 4. Replace the UE. If the download and webpage access failures does not exist any more, the problem lies in the UE. Contact the UE maker for solution.
O&M Handbook on ZTE Radio Technologies
Page 158
How to analyze download and webpage access failures after activating PS services is described in Figure 8.7
Figure 8.7 Analyzing Download and Webpage Access Failures after Activating PS Services
Recommended Solutions 1. Check to see if the data configuration is modified before the failure occurs. If so, recover the configuration by importing the backup data. 2. Reset the GIPI, which segments and regroups packets. If the failure still exists, replace the interface board. 3. If the failure remains, conduct an active/standby changeover to the UIM. 4. If the changeover doesn’t work, reset the RUB where the PS service is established. 5. If the failure remains after all these resets, ask personnel at the CE and the CN sides for troubleshooting to see if the problem is caused by the MTU packet limitation.
8.3.5 Handling Node B Service Abnormality and Interruption 8.3.5.1 Handling Large-Scale Cell Outages Cell outages are mainly caused by NCP link or CCP link disconnections, SCTP disconnections, and common channel establishment failures, which then result in cell establishment failures or repeated deletions and creations of common channels. Generally, the alarms about NCP/CCP/SCTP link disconnections are caused by transmission- and signalling processing-related problems, which should be analyzed through such information as the location where the alarm is generated and the module to which the cell belongs. Fault Analysis 1. Check the NM to see if large-scale cell outages occur to all RNCs, and if all transmissionrelated boards generate alarms. If so, the problem probably lies in transmission. 2. Check the alarms on the NM alarm management interface. If the interface board generates many E1/IMA/SCTP link alarms, the cell outage is possibly caused by transmission-related problems. For IP transmission, check to see if there is any conflict in terms of MAC address or IP address.
O&M Handbook on ZTE Radio Technologies
Page 159
3. If there are cell outage alarms but no interface board transmission failure alarms in the NM system, the problem may be caused by RCP failure. 4. If cell outages only occur to several interface boards, the problem possibly lies in the Iub interface board. How to analyze large-scale cell outages is described in Figure 8.8. Figure 8.8 Analyzing Large-Scale Cell Outages
Recommended Solutions 1. Check to see if a global parameter modification is made before the failure occurs. If so, recover the configuration by importing the backup data. 2. If all out-of-service cells belong to the same module and the transmission interface board generates no alarms, conduct an active/standby changeover to the home RCB module. 3. If all out-of-service cells belong to the same resource shelf and the transmission interface board generates no alarms, conduct an active/standby changeover to the UIMU. 4. If all cells that belong to an interface board are out of service, reset or replace the APBE/SDTA.
8.3.5.2 Handling Absence of Cell Signals and Low Success Rate of RRC Establishments The absence of cell signals is mainly caused by failures arising from common transmission channel establishments, system message broadcasts, and UE-dedicated radio link (on Node B) releases, or by transmission bandwidth resource leakage. Such problems are analyzed by checking fault notifications, QoS alarms, success rate of RRC establishments, and users’ complaints, or by making tests. How to analyze the absence of cell signals and low success rate of RRC establishments is described in Figure 8.9. Figure 8.9 Analyzing Absence of Cell Signals and Low Success Rate of RRC Establishments
O&M Handbook on ZTE Radio Technologies
Page 160
Fault Analysis 1. Check the NM NM interface to see if there are QoS alarms about the success rate of RRC establishments. If so, it means that the current common transmission channels are established successfully and the UE has initiated RRC establishments. 2. Check the NM alarm management interface to see if there are notifications about system message update failure. If so, it means that broadcast messages cannot be delivered and the UE cannot access the network correctly due to the update failure. 3. Connect an LMT to the site to see if the BCH packet transmission increases normally. If not, it means that the Node B fails to deliver broadcast messages. 4. Conduct ALCAP and FP signalling tracing through RNC or LMT signalling tracing to see if the transmission allocation and the FP synchronization fail during RRC establishments. Recommended Solutions 1. Check to see if a global parameter modification is made before the failure occurs. If so, recover the configuration by importing the backup data. 2. If there are notifications about system message update failure, modify the SIB1 value of the cell and trigger the system message once to refresh the updating process. 3. If the Node B fails to deliver broadcasts, or if the transmission allocation and FP synchronization fails, block and unblock the cell. 4. If all these steps don’t work, reset the Node B.
8.3.6 Handling OMM/NetNumen U31 Abnormality and Interruption Fault Description Generally, the symptom is that the Client cannot log in the Server. How to analyze OMM and NetNumen U31 abnormality and interruption is described in Figure 5.10.
Figure 8.10 Analyzing OMM and NetNumen U31 Abnormality and Interruption
Handling Steps 1. Check to see if the communication between the Client and the Server is normal.
O&M Handbook on ZTE Radio Technologies
Page 161
a. Ping the IP address of the Client and the Server to see if the communication is normal. If the IP address can be pinged through, but the packet loss rate is high and the network is intermittent, check to see if there is another computer with the same IP, if the dhcp function is enabled illegally in any computer in the internal network, and if the physical connection of all NEs is correct. b. If the IP address cannot be pinged through, check the physical connection between the Client and the Server for abnormality. If the Server and the Client are not in the same subnetwork, use the command netstat–r to check if the Server and the Client can communicate through the router. If not, add a route by running this command: route addsxx.xx.xx.xx (network IP address) -netmask xx.xx.xx.xx (subnet mask) xx.xx.xx.xx (gateway IP address); for example: #route add 192.168.0.0 -netmask 255.255.255.0 10.11.201.254 This command will add a route to the 192.168.0.0 network section, with the gateway IP address being 10.11.201.254. The routes added by this means will not exist anymore after the operating system is restarted. Therefore, it is required to write the route configuration command in the startup script; for example, at the end of the /etc/rc3 file. c.
Check to see if the router is configured correctly.
8.3.7 Handling Overload Handling MP CPU Overload Fault Description The MP CPU overload alarm occurs. The performance statistics shows that the average MP load is above 60%. The fault is mainly caused by insufficient traffic planning, traffic burst, and UE registration burst. How to handle MP CPU overload is described in Figure 8.11.
Figure 8.11 Handling MP CPU Overload
O&M Handbook on ZTE Radio Technologies
Page 162
Recommended Solutions 1. How to handle MP overload caused by increased traffic. During the MP overload period, keep a close eye on the MP load. If the load is above 80%, block some cells manually to lower the load. Modify the corresponding parameters when the MP load is relatively low. Modify the access parameters to reduce the retransmissions of RRC connection requests. Modify the location update parameters to reduce the periodic location updates. Make the modifications according to the MSC. The modified parameters must be lower than the values set in the MSC. If all RCP modules are not evenly loaded, modify the number of sites that belong to these RCP modules. 2. How to handle MP overload not caused by increased traffic. Check to see if the MP runs normally. Check the history alarms of the MP. Log in the OMCR Client and click View > Fault Management > Management View > View History Alarms. If there is any abnormality, conduct an active/standby MP changeover, or replace the MP. Log in the OMCR Client and click View > Configuration Management > Active Config Set > RNC Ground Resource > RNC Rack. Check to see if the MP board is in an abnormal color status. Click the MP board to make an active/standby changover. Check to see if signalling tracing and RTV measurement are enabled. If so, disable them. Go to the MP-related logs and send them to the UMTS troubleshooting team.
8.4 Data Backup and Recovery Before handling ZXWR RNC emergency faults, back up the configuration data first. On one hand, the fault recovery may involve configuration data modification, and the data can restore
O&M Handbook on ZTE Radio Technologies
Page 163
onsite status to avoid the worst case during the emergency fault recovery. On the other hand, reserve the first-hand information for ZTE’s maintenance and technical support personnel and the technicians at the home front, helping to analyze and locate problems and improving the system performance. There are two methods to back up and recover ZXWR RNC configuration data: l Create the database maintenance task. After creating the database maintenance task, the system can automatically back up the specified maintenance table according to the maintenance time set by the task. l Manual backup and recovery of data table If necessary, manually back up and recover the data table at any time. This method is quicker and more flexible, better option in the emergency cases.
Chapter 9 RF Optimization _____________________________________________________ O&M Handbook on ZTE Radio Technologies
Page 164
9.1
Optimization and Drive Test
A typical set of data required to be maintained for GSM Network optimization and Drive test 1. Record of Exact latitude and longitude of the sites with site name & address with Unique SITEID as well as record no. 2. Record of Exact details of Antenna Height/ Tilt Mechanical / Tilt Electrical. 3. BCCH Frequency & BSIC Plan of the sites. 4. Verification BCCH frequency as per plan periodically (once in 3 months. 5. Level of handover from 1800 MHz to 900 MHz at 1800 MHz sites. 6. Check of Signal Quality and strength at the points of hand overs. 7. Measurement of VSWR where system alarms of VSWR exists.
9.2
Need for Optimization • • •
• •
Optimization is an invaluable element of service required to maintain and improve the quality and capacity of a network. It is essential if an operator wants to implement changes to the network to maintain the high quality of service levels expected by subscribers in networks. Without optimization the network will degrade from the commissioned state, due to the network changing radically as the traffic on the system grows, and snapshot optimization will not keep pace with these changes. Without optimization the system will suffer poor call quality, many dropped calls due to interference and inaccurate parameters resulting in poor handover performance. These together with other problems, have the same result, Subscriber Dissatisfaction. Optimization Process Components
INPUTS Quality Of
TOOLS Drive test kit (TEMS) and
Results
1) Frequency 2) BCCH changes
RF Design
OMC-R or Traffic
Alarms and events OMC-
3) BSIC changes 4) Antenna down tilt 5) Azimuth changes
Customer 9.3
Customer Care
Optimization Process Inputs
The following inputs are considered for optimization: –
QOS Parameters
–
RF Design Parameters
–
OMC alarms
O&M Handbook on ZTE Radio Technologies
Page 165
–
Routine Drive Testing
–
Customer feedback
–
Database Parameters
Using the above inputs we can determine the optimization requirement and the area which needs to be optimized. 9.3.1
QoS Parameters
QOS Parameters are the quality indicators of the Network. Call Success rate, Call Drop Rate, Handover success rate, Call Congestion are some of the QOS parameters. These parameters have to be continually monitored on cell, site , BSC and Network basis. If any abnormality is observed or if any deterioration is seen in any of the parameters optimization process has to be initiated. 9.3.2
RF Design Parameters
When a Network is designed benchmarking is done for Network quality, capacity, failure and congestion parameters. Whenever the Network is unable to comply with any of the RF design parameters, optimization process needs to be initiated. 9.3.3
OMC Alarms
Any problem in the Network results in a alarm at the OMC. Whenever a alarm is observed at the OMC it must be carefully analyzed to determine if there is a network problem and if it is required to initiate optimization process. The alarm can be due to faulty hardware which can create problems in the network. 9.3.4
Drive Test
Drive testing is done continually to monitor the health of the network. It is a normal procedure to define drive test routes and have them drive tested daily to monitor the network.
All sites and sectors should be tested within the drive test routes at least once. Following care should be taken while defining the routes –
All major roads and highways should be tested at least twice per week within the agreed routes.
–
All cells should be tested for handout and hand-in within the routes if possible.
–
The routes should be approximately 2 - 3 hours in duration. This is required to manage the data collected for analysis, routes longer than this can be difficult to analyze and transfer from P.C to P.C due to the files being too large.
–
Routes of major importance should be identified prior to starting and should be driven first. i.e. Airports to the city Centre.
O&M Handbook on ZTE Radio Technologies
Page 166
9.3.5
Customer Feedback
–
A procedure to feedback customer information on the performance and coverage of the network can be extremely useful.
–
The received information is used to target areas requiring optimization and to verify coverage against the RF design.
–
The information fed back is also used in assessing the growth of the network by identifying areas of high traffic volumes.
9.4 Optimization Process Once the optimization needs have been identified the optimization process is started to analyze the problem and then provide possible solutions. Optimization process involves studying and analyzing the problems using the following steps –
Statistical analysis
–
Drive testing
–
OMC tools
–
Site visits
9.4.1
Statistical Analysis
The quality of the network can be measured through the statistics generated from the network. These are available through the OMC (Operations and Maintenance Center) and are used to generate key metrics. This operational metrics will then be measured against the required metrics as agreed between the operator and vendor, from this comparison an optimization plan will be generated. Drive test statistics represent a small sample of the total calls on the network and can provide a useful indication of network quality. In order to provide a precise information of user traffic, the statistics obtained from the whole network through the OMC are a more accurate assessment of the quality of the network Key Quality Metrics The following metrics can be used to measure the performance of the network. – – – – – – –
Dropped Call Rate Handover Success Rate Overall RF Loss Rate - TCH & SDCCH RF loss combined TCH Assignment Success Rate Call Success rate TCH Blocking Rate SDCCH Blocking
Importance Of Statistical Analysis
O&M Handbook on ZTE Radio Technologies
Page 167
– – –
It is important for a good optimization engineer to have good knowledge of various statistics available from performance management. Any change in the network whether good or bad is definitely reflected in the statistics. By studying and analyzing the statistics we can not only detect the problems in the network but in some cases even provide the solution for the problem.
Statistical Analysis Types –
Trend Analysis
–
Daily Analysis
Trend Analysis Analysis which is carried out using statistical data over a period of time is called trend analysis. The longer the period better the analysis and accurate the results. Trend analysis helps us in understanding the performance of the Network over a period of time. It is important in generating Network Performance report and helps us to understand the progress of the network. It also helps us in Network expansion planning. It is expected that the operator maintain at least six months of data. Breakdown of Call Setup Failures 25
SDCCH RF Loss Rate (%) SDCCH RF Blocking Rate (%) MSC/PSTN-Related Failures TCH Assıgn Faılures TCH RF Blockıng Rate (%)
Percentage (%)
20
15
10
5
0
Date and Time
Daily Analysis Key statistics are analysed on a daily basis for the Network, BSC’s and cells. If any problem is observed (e.g. RF losses for a particular cell has gone up drastically) the concerned statistics are analysed in detail to determine the problem and then to initiate appropriate action. Daily performance analysis helps us check and solve problems at the initial stage itself and thus help us to maintain the quality of the Network. Statistics Evaluation Process Analyse key statistics for cell wise data. Note down the problems and prioritize them. Evaluate the concerned statistics in detail to pinpoint the possible cause for the problems. Initiate appropriate action to determine the solution. Apply the solution.
O&M Handbook on ZTE Radio Technologies
Page 168
Check statistics for improvement. If no or little improvement repeat steps 3,4,5 and 6. Same process can be applied for BSC wise and Network data.
Statistics Evaluation Process SDCCH and TCH congestion This statistics tell you if your TCH and SDCCH were congested To check if it is required to add a new carrier we must look at these statistics but should also look at time congestion statistics. These statistics tell you the amount of time for which the cell was congested during the day. Also it is important to study the trend for the above statistics before the action to be taken is decided.
9.4.2
Drive Testing General Drivetesting involves driving in a vehicle and collecting network data by making a lot of calls. The data collected includes data for serving cell as well as the neighbors. This data collected helps us to find and analyze the problems in the network. These data can also be loaded on the planning and optimization tools like Pegasos, Planet nemo etc. and usefull plots can be generated such as serving cells coverage plots, Quality plots etc. Equipment necessary for Drivetesting. –
Vehicle
–
Drive test mobile phone (e.g.Ericcson TEMS/ ZTE NEMO)
–
External vehicle mounted GPS
Laptop with drivetest software and GPS connection capability Drivetest Outputs Using the drivetest equipment we can monitor the following –
Status Information
–
Error reports
–
Mode reports
–
Layer 2 messages
–
Layer 3 messages
Status Information
O&M Handbook on ZTE Radio Technologies
Page 169
In status information we get the following information –
General Information: This includes the Latitude ,longitude data, server call name, Marker ,data, time , log file name etc.
–
Serving cell: This includes Cell Identity, BSIC, ARFCN ,MCC, MNC, LAC.
–
Serving + Neighbor cell data: This includes CI, BSIC, ARFCN, Rxlev, C1 and C2 for the serving and the best 6 neighbors.
–
Dedicated channel: This includes data such as Channel number, Timeslot number, Channel type and TDMA offset,hopping information and channel mode.
–
Radio Environment: This includes serving cell,lat , long, rxlev, rxqual, TA, DTX and RL Timeout counter information.
Error reports If any errors are reported during the call they can be analyzed from this report. Mode reports These are the channel mode reports. Layer 2 messages All the layer 2 messages can be analyzed. Layer 3 messages All the layer 3 messages can be analyzed. Drivetest types: Drivetest can be categorized in three types –
Routine drive test
–
Problem specific drive test
Cell coverage analysis drive test Routine drive test As we have discussed earlier optimization is a ongoing process and the network needs to be monitored on a daily basis. Routine drive test forms a integral part of this process. Drive test routes are decided by the Network operator and these routes are regularly drive tested and any problems found are reported. These problems are then further analyzed and solved. Hence it is important that these drive test routes are selected carefully. Drive test routes should include all the major road, important location, airports etc. Also they should be able to cover most of the cells.
O&M Handbook on ZTE Radio Technologies
Page 170
Each drive test route should be typically 2 - 3 hours long. Typical Optimization Process using routine drive testing The drive test routes must be decided by the operator and a priority set on the routes for testing. The drive test routes are usually 2 - 3 hours in duration in order to ensure that the data generated is of a manageable size. The drive test teams use the Test Mobile equipment (e.g.TEMS) to make test calls to the MSC test number on the network of 2 minute duration with a 15 second break. All data is logged on the computer, location information is also taken using a GPS receiver. During or after completion of the drive test route, analysis of the data collected is performed to identify areas of dropped or noisy calls. This will be done using FICS or other similar software. Should the analysis of the route indicate problems of either dropped or noisy calls then with the aid of the RF design and Database parameters, an assessment is made to identify the possible source of interference causing the noisy or dropped call. If a call is dropped and no interference is present a retest is made in the same area, if the scenario of the dropped call can be repeated, the identity of the problem cell will be obtained and corrective action taken. To assist in confirming possible sources of interference there may be a requirement to remove the suspected interfering channel. This would be done by the optimization engineers. The suspected interfering carrier would be removed temporarily from service and test calls made again in the problem area, this would show if the interference had been removed. The process for temporarily removing carriers would have to be agreed with the operator, this usually varies as to the importance of the cell as to what time of day it can be taken out of service. After conformation as to what is causing the problem with the drive test route, the drive test engineer will attempt to find a solution to the problem. This can be one of a number of possibilities i.e. Power Change to BTS, Frequency Plan change, Neighbor addition required, etc. Once a possible solution to the problem has been found it may be possible in some circumstances to immediately attempt the solution via the OMC, this usually relates to minor database changes and adding neighbors. The solution is implemented and proven immediately. If the problem is rectified the change remains in place and a change request is raised for the solution for the purpose of keeping records of all changes in the network. If the solution requires a major database change or antenna work a change request must be raised via the Optimization Control Engineers.
O&M Handbook on ZTE Radio Technologies
Page 171
After the solution is implemented a retest of the problem area is carried out to confirm the problem has been solved Problem drive testing Any problem reported by statistical analysis, routine drivetesting, customer care centre , alarms need to be analyzed in detail to find a solution. Problem specific drive testing is a important tool which helps us do it. Here we make a list of problematic cell and drive test them thoroughly to analyze the problem. There may be many different methods which a optimization engineer may employ for the analysis. As an example, if a particular cell is being interfered the frequency of the cell may be changed temporarily to identify the interferer. Also the levels and TA at which the cell is being interfered may be analyzed. Here the data collection and analysis are done simultaneously. Cell Coverage Analysis Drive Test It has been found that normally that the coverage and server area of the cells differ from the planned area. Hence it is often found that new cells that come on air serve far more or much less area than initially planned and same could be the case with the coverage. This could lead to two problems. If the server area is less than planned it could lead to coverage holes or poor cover areas. If the coverage area is more than planned it may cause interference in the network. Hence it is important that once new cells come on air they must be thoroughly drive tested to determine their server and coverage areas. If any major deviation from the initially planned design is found the cell sites should be optimized. Scanning This is a important feature of the drive test software. It enables us to lock onto a particular frequency during the drive test which is helpful in determining the server area of a cell. Also we scan a set of frequencies and have a graphical display of the same or can also be stored for further analysis. This is helpful in finding interfering frequencies and also in finding clear frequency. Optional Features Some drive test equipment provide supplementary features which help during drive test. Map displaying the drive tested area showing the major roads, location, cell sites is provided ,this helps us to be always aware as to where we are in the network. Also some vendors provide spectrum analyzer which helps in finding the interfering frequencies and to find clear frequencies.
O&M Handbook on ZTE Radio Technologies
Page 172
Typical Information Available From A Drive Test Tool
Graphical Representation
General Information Obtained During Drive Test
Layer2 and Layer3 Information Obtained During Drive Test
O&M Handbook on ZTE Radio Technologies
Page 173
Layer3 Information Obtained During Drive Test
Serving Cell and Neighboring Cell Information adio Environment Information
Radio Environment Information Radio Environment Information
Dedicated Channel Information
O&M Handbook on ZTE Radio Technologies
Page 174
9.4.3
OMC Tools
General Many vendors provide advanced tools which help in optimization of the Network. Some vendors provide Network Health reports which provide you list of bad performing sites with poor sites and possible causes for the problems. However one powerful tool provided by all operators is the call trace tool. The degree to which this feature has been developed varies from vendor to vendor. This is perhaps the most important tool in optimization. We will be having a look at this feature in detail. Call Trace Feature This feature enables us to put a trace on a call and collect all data related to the call. The call trace can be put on a cell basis, BTS wise, over the BSC or over the entire Network. Call trace can be put on a IMSI, IMEI ,TMSI or on every nth call being made in the cell, BTS, BSC or the Network. Call trace gives you all the information that you get in the drive test plus it also give you uplink Rxlev and Raquel information. Also drive testing can be done only on the roads hence it becomes difficult to locate and solve indoor problems. Since in call trace we can accumulate data for call being made throughout the cell it includes the indoor calls also and hence gives us the the correct picture regarding the performance of the cell. Protocol Analyzer : Protocol analyzer may be used to analyze the C7 signaling messages between the MSC and the BSC . These are used to analyze problems which may originate either in the Radio part or the MSC e.g. paging problems.
O&M Handbook on ZTE Radio Technologies
Page 175
9.4.4
Site Visit
General When we visit the problematic sitefor optimizing we must ask three simple questions which will help us in optimizing Why was this site put up? Will this site serve that purpose? What are the problems that I see at this site and how can I solve them ? Let us now look at each of those questions individually. Why was this site put up? We must know if the site was installed for capacity or coverage. If it was for capacity we should know if it should offload the traffic of some existing sites and if it should generate traffic of its own. Also if the site in question is a hotspot or not. If the site was installed for coverage we should know exactly the area it is supposed to cover and if there is some existing coverage in that area. Will this selected site serve that purpose? Once we are clear about the objective of installing the site we must analyze if the site in question serves that purpose or not. It is important that the selected site serves its objective. What are the problems and how can I solve them Some of the common problems could be as follows –
The neighboring sites cause interference to the proposed site.
–
The site is a cause of interference to some existing sites.
–
If there is a possibility of a back lobe or side lobe problem.
–
There could be some near end obstruction
9.5 Optimization Solutions General Once the problem has been analyzed a solution has to be provided. Common solution to problems are –
Database Parameters Changes
–
Antenna Optimization
–
Frequency changes
–
Neighbor addition and deletion
O&M Handbook on ZTE Radio Technologies
Page 176
–
Formation of new location areas
–
Addition of new cellists
Database Parameter Changes Many problems can be solved by changing some database parameters. Some of the common changes are –
Handover parameters and thresholds
–
Maximum transmit power of BTS
–
Paging parameters
–
SDCCH Parameters
Antenna Optimization –
This includes changing of antennana tilts, orientations, positions. Sometimes the antenna may also be changed.
Frequency Changes –
Frequency changes help us to control the interference in the network.
–
However one should be careful when doing these changes so that this changes do not affect the other sites adversely.
–
If there are a lot of changes it is advisable to change the whole frequency plan.
–
A careful study of cell coverage area and server area helps in making those changes.
Neighbor Additionand Deletion –
Many problems arise due to wrong neighbor definitions or missing neighbors.
–
Neighbor definitions must be reviewed on a regular basis. Statistics and drive tests provide good inputs for this purpose.
Formation of New Location Areas –
Sometimes to solve paging load problems it might be required to for new location areas.
Addition of new cell sites –
Sometimes to solve coverage hole problems we need to add more site (normally micro or Pico cells)
Path Balance –
Many problems also may arise due to poor path balance. Hence it is important that we make a mention about it.
–
Path balance data can be collected from the statistics.
–
As we use different frequencies for uplink and downlink, we have different footprints for the uplink and the downlink .
O&M Handbook on ZTE Radio Technologies
Page 177
–
It is imperative that the footprints match.
–
If the downlink is stronger it implies that the mobiles at the boundaries of the serving area are not able to reach the BTS and there is a uplink problem.
–
Similarly if the uplink is stronger it implies a downlink problem.
9.6 Frequency Planning for 2G BTSs 9.6.1 Frequency Channel Allocation: In GSM systems we divide the total allocated spectrum into two sub-groups one for Control information with traffic referred to as BCCH frequency and other only for traffic referred to as TCH (or non-BCCH) frequency. While planning, no compromise is made for BCCH frequency interference whereas certain compromise could be made for TCH frequency interference. Typically a cluster size of 4 or 7 is considered for BCCH reuse whereas a cluster size of 3 or 4 is used for TCH re-use. The number of channels in each group depends on the spectrum allocated and C/I criteria for re-use in each case. Example: BSNL’s Case (5 Mhz allocated in 900 Mhz) Frequency Re-use : 4x3
O&M Handbook on ZTE Radio Technologies
Page 178
Frequency Re-use:5 x 4 re-use pattern
Frequencies ( BCCH /TCH values) under use in BSNL
9.6.2 BSIC Planning: In addition to the assignment of frequency group to a cell, a Base Station Identity Code (BSIC) must be assigned in association with the frequency group. This will eliminate the possibility of incorrect cell identification and will allow the evolution to future cell architecture. The BSIC is a two-digit code wherein the first digit is indicates NCC (Network Colour Code) and the second digit indicates BCC (Base Station Colour Code). The NCC and BCC have values ranging from 0 to 7, where the NCC is fixed for an operator, signifying at any given point there can be maximum of 8 operators in an area. The BCC defines the cluster number which means a group of 8 clusters carry unique identity which are re-used for another group of 8 clusters and so on. The principal for allocation of the BSIC is the same as for the RF carriers but at cluster level rather than cell level. The concept can be understood in the following example, In case of BSNL
NCC- 2&3 and BCC- 0 to 7
Assume a network with 100 base stations each having three sectors. The BCCH and TCH share the same re-use plan 4 x 3. Which means we have cluster of 4 base stations, and in all we have 100/4 = 25 clusters. Assume NCC code allocated is 2, which gives us clusters starting from number 21 to 27. Hence seven clusters form a group and hence we have 25/7 that is 3 groups of 7 clusters plus additional 4 clusters which form part of the 4th group. The reuse of these 7 clusters group for BSIC numbered from 21 to 27 is shown in the figure (1.5) below,
O&M Handbook on ZTE Radio Technologies
Page 179
Represent a cluster of 4 sites each 22 having 3 sectors 22 27
23 21
26 22
21 26
24 22 25 23
23
27
25 23
27
21
24
21 24
24
26 25
BSIC 7 re-use cluster plan. It should be noted that since BSIC are defined at cell (sector) level, hence there are every possible chances that the three sectors within the same site can have different BSIC. The reason being as BSIC is used for cell identification hence cells with same BCCH frequency but different BSIC can be easily discriminated by the MS. The following is the 2G frequency allocated to BSNL in 900 Mhz/1800 Mhz/2100 Mhz.
O&M Handbook on ZTE Radio Technologies
Page 180
9.6.3 Frequency Band Allotted to BSNL SN 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 1
GEN 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 2G 3G
BAND 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 900 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 1800 2100
ARFCN 63 64 66 67 68 69 70 71 73 74 75 76 77 78 80 81 82 87 88 111 112 113 115 116 117 118 119 120 122 123 124 713 714 715 716 717 718 778 779 780 781 782 783 784 785 786 832 833 834 835 2100
Uplink frequency MHz 902.6 902.8 903.2 903.4 903.6 903.8 904 904.2 904.6 904.8 905 905.2 905.4 905.6 906 906.2 906.4 907.4 907.6 912.2 912.4 912.6 913 913.2 913.4 913.6 913.8 914 914.4 914.6 914.8 1750.4 1750.6 1750.8 1751 1751.2 1751.4 1763.4 1763.6 1763.8 1764 1764.2 1764.4 1764.6 1746.8 1765 1774.2 1774.4 1774.6 1774.8 1966.5
Downlink frequency MHz 947.6 947.8 948.2 948.4 948.6 948.8 949 949.2 949.6 949.8 950 950.2 950.4 950.6 951 951.2 951.4 952.4 952.6 957.2 957.4 957.6 958 958.2 958.4 958.6 958.8 959 959.4 959.6 959.8 1845.4 1845.6 1845.8 1846 1846.2 1846.4 1858.4 1858.6 1858.8 1859 1859.2 1859.4 1859.6 1859.8 1860 1869.2 1869.4 1869.6 1869.8 2156.5
TRAFFI C TCH TCH TCH TCH TCH TCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH BCCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH 3G
Chapter 10 O&M Handbook on ZTE Radio Technologies
Page 181
2G Network KPI Optimization _____________________________________________________________________________________
10.1 Introduction Network Optimization is a continuous activity. Purpose of network optimization is to improve system performance and maximize service quality under existing system configuration. Network optimization is necessitated due to following factors: Network structure changes e.g. change in coverage and capacity of network Environmental changes e.g. new building, road, vegetation etc End-user changes e.g. new calling model, subscriber distribution change Application of new technology Induction of new equipment Formulation of new standard
Following 2G network KPI optimizations are covered in this chapter: SDCCH congestion and solutions
SDCCH assignment analysis TCH assignment failure and solutions TCH call drop and solutions Handover problems and solutions Paging problems and solutions Interference and solutions Coverage problem and solution Data KPI improvement
10.2 SDCCH Congestion and Solutions During Location Update and early stage of MOC and MTC process, MS usually seizes SDCCH to exchange signaling. SMS is also sent/delivered through SDCCH channel in idle mode. When BSC receives SDCCH request from MS, it checks SDCCH resource. If all SDCCHs are occupied at that moment, SDCCH congestion takes place. Formulae for SDCCH congestion in ZTE V3 (6.20) is given below: Number of signaling channel blocking * 100/Number of signaling channel call attempts (C900060005+C900060011+C900060039)*100/(C900060003+C900060010+C900060038) SDCCH congestion causes and solutions: (a) Large traffic volume exceeding network capacity Solution: Increase cell capacity by adding more TRXs. (b) Unreasonable setting of system parameters and RACH parameters Solution: (i) Increase RACH access threshold appropriately to cope with interference (ii) Reduce MaxRetrans appropriately (iii) Increase number of transmission timeslots (c) Too many location update at LAC boundaries Solution: (i) Adjust LAC selection and/or modify LAC boundaries (ii) Adjust CRH (Cell Reselection Hysteresis) (iii) Adjust parameter setting of periodic location update timer (T3212) (d) Too much SMS traffic Solution: (i) Implement dynamic SDCCH allocation mode (ii) Increase SDCCH channels (e) Hardware fault in TRX/FPU or transmission system Solution: (i) Replace the faulty hardware (ii) Check and repair the transmission system
O&M Handbook on ZTE Radio Technologies
Page 182
Procedure for checking SDCCH Congestion: 1. Check congestion range through reports. SDCCH congestion in all the cells under the BTS may be related to wrong parameter configuration or transmission fault. 2. Check through reports if channel activation failure/timeout occurs. It can be checked through alarms. 3. Collect times of access success and failure (due to different causes) through radio access measurement. Access causes fall into four types: MOC MTC LOC (Location Update)
Others
Analysis of access attempts with different causes and their proportions can help to locate the cause of SDCCH congestion. 4. Check if there are any newly commissioned sites or any adjustment on LAC or VLR has been performed. 5. Find out if the SDCCH congestion continues for a long time in the busy hour. If it is so, then SDCCH channels have to be increase or new TRX has to be added.
10.3 SDCCH Assignment Analysis SDCCH is used to transmit information like channel assignment, which falls into following two types: SDCCH/8 – The stand-alone dedicated control channel SDCCH/4 – The SDCCH that is combined with CCCH In brief, following processes shall be taken into consideration in the process of occupying SDCCH: Location update, periodic location update IMSI attach/detach Call setup SMS Formulae for SDCCH assignment success rate in ZTE is: Number of successful SDCCH assignments * 100/(Number of successful SDCCH assignments + Number of failed SDCCH assignments) (C900060242)*100/(C900060242+C900060243) Common causes of SDCCH assignment failure: (i)
MS frequently sends location update due to poor downlink quality: If the MS needs to make location update, while thw radio environment is poor, it will retransmit Channel Request with the cause of location update again and again., but will never receive Immediate Assign message. The frequent location update will cause fluctuations in SDCCH assignment indicators. Troubleshooting: Check the TxInteger of the problematic cell, along with LAPD delay observed from signaling. Check whether the LAPD link of BCCH TRX in the problematic cell is multiplexed with that of other cells.
O&M Handbook on ZTE Radio Technologies
Page 183
(ii)
(iii)
(iv)
(v)
(vi)
Check whether any of the adjacent cells have same ARFCN and BSIC as that of problematic cell. Check transmission alarms Analyze signaling and check if Channel Request with large TA, if so, fake excess exist and TA_allowed restriction can be used. Improper setting of TxInteger: The default value of TxInteger is 14, which is also the maximum value. When the transmission link delay is high, while TxInteger is set with a small value, it will result in MS sending too many access requests. However, MS only responds to the first Immediate Assign it receives. High LAPD Delay: Possible causes of LAPD delay are: Application of LAPD 1:4 multiplexing can lead to heavy load on LAPD channel, which may cause delay. Transmission equipment’s faults also lead to LAPD delay. The transmission equipment’s own delay such as use of satellite transmission can also cause LAPD delay. PS service is more sensitive to network delay. Any LAPD delay will lead to re-transmission of PS service message, which increases the flow on LAPD and causes longer LAPD delay, and a malicious cycle will occur. Overshooting: If the coverage of the cell is too large, the DL Rxqual at the cell margin will be poor. In this case, BTS can receive the Channel Request sent by MS, but MS cannot receive Immediate Assign sent by the BTS, for BTS is more sensitive than MS. Solution: Adjust the engineering parameters of the antenna to limit the cell coverage. TA_allowed can effectively decrease SDCCH assignment failures caused by overshooting. Co-channel and Co BSIC: If two cells have same BCCH and same BSIC, then also there will be SDCCH assignment failures. For avoiding this, use different BCCH and BSIC for adjacent cells. Uplink interference: BTS receiving sensitivity is -112 dbm ~ -125 dbm. If the random access signal strength received by BTS is lower than BTS sensitivity, it usually is confirmed to be interference. For handling this aspect, adjust the TA_allowed parameter.
10.4 TCH assignment failure and solutions The relevant KPI is TCH allocation success rate. Its formula is: Number of TCH assignment successes (excluding handover)/Number of TCH assignment attempts (excluding handover) (C900060017+C900060028+C900060036+C900060235+C900060199+C900060210)*100/ (C900060010+C900060019+C900060030+C900060038+C900060042+C900060046) Main causes of TCH assignment failure
Traffic congestion in cells Hardware problem Co-channel or adjacent channel interference Antenna feeder problem Un-reasonable setting of parameters Transmission problem on A interface or Abis interface Influence of repeater
O&M Handbook on ZTE Radio Technologies
Page 184
Problem handling procedure (i) (ii) (iii) (iv) (v)
Check if traffic congestion exists Check whether the radio parameters set are reasonable Check indicators e.g. BER, idle interference band class Check hardware Check antenna system
10.5 TCH Call drop and Solutions TCH call drop formula is given below: TCH call drop rate = Total TCH call drops/Total TCH occupancy * 100 = (C900060054+C900060055)*100/(C900060028+C900060036+C900060199+C900060210) Common causes of call drops:
Unreasonable setting of handover parameters UL/DL unbalance Unreasonable setting of other parameters Coverage problem Interference Equipment hardware fault
Call drops due to radio link failure Main causes: Weak coverage, poor radio signal Unreasonable setting of radio parameters Incomplete or wrong adjacent cell data Unreasonable setting of handover parameters Congestion in adjacent cell Equipment hardware fault Antenna system fault Subscriber’s fault Handling procedures: Check radio parameters. Adjust unreasonable settings of radio parameters Check indicators like BER and level of idle interference band, reduce or eliminate radio interference Check if coverage problem exists through drive test Check and eliminate equipment fault Check antenna system Call drops due to handover failure Main causes: Interference Hardware fault Unreasonable settings of radio parameters Inappropriate adjacent cell relation or wrong adjacent cell data Unreasonable settings of handover parameters, which result in ping-pong handover
O&M Handbook on ZTE Radio Technologies
Page 185
Handling procedures: Check radio parameters, adjust the unreasonable settings and add necessary neighbor relations Check indicators like BER and level of idle interference band, reduce or eliminate radio interference Check equipment hardware Call drops due to LAPD link failure Main causes: BTS hardware fault BTS transmission problem BSC hardware fault Handling procedures: Investigate and eliminate BTS hardware fault Investigate and eliminate BTS transmission problem Investigate and eliminate BSC hardware fault
10.6 Handover Problems and Solutions Handovers are meant for maintaining call continuity when subscriber crosses over from one cell to another cell. KPI to be monitored for handover performance in GSM is “Handover Success Rate”. Its formula is given below: Handover success rate: Number of handovers successful/total number of handover requests =(C900060098+C900060102+C900060120+C900060094+C900060096)*100/(C900060097+ C900060213+C900060214+C900060215+C900060099+C900060100+C900060101+C900060216+C9000 60119+C900060093+C900060095) Analysis of handover problems (i)
(ii) (iii)
(iv)
(v)
(vi)
Coverage Poor coverage due to influence of forest, complex landforms, houses, indoor coverage etc. Isolated cell : no adjacent cells around Skip-zone coverage : no adjacent cells available due to isolated island effect Interference: It makes MS unable to access in UL or DL. Signal receiving problem will result Antenna system problems Too large VWSR Reversed installation of antenna Non-standard antenna installation Unreasonable azimuth, down tilt Below standard antenna insulation ‘Twisted cables, loosened connectors and wrong connections BTS software/hardware problems BTS board faulty Clock generator malfunction Internal communication cable malfunction BTS software malfunction Transmission fault Unstable transmission Too high transmission error rate BSC Hardware/software malfunction
O&M Handbook on ZTE Radio Technologies
Page 186
(vii)
Clock generator malfunction: unconformity among clocks in different BTSs due to clock generator malfunction Problem in BSC board Wrong data configuration Unreasonable setting of handover threshold Cell ID, LAC, BCCH and BSIC value in “external cell data sheet” do not match up to those in the corresponding BSC Wrong BSC signaling point in “list of cell under a LAC” in MSC Co-channel and co-BSIC adjacent cells exist Other issues A interface malfunction Busy target cell Equipment compatibility problem: Difference in signaling at interface A and interface E between ZTE and other suppliers’ equipment, causing non-recognition or non- support problem, including speech version, handover code and addressing mode (CGI or LAC) etc., which will result in handover failure
10.7 Paging Problems and Solutions Paging is done by MSC for alerting the MS for MTC or SMS-MT. The relevant KPI for paging performance is Paging Success Rate. Its formula is given below: Paging success rate = MTC access success number/Total paging attempts = ∑C900060002/C900060152 Reasons for low paging success rate (i)
(ii)
(iii)
(iv)
Paging message can’t be sent on the radio channel Link load is so high that it makes bottom layer SCCP message lost MSC/VLR, BSC flux control makes message to be discarded When the load os high, message queuing time gets longer so that the message can’t be sent to MS in time Poor transmission link quality makes bottom layer LAPD message lost T3212 timer is set unreasonably. Value of T3212 timer in BSC should be less than that of VLR periodic location update timer Too many paging messages make message lost on radio interface MSC redundant cell data makes BSC paging times abnormal MS don’t receive paging message Coverage reason Frequent MS reselection Frequent location update MS can’t monitor messages on BCCH while using GPRS service Paging group is set unreasonably Paging repeat time is set unreasonably Frequencies of adjacent cells differ greatly so there are frequent reselections, different monitor time makes paging lost easily. Related messages are not sent to MSC when MS is responding paging SDCCH congestion SDCCH assign failure Unbalance uplink and downlink, weak uplink Bad transmission link makes messages lost Special situations
O&M Handbook on ZTE Radio Technologies
Page 187
Two MSs are calling one mobile phone at the same time. MSC connects one MS and replies the other with no paging response MSC paging sending time is unreasonable
Optimization Strategy (i)
(ii)
(iii)
(iv)
(v)
(vi)
(vii)
Expel the abnormal phenomenon caused by the system Check flux control alarm and see whether MSC/VLR/BSC has flow control alarm. Maintain trunk link on A/Abis interface, observe signaling load on A/Abis interface, increase signaling link in time and decrease paging failure caused by too high signaling load Check whether BTS has transmission transient alarm. Observe whether it is multifarious to reselctphenonmenon, if it is already needed to modify reselection parameter (CRO, TMO and PT etc.) Check whether MSC database has redundant data Check MS latest activity status Presently only VLR probe can be used to check latest activity status Record signaling on SGSN, MSC and Abisinetface in the test to judge MSC activity Eliminate GPRS influence Check whether GPRS routing area is set reasonably. Routing of one site should be same and routing area of cells where frequent reselections occur should also be same Check whether routing area update time I set reasonably Use mobile phone that has no GPRS service Indicator analysis Check SDCCH congestion status. Eliminate no paging response due to SDCHH congestion Analyze whether MTC success rate is normal Analyze whether cell location update times are normal Analyze system average TA and maximum TA to judge whether overlapping exists Radio parameter checking and optimization Check parameter setting related to paging, access, immediate assignment Check whether T3212, RxLev Access Min IDETTIM are set reasonably Whether LAC division is reasonable, whether overlapping area of several LAC is reasonable. Consider splitting LAC if its capacity is exceeded MSC paging strategy analysis Check whether system capacity supports multi-paging, if yes, analyze effect of multipaging on the system. MSC is responsible for forming paging message and resending the message if there is no response The interval between two pagings is very important. In radio aspect, the longer is the interval between two pagings, the smaller is the relativity with radio environment for MS while responding paging, the easier for the MS to respond to paging messages successfully. But, calling subscriber may hang up if paging interval is kept too high Field Test Field test is the most important step, from which only we can get the real picture Observe whether frequent reselections occur, modify reselections parameters e.g. CRO, TMO, PT etc. Test whether blind area exists
10.8 Interference and Solutions
O&M Handbook on ZTE Radio Technologies
Page 188
Interference is the presence of any un-desirable signal in the network. There are two types of interference:
Internal interference: Internal interference refers to unreasonable frequency planning and equipment hardware faults, which could lead to decrease to network service quality External interference: External interference refers to unknown signal source out of the network, whose existence could seriously disturb the network’s signals and lead to decrease in the service quality
Problems caused by interference
Call Drop Poor speech quality On and off speech Inability to establish calls Metallic noise
Causes of interference (i)
(ii)
(iii) (iv)
Unreasonable frequency planning Frequency and adjacent cell relation could have been set unreasonably in network planning because of planning tools or human mistake Interference will be reflected in too large DL_RxQuality, MS unable to access the network, poor speech quality and call drop Use planning tool to check if co-channel exists and adjust the cells frequencies wherever it exists Skip zone coverage Unreasonable setting of engineering parameters such as antenna type, down tilt, and azimuth may result in skip zone coverage (coverage more than the actual requirement) Improper setting of network parameters such as minimum access level, BTS transmission power, MS max transmission power, handover thresholds, etc, may also result in skip zone coverage Equipment fault Radio fault of BTS is mainly caused by defective UL unit parts External interference Due to wide-band repeater Due to CDMA system (trailing signal) Due to signal jammer
Analytical methods of handling interference problem Analytical methods of handling interference problem are given below: (i)
Statistical analysis of network performance indicators Statistics of interference band: When TCHs are in idle status, UL noise/interference is constantly being measured by BTS, and the measurement result will be analyzed, and interference level be sent to BSC in 6 levels Statistics of handover due to UL/DL interference: It can be judged whether interference exists through statistics of handover caused by UL/DL interference Collection of UL/DL RQ samples during speeches: RxQual is an indicator to reflect speech quality, which is based on bit error rate (BER) and falls into following 8 grades ( 0~7)
O&M Handbook on ZTE Radio Technologies
Page 189
(ii)
(iii)
(iv)
(v)
RxQual_0 RxQual_1 RxQual_2 RxQual_3 RxQual_4 RxQual_5 RxQual_6 RxQual_7
BER < 0.2% 0.2% < BER < 0.4% 0.4% < BER < 0.8% 0.8% < BER < 1.6% 1.6% < BER < 3.2% 3.2% < BER < 6.4% 6.4% < BER < 12.8% 12.8% < BER
Parameter checking Check parameters related to transmitting power Check antenna engineering parameters Check frequency planning parameters Check parameters related to skip zone coverage Checking hardware fault OMCR warning analysis Checking latent equipment fault Drive test and call quality test Drive test can effectively detect the location and degree of interference, which is convenient for analyzing the cause of interference In call quality test, level of speech quality can be actually felt and quality class on the test phone can be seen for drawing the inferences for further action Test for external interference Confirm external interference with the help of site-master: If persistent strong level exists within the bandwidth of 20 MHz, it can be concluded that strong uplink interference exists Make UL interference analysis of GSM 900M UL frequency band with frequency scanning meter such as NetTek Analyzer
10.9 Coverage Problem and Solution Coverage problem is of following three types: (i)
(ii)
(iii)
Weak coverage: Too small coverage range will cause high call drop rate and a large number of customer complaints. Main causes of weak weak coverage are: Too small BTS power Too low antenna height Too small down tilt Hardware problem Obstruction due to buildings Signal absorption due to foliage, water bodies etc. Over coverage: Too large coverage will result in frequent handovers, mutual interference and deterioration of network indicators. Main causes of over coverage are : Poor antenna performance In-appropriate down tilt Too high antenna height No-serving cell coverage: When cell reselection parameters and handover scenarios are similar, or there are 2 or more cells with similar signal strength, ping-pong handover may result. Main causes of no-serving cell coverage are: Unreasonable planning of antenna parameters In-appropriate type of antenna Too large or too small carrier transmission power Shrunk coverage caused by equipment fault Influence of changes in radio environment
O&M Handbook on ZTE Radio Technologies
Page 190
Unreasonable planning of handover parameters Unreasonable planning of cell reselection parameters
Procedure of handling coverage problem
Check setting of problematic BTS’s radio parameters Check if strong interference source exists Check hardware Check antenna system Analyze the local geographical environment to see if site location and type of site are appropriate
10.10 Data KPI Improvement From radio network point of view, following KPI has to be monitored: Packet connection drop rate = Packet connections dropped/Total packet connections established For improving the data KPIs, following aspects are to be taken care of: Error free transmission: Data traffic is more sensitive to transmission errors as compared to voice transmission. For improving the data performance, it may be ensured that transmission media is error free. Reserving appropriate number of time slots for data: Based upon relative proportion of data and voice traffic in any cell, appropriate number of time slots should be reserved for data traffic. As per current norms followed in BSNL, time slots reserved for data in a cell having more than 2 TRXs is 4 , while for 2 TRX cell, it is 2. Limit for maximum number of time slots which can be used for data traffic should be 100%.
O&M Handbook on ZTE Radio Technologies
Page 191
Chapter 11 3G KPI Network Optimization _____________________________________________________ 7.1
Overview The radio network KPIs directly reflects the network quality, and KPI monitoring is an important means to locate the faults. KPI monitoring and optimization are mostly performed during the network operation and maintenance stage. Abnormal events are supposed to be detected as early as possible and handled with proper solutions so that sound voice and data services can be ensured for the subscribers. At the beginning of the network construction, the optimization team should put more emphasis on the RF adjustment rather than the optimization of KPIs except for CS call drop rate, the PS call drop rate, and the RTWP indicator. During the network operation and maintenance stage, KPI optimization (also called parameter optimization) plays the main role, that is, the optimization team should optimize a certain indicator through integrated parameter adjustment so as to meet the customer’s requirements. KPI data comes from NetNumenT31, the network management system in the operation and maintenance center (OMC). Based on the analysis on KPIs, the current states of those indicators are learned and they are important reference for assessing the network performance. The KPIs include the network service retaining capacity, accessibility, mobility, system capacity, and so on. According to the current values of these indicators, for example, some site has congestion, some site has a call drop rate of 10%, or some RNC has a certain worst cell proportion, busy cell proportion, cell code resource availability, access success rate, call delay and handover success rate, the optimization team should judge and locate the area, scope and severity of the fault.
O&M Handbook on ZTE Radio Technologies
Page 192
KPIs are divided into service KPIs and network KPIs by the statistic sources. Service KPIs are collected through field drive tests (DTs) while network KPIs are collected from the unified network management system. This article mainly discusses the analysis on network KPIs. Usually, the final solution is made based on the joint analysis on the OMC KPI data, alarms, subscribers’ complaints, and DT results. Figure 11.1 Joint KPI analysis
11.2
KPI Monitoring Process The purpose of KPI monitoring is to find out abnormal events that affect services as well as subscribers’ perception and solve the problems as early as possible. For instance, if the call drop rate at a certain site goes over 50%, we need to find the problem and work out the solution in the earliest time. As it is very urgent and important to locate KPI problems, we need a whole set of scientific KPI monitoring mechanism and problem shooting process, as well as appropriate monitoring tool and analysis tool to help us find the call drops caused by transmission problems, resource congestion, cells service interruption, serious interference, hardware fault with Node B, wrong configuration of RNC parameters in time. We classify KPI monitoring into four categories: routine KPI monitoring, KPI monitoring during the process of parameter modification, KPI monitoring during the RNC or NodeB version upgrade, and KPI monitoring during the process of cutover. Routine KPI monitoring should be performed every day and be recorded in a KPI daily report, which should involve the worst CS cell, the worst PS cell, the cell with the lowest RRC connection rate, the cell with the most serious resource limit, and so on.
11.2.1
KPI Monitoring Process KPI monitoring falls into four categories: routine KPI monitoring, KPI monitoring during the process of parameter modification, KPI monitoring during the version upgrade of RNC or NodeB, and KPI monitoring during the process of cutover. Each type of monitoring has its own monitoring items and output form. For instance, the output of the routine KPI monitoring should be a daily report, while the output of other KPI monitoring types should be a KPI comparison report. Different types of KPI monitoring should have different time granularities according to the requirement of problem location.
O&M Handbook on ZTE Radio Technologies
Page 193
Routine KPI monitoring should be done persistently and be recorded in a daily report, which should include a collection of the cells worst in different aspects, and be sent to relevant person by email.
11.2.2
Routine KPI Monitoring Process Routine KPI monitoring process is shown below in the Figure 11.2
Figure 11.2 Routine KPI monitoring process
O&M Handbook on ZTE Radio Technologies
Page 194
EMS exports the one-day granularity of the whole
Screen out the worst cells with Output KPI daily report in
Equipment/version problem Coverage problem
O&M Handbook on ZTE Radio Technologies
Page 195
Problem handling team classifies, collects and locates the worst cells Hand to the network optimization personnel
Hand to R&D dept. or customer service dept
11.2.3 KPI Monitoring Process During Parameter Modification Figure 11.3 KPI monitoring process during parameter modification
Classification of the worst cells Parameter problem Hand to the planning personnel
O&M Handbook on ZTE Radio Technologies
Page 196
11.2.4
KPI Monitoring During RNC or NodeB Version Upgrade Figure 11.4 KPI monitoring workflow during RNC or NodeB version upgrade
O&M Handbook on ZTE Radio Technologies
Page 197
Current version Rollback or not Yes
Send mail to or call the person in
Execute the worksheet to upgrade version
Network KPI monitoring （ 15 minutes time granularity ）
Whether the RNClevel KPI is normal
Keep on monitoring
Output formalNo Word report
(Compare the hourly granularity KPIs before and after the parameter modification, and output the result every hou
Locate the worst cells. Determine whether they are related with the vers
No
O&M Handbook on ZTE Radio Technologies
Page 198
Ye
11.2.5
KPI Monitoring During Cutover For the network on which the equipment needs to be replaced (for instance, HongKong CSL network, for which we replaced Nokia’s equipment with ZTE’s), after the network optimization is completed, the subscribers on the existing network should be cut over to our network gradually. During the cutover, there will be subscribers registering on our network constantly, which will cause load increase on the network. In this case, we should watch KPI changes closely. The monitoring process, items, method and report are the same as those described in section 10, “
.” Please read it for reference.
11.3
11.3.1
KPI Analysis Methods
KPI Analysis Methods Different network problems require different performance analysis methods. Choose one or more appropriate methods after learning the running state of the existing network and the problems with it. Common analysis methods are as follows: TOP N worst cells method: Based on the traffic statistics indicators we care about (such as the call drop rate, connection rate, and soft handoff failure rate), choose N worst cells whose average indicator values in the peak hours or of the whole day are the lowest as the target of fault analysis and optimization. Or prioritize objects of optimization against these indicator values. Time tendency chart method: Tendency chart of indicator change is commonly used in the traffic analysis. The analysis engineer can work out an hourly, daily or weekly tendency chart of one or more indicators of the whole network, a cluster, or a single cell, and find out the change rule of traffic statistics indicators. Regional location method: The change of network performance indicators often occurs in some regions. The indicators in these regions may be worsened by traffic increase, traffic mode change, radio environment change, faults with a small number of stations, or uplink/downlink interference, which will therefore affect the performance indicators of the whole network. By comparing the network performance indicators before and after the change, we can mark out the station or the sector with the greatest indicator change on an electronic map, and take these problem regions as the analysis focus. Comparison method: A single traffic statistics indicator may be affected by many factors. While some factors change, others may not. Choose a proper object for comparison to confirm the existence of problems, and then analyze the causes of the problems. When examining an indicator, do not care whether the absolute indicator value is high or low only, pay more attention to whether the value is high or low compared to other indicators instead.
O&M Handbook on ZTE Radio Technologies
Page 199
End
11.3.2
Basic KPI Analysis Skills Be able to use the KPI statistics tool and the analysis tool l
Use tools to learn about the running state of the whole network quickly, and screen out TOP N worst cells quickly.
l
Use different analysis tools to find problems from different aspects and locate the problem quickly.
l
Understand the signaling process and basic principle
In the process of abnormity location, keep a clear aim in mind, and be able to apply the process and basic principle to check the other relevant indicators rapidly to facilitate the analysis. Be familiar with the process and basic principle and be able to make logical association between abnormal KPI problems and network problems (such as the coverage problem and the interference problem). Be able to determine the problem nature according to the abnormal KPI, and then choose the appropriate tool to analyze the problem in depth. Performance analysis requires engineers to understand basic signaling process, be familiar with the protocol stacks of standard interfaces, and know relevant algorithms to realize the product functions. Engineers should at least have a concept about the various algorithms. If the analysis of a commercial network involves some algorithms, engineers should study these algorithms in depth.
11.3.2.1
11.3.2.2
KPI Monitoring Tools
Network management tool NetNumen U31: count KPI original data, alarm data, radio parameter configuration in cells, and parameter configuration on the earth.
KPI daily report generating tool: classify key indicators according to a certain condition, and screen out the worst cells.
KPI Analysis Tools
CNO Tool: CNO tool has the KPI analysis function. So using it, you can screen out the worst cells according to various conditions, and point out the corresponding counter of an indicator.
Signal Trace: Trace the signaling (RNL signaling and RNL signaling) of RNC interfaces, which includes the Iu interface, the Iur interface, the Iub interface and the Uu interface (the signaling flow between RNC and UE at RRC layer). And RNL signaling trace is a common way for locating the KPI problem. Being able to trace the RNC signaling is a basic requirement for the on-site KPI optimization engineers and the network optimization and maintenance engineers. This signaling tracing tool is very powerful, which can trace signaling according to the UE cell and IMSI in the KPI analysis. According to the UE cell, it can trace the
O&M Handbook on ZTE Radio Technologies
Page 200
signaling of multiple subscribers, while according to IMSI, it can trace the signaling of only one subscriber. However, if the RRC connection is not established yet, signaling cannot be traced. That is because only when RRC connection has been established, can the RNC obtain the subscriber’s IMSI from the CN.
RNC ASS Log: ASS log is usually applied when there is abnormity and RNC signaling is out of trace. In this case, use ASS log to analyze the signaling before and after the abnormity occurs. Abnormity can be queried according to IMSI or cell ID. ASS log can be also used to collect various abnormities.
NodeB LMT: NodeB local operation and maintenance tool. Apart from all the operation functions of the OMCB, this tool can collect more detailed information about cells and UE. NodeB local maintenance terminals include: EOMS, EFMS, DMS, and PMS.
NodeBAbnormity Probe: On the site of WCDMA commercial office, NodeB abnormity probe is an effective tool to monitor the running state of the NodeB. Every module of NodeB can record the abnormal information automatically, which makes it easy to locate problems. However this method requires professional knowledge, such as knowledge about the function and interface of each module or board. If the on-site engineers cannot make the simple analysis, they can just obtain the abnormity probe and send it to the R&D engineers at the rear side. The abnormities reported on the NodeB will be stored at the OMCB server according to different RNCs. To conduct NodeB abnormity probe analysis, you need to download abnormity probe files from different OMCB servers and then use the abnormity probe tool to make a comprehensive analysis.
CTS Tool: CTS is a tool developed by the CN department, which can trace signaling in depth according to IMSI, and trace signaling across RNCs. So this is particularly suitable to trace VIP subscribers. In this case, CTS is easier to use than SignalTrace, which can only trace signaling of RNCs one by one. CTS can trace the interactive signaling between network elements (NEs) within the CN, as well as the signaling of the Iu interface and the Uu interface. This kind of signaling tracing is what we called in-depth tracing. The work principle of CTS is to set up an IMSI task on the CTS server and send it to the CN front side, which will then send this task to each CN module via the interfaces dedicated to the CN modules and the RNC, and then each module, after receiving the signaling related to the IMSI task, will send the signaling back to the CTS server via the CN front side. The interfaces mentioned above are private interfaces, so this tool can only support our own CN and RNC. CTS signaling can be checked and analyzed with an offline tool, but the offline tool does not work very well because of the lack of continuous optimization and perfection.
UE log: DT test is also an important auxiliary way in analyzing KPI indicators. There are many problems that cannot be located by tracing signaling at the network side, and can only be located by the use of UE log. The commonly used drive test software includes: QXDM/APEX (QCAT), CNT/CAN and TEMS. CNT/CAN and TEMS are often used for network optimization. For the use of CNT/CAN, please refer to the corresponding help file and the instruction
O&M Handbook on ZTE Radio Technologies
Page 201
document publicly released by the Network Optimization Tool Department. QXDM and the analysis tool APEX (QCAT) provided by Qualcomm is very powerful, which have contributed a lot for the stability and maturity of our system for many years.
11.3.2.3
General Process of KPI Optimization Analysis Basic analyzing ideas: KPI optimization is a process to find and solve problems. KPI optimization during the operation and maintenance stage is mainly to pick out the performance data that needs special attention from the OMC, classify these performance data, and then compare the value of these data with that required by the operator. If the value of an indicator is lower than the operator’s requirement, analyze this indicator and find out the factor that affect the indicator, and then propose a solution to the operator. If the values are higher than the operator’s requirement, there’s no need to pay special attention to them. KPI analysis is a process from the whole to the part. Step 1: Check the key indicators from the view of the whole network. If there is not any problem, just ignore them. Otherwise, try to locate the RNC NE that has the problem. Step 2: Analyze the indicators of the corresponding RNC to find out the RNC whose indicators have the problem. Step 3: Analyze the indicators of the cell under the problem RNC to find out the worst cells or TOP N cells. If the indicators of all the cells under the RNC are tend to be low, it is a common problem probably caused by parameter configuration. And then check whether the radio parameter configuration in the cells under this RNC is the same as that in the cells under the normal RNCs. Step 4: Make a comprehensive analysis on the KPIs, alarms, DT test data, and customer complains of the worst cells to find out a solution. Analysis method: After learning the KPI analysis ideas, we must know some common KPI analysis methods to rule out causes of problems from the obvious ones to the hidden ones. For example, we found that the TCP code words were strictly limited at eight sites near a park, and the call drop rate rose suddenly. How to solve this problem? Method one: First, we checked whether the alarms, transmission, and boards of these sites were normal. After they are proved all normal, we sent some engineers to the site to do test. And meanwhile, we traced the RNC signaling at the OMC. It turned out that the test result was normal, and the indicators of these sites of that day did not have any problem and code words were not limited. And later we knew from the news that there was a big gathering of about one million people at the park at that moment. Until then we came to know that the congestion was caused by too many users using the network at the same time.
O&M Handbook on ZTE Radio Technologies
Page 202
Method two: First, because the eight sites went worse all of a sudden, it was unlikely that the problem lied in the hardware. Then we checked whether the radio parameters had been modified the day before. The result is no worksheet had been issued to modify those parameters, and no alarm was found at those sites. Therefore, we excluded the possibility of hardware problem. Then we checked the traffic trend graph of the last few days (over seven days) and found that the high call drop rate might be caused by high traffic. The graph showed that traffic of each site rose suddenly on the day before. Thus we came to the conclusion that this was an abnormal abrupt event, which may have been caused by a gathering. And later we were told that there was a big gathering at the park. So we were assured the code words limitation and high call drop rate at the eight sites were caused by too many subscribers using the network at the same time. By comparing the two methods above, we can find that although the first one (sending engineers to the site, without the consideration of abnormal events) is commonly used, it is inefficient and costs more resource. The second method (analyzing the problem by the means of exclusion and association) is more efficient. From this case, we would like to emphasize that KPI analysis is a process of problem exclusion. Using the comprehensive methods (like Method One) at the first brush may be making a detour.
Exclusion method: Check the alarms on the OMC to learn about the state of the RNC, NodeB, BPC board, and the transmission. If there are obvious broken link in transmission or hardware problem, the cause of the problem is easy to locate.
Incident association: If the problem is with a great number of sites, take abrupt incidents into account, such as large-scale gathering, terrible weather of incorrect operation. These incidents will put influence of different levels and ranges on the network indicators.
Comparison of radio parameters: If some site goes wrong in a sudden, check whether the radio parameter configuration of this site is consistent with that of other normal sites. If not, change it as that of the normal sites, because the indicator decrease may be caused by an incorrect modification of radio parameters.
Relevant indicators association: If a certain indicator is in poor condition, check its relevant indicators and find the common problem from these relevant indicators.
Comprehensive problem location: When the above reasons are excluded, use DT data, KPI data, RNC signaling analysis data to locate the problem with indicators comprehensively.
O&M Handbook on ZTE Radio Technologies
Page 203
Figure 11.5 KPI optimization analysis process
O&M Handbook on ZTE Radio Technologies
Page 204
O&M Handbook on ZTE Radio Technologies
Page 205
11.4
KPI Optimization Analysis This chapter mainly demonstrates how to analyze the indicator problems from the aspect of OMC data, and provides flowcharts for KPI optimization. The detailed analyzing method and cases of every special subject can be checked in the optimization guides of all the subjects.
11.4.1
CS Call Drop Optimization The CS call drop rate is the most important indicator in KPI optimization.
11.4.1.1
Definition of Call Drop After checking the signaling on the Uu interface at the UE side, the engineer can judge the situation a call drop if the Uu interface message satisfies one of the following three conditions during the calling process (in connection). RNC Release is not received, but the UE condition changes from CELL_DCH to IDLE. RRC Release is received and the released cause value is Not Normal. One of the following three messages — CC Disconnect, CC Release Complete, and CC Release — is received, and the released cause value is Not Normal Clearing or Not Normal, Unspecified. In a board sense, the call drop includes the call drop rates of CN and UTRAN. The call drop of UTRAN includes the following two aspects: After the successful service establishment, RNC sends the RAB Release Request to CN. After the successful service establishment, RNC sends the IU Release Request to CN. Later, RNC receives the IU Release Command from CN. Note that RAN call drop statistics, which is defined from the aspect of lu interface signaling, means the launching times of RAB Release Request and lu Release Request of RNC. And the DT call drop statistics is defined from the aspects of the Uu interface message, nonaccess stratum message and cause value. RAN call drop statistics and DT call drop statistics are not exactly the same.
11.4.1.2
CS Call Drop Analysis Flowchart Figure 11.6 CS call drop analysis flowchart
O&M Handbook on ZTE Radio Technologies
Page 206
O&M Handbook on ZTE Radio Technologies
Page 207
11.4.2 11.4.2.1
11.4.3
PS Call Drop Optimization Optimization Flowchart Figure 11.7 PS call drop optimization flowchart
Optimization of Accessibility Indicators Accessibility performance includes the success rate of RRC connection setup and the success rate of CS/PS RAB assignment. These two kinds of KPIs play important roles in the network optimization and directly influence the success rate of CS/PS service establishment. In this document, this kind of problems are found from the aspect of OMC data, and solved through parameter optimization.
O&M Handbook on ZTE Radio Technologies
Page 208
11.4.3.1
Definition of Access Failure For the mobile originated call in the CS domain, the access failure event means that the UE sends RRC REQUEST, and IE establish cause is Originating Conversational Call, but alerting of the direct transfer message is not received. The relevant events are defined as follows in the access failure stage. RRC connection setup failure: After considering the resending times and the waiting time, the UE sends RRC CONNECTION REQUEST, and does not receive the response from RNC or RRC CONNECTION REJECT delivered by RNC. Initial direct transfer and security mode establishment failure: After sending RRC CONNECTION SETUP COMPLETE, the UE does not send NAS SETUP. RAB assignment failure: After receiving CALL PROCEEDING, the UE does not receive RB SETUP delivered by RNC. Or the UE replies with RB SETUP FAIL after receiving RB SETUP. Or the UE receives DISCONNECT with the cause value not being Normal Release after receiving RB SETUP. At this time, the UE has not reported RB SETUP CMP. Failure after RAB assignment:After the UE sends RB SETUP COMPLETE, the originating UE receives DISCONNECT/RELEASE from CN. Or the UE waits CONNECT or ALERTING overtime, and launches the Call Clearing process; Or the UE becomes IDLE before receiving Alerting, and starts to receive the system message. For the mobile terminated in the CS domain, the access failure event means that the terminating UE receives the paging of paging type 1, and does not send RRC CONNECTION REQUESTwith the cause value being Terminating Conversational Call. Or the UE does not send the alerting of direct transfer message to CN after sending RRC CONNECTION REQUEST. The relevant events are defined as follows in the access failure stage. RRC connection setup failure: After sending RRC CONNECTION REQUEST, the UE does not receive the response from RNC or RRC CONNECTION REJECT delivered by RNC. Initial direct transfer and security mode establishment failure: After sending RRC CONNECTION SETUP COMPLETE, the UE does not receive the SETUP direct transfer message. Or the UE sends RELEASE COMPLETE. Or the UE receives DISCONNECT from CN. RAB assignment failure: The UE does not receive RB SETUP delivered by RNC after sending CALL CONFIRM. Or the UE replies with RB SETUP FAIL after receiving RB SETUP. Or the UE receives DISCONNECT with the cause value not being Normal Release after receiving RB SETUP. At this time, the UE has not reported RB SETUP CMP. Failure after RAB assignment: After the UE sends RB SETUP COMPLETE, the terminating UE receives DISCONNECT/RELEASE from CN.
O&M Handbook on ZTE Radio Technologies
Page 209
11.4.3.2
Analysis on RRC Connection Failures The problem of RRC connection setup failure can be analyzed through the UE signaling flow and RNC single-user tracing. The RRC connection setup includes the following steps: The UE sends RRC Connection Request through the RACH channel. RNC sends RRC Connection Setup through the FACH channel. The UE sends RRC Connection Setup Complete through the dedicated uplink channel after the downlink dedicated channel is established and synchronized. RRC connection setup failures are always caused by following issues: Uplink RACH problem Problem about downlink FACH power allocation proportion Parameter reselection problem of the cell Low downlink dedicated initial transmitting power Uplink initial power control problem Congestion Equipment malfunctions Among these issues, the problems of uplink RACH, downlink FACH power allocation proportion, and parameter reselection of the cell and equipment malfunctions appear more frequently.
O&M Handbook on ZTE Radio Technologies
Page 210
Figure 11.8 Analysisflowcharts of RRC connection setup failures
O&M Handbook on ZTE Radio Technologies
Page 211
UE sends RRC Connection Request, but RNC does not receive it
l
If the Ec/Io of downlink CPICH is relatively low, it is the problem of coverage.
l
If the Ec/Io of downlink CPICH is not very low (for example, the value is larger than -14 dB). Usually, it is the problem of RACH, and the following issues may cause the problem:
The power of Preamble does not rise to a required value, and the rising times of Preamble should be increased.
The output power of UE is lower than the required value, which is caused by poor UE performance. In this case, the UE should be changed.
The NodeB equipment has a standing wave and the engineer should check whether Node B has any SWR alarm.
The radius of the cell is set improperly. If the radius parameter of the cell is set too small, the NodeB cannot synchronize the UE beyond the range of the radius, and the access fails. This problem often happens in the places with large coverage, such as the rural areas and the suburbs.
RNC delivers RRC Connection Reject after receiving RRC Setup Request. When RRC Connection Reject appears, the engineer should check the specific reject cause value. Usually, there are two kinds of causes: The CPU load of RNC control plane board is too heavy and more boards should be added. DCH and FACH admission is rejected. However, this situation does not always happen. UE does not receive RRC Connection Setup delivered by RNC This problem may be caused by the following reasons: Poor coverage Improper parameters of cell selection and reselection Checking method: The engineer should check the Ec/Io of CPICH. If the value is lower than -12 dB (Ec/Io is -12 dB by default), and there is no cell of better quality in the monitor set, the cause of this problem is poor coverage. If there is better cell in the monitor set, cell reselection may cause this problem. Poor coverage can be improved by coverage enhancement, such as adding some sites to cover the places without signal coverage and adjusting the engineering parameters. If the coverage cannot be improved, the engineer can enhance the FACH power according to the PCPICH Ec/Io coverage of the current network. For example, if all the pilot Ec/Io values are larger than -12 dB in the coverage area, the power proportion of the common channel should be configured on the basis of the situation that the Ec/Io value is larger than -12 dB. And so, the success rate of the idle UE assessment can be ensured.
O&M Handbook on ZTE Radio Technologies
Page 212
As for the access problem caused by cell selection and reselection, the engineer can speed up the cell selection and reselection by adjusting the cell selection and reselection parameters, and the problem of RRC connection setup failure caused by improper cell selection and reselection parameters can be solved. Note: The RRC Connection Setup message is borne by FACH. RRC Connection Request sent by the UE is received by UTRAN at the preamble of PRACH, and then it is sent from the RACH channel based on the current preamble power. And the transmit power of preamble can rise all the time until the response is received (There is a limitation for the maximum number of preamble retransmissions). Therefore, in the areas with poor coverage, the RACH coverage and FACH coverage may become unbalanced, and as a result, UTRAN can receive RRC Connection Request sent by the UE but the UE cannot receive RRC Connection Setup sent by RNC.
UE receives RRC Connection Setup and does not send RRC Setup Complete If the downlink signal quality is normal, this problem may be caused by the abnormal condition of the cell phone. Another reason of this problem may be the downlink synchronization failure caused by the low initial power of downlink dedicated channel. You can solve this problem by adjusting the service downlink Eb/No. RNC does not receive RRC Setup Complete sent by UE Because the uplink initial power control mayincrease the UE transmit power, this kind of problem seldom appears. If it appears, the engineer can increase the Constant Value of the dedicated channel properly to raise the uplink DPCCH initial transmission power of the UE. At the same time, this problem is also relevant with the uplink SIR initial target value configuration because this value may affect the uplink initial synchronization at the initial stage of link setup. If the value of the parameter is set too large, there will be too much uplink inference brought by the initial setup of the link. If the value is set too small, the uplink synchronization will take longer time, and the initial synchronization may even fail. This parameter is an RNC-level parameter, which has a great influence on network performance. Therefore, the engineer should be cautious while adjusting this parameter. Note: RRC Connection Setup Complete is sent through uplink DPCH, and the UE calculates the initial power of uplink DPCCH according to the received IE”DPCCH_Power_offset” and the measured CPICH_RSCP value. DPCCH_Initial_power = DPCCH_Power_offset - CPICH_RSCP DPCCH_Power_offset = Primary CPICH DL TX Power + UL Interference + Constant Value. The Constant Value can be configured in the OMC. If this value is set too small, the UE may not have enough power to send RRC Connection Setup Complete.
O&M Handbook on ZTE Radio Technologies
Page 213
11.4.3.3
Analysis on RAB/RB Setup Failures When RAB or RB setup fails, RNC will send RAB Assignment Fail in the RAB Assignment Response signaling. The engineer can find out the specific failure reason from the failure cause value carried in relevant cells. The reasons for common RAB/RB setup failures include: l
RNC directly rejecting RAB Setup Request because of wrong parameter configuration
l
Admission reject
l
RAB setup failure because the UE fails to respond to RB Setup Request
l
RAB setup failure because the Uu interface fails to set up RB
Figure 11.9 Analysis flowchart of RAB setup failures
O&M Handbook on ZTE Radio Technologies
Page 214
RNC Directly Rejecting RAB Setup Request Because Of Wrong Parameter Configuration The case that RNC responds with RAB Setup Failure directly is seldom caused by invalidparameter configuration in the business network. Usually, this case is caused by special operations of the special users. The main scenario is that the subscription information of the user’s PS service is beyond the capability of the UE, which leads to the direct refusal from RNC. For example, a special user’s subscription rates of uplink and downlink are 384 K, but the maximumuplink rate of
O&M Handbook on ZTE Radio Technologies
Page 215
the UE is only 64 K. The maximum uplink and downlink rates of the QoS message used for activating PDP set by the AT command or mobile terminal software used by the user are 384 K, so the RNC will find the maximum uplink rate is beyond the UE’s capability, directly reply withRAB Setup Failure and will not launch the RB setup process, when it receives RAB Assignment Request. After the RAB setup fails because the parameter configuration is beyond the UE’s capability, SGSN will negotiate again to launch the new RAB assignment until the UE has the capability to support the assignment, and the RAB assignment is finished. For the users, the PDP activation is still successful, and the actual maximum rate is the maximum rate the UE can support. However, if the minimum guaranteed bit rate required by the QoS setting in the UE’s PDP activation request is beyond the UE’s capability, though the network negotiates a lower rate to accept the UE’s PDP activation request, the UE will launch the request of deactivating PDP when it finds that the rate negotiated by the network in PDP activation accept request is lower than the minimum guaranteed bit rate, and finally the PDP activation cannot be completed.
Admission Reject For the non-HSDPA user, if there are insufficient system resources (including power, channel code, lub transmission resource and CE), the call establishment failure will be caused by the admission reject. At this time, it is necessary to check the network load, code resource, lub transmission resource and CE resource occupation to make sure the congestion is caused by the limitation of a certain kind of resource. What is more, the engineer should plan the corresponding expansion method. If the cell does not support the HSDPA service, the R99 user admission is judged according to the fixed R99 admission threshold. If the cell supports the HSDPA service, and the HSDPA and R99 dynamic power is allocated, the uplink admission of non-HSDPA is judged based on RTWP or the equivalent user number. If the uplink load is too heavy, the nonHSDPA user admission will also fail. If the bandwidth configuration on the lub interface is insufficient, the lub interface will reject the R99 data service activation because of limited bandwidth. The admission control of the NodeB Credit resource is similar to the power admission control. Whether the remaining Credit can support the currently requested service or not can be judged according to the spectrum spreading factor of the new access user. According to the condition of the RAB Downsizing Switch, RNC will deal with the issue in the corresponding way. For the HSDPA user, in the dynamic power allocation mode, besides the mentioned system resources such as the power, channel code, lub transmission resource and CE, the admission reject should take into consideration whether the number of H users supported by NodeB and the number of H users supported by the cell are over the regulated threshold or not into consideration.
O&M Handbook on ZTE Radio Technologies
Page 216
For the HSDPA user, when the bandwidth configuration on lub interface is insufficient, the admission reject will not happen, but the rate will be reduced. What is more, the AAL2PATHs of HSDPA and R99 are configured respectively, and the HSDPA AAL2PATH must be configured to the HSDPA_RT or HSDPA_NRT type. If the HSDPA AAL2PATH is configured to RT or NRT of R99 AAL2PATH type, the RAB assignment failure will not happen, but RNC will establish the HSDPA service as R99 384 Kbps. For the downlink power admission, Besides whether the R99 service load is over the non-HSDPA service threshold, DCH service should take into consideration whether non-HSDPA power and HSDPA GBP (the minimum power needed for the guaranteed bit rate) are over the general power threshold of the cell. For the HSDPA service, it is necessary to check whether the throughput rate provided by the cell is over the sum of all the users’ GBR thresholds, or whether the GBPs of the stream service and the background service are over the HSDPA power of the cell. At the same time, whether the non-HSDPA power and the HSDPA GBP (the minimum power needed for the guaranteed bit rate) are over the overall power threshold of the cell should be also taken into consideration. For the lub admission, For the DCH service, the admission is made according to the multiplication of the peak rate and the service activation factor. For HSDPA service, the admission is made according to the GBR. If the lub exceeds the congestion threshold, the DCCC rate reduction will be triggered. And if the RLC_AM retransmission rate is over a certain threshold, the Iub Overbooking switch can be opened to trigger the TF which limits R99 or to reduce the rate of HSDPA service by a certain factor.
RAB Setup Failure Because the UE Fails to Respond to RB Setup The UE fails to respond to RB setup mainly because of the user’s operation. Take the following cases as examples: l
When the user already has had the downlink 12 K data service, he receives RB Setup Request of the VP service (either the originated call in the VP domain or the terminated call in the VP domain). Because the UE does not support the VP and high-speed PS service in the downlink at the same time, it directly replies with RB Setup Failure, and the cause value is unsupported configuration.
l
Compared with the WCDMA subscriber originating the VP service, the terminating subscriber resides in the GSM network, and so it does not support the VP service. After RNC receives RAB Assignment Request, the core network will deliver the Disconnect command right after call proceeding, and the cause value is Bearer capability not authorized. At this time, the UE has just received the RB SETUP command and has no enough time to finish the RB setup. So the UE will reply withRB Setup Failure after it
O&M Handbook on ZTE Radio Technologies
Page 217
receives the Disconnect command, and the RNC will reply withRAB Setup Failure, with the cause value being failure in radio interface procedure. RAB Setup Failure Because the Uu Interface Fails to Set Up RB RNC sends the Radio Bearer Setup command to the UE but fails to receive Radio Bearer Setup Complete. This kind of situation (RB setup failure) often appears in the cells with weak signals. There are two causes of weak signals: one is that the UE does not reside in the best server to launch the access, and the other is poor coverage. l
If the UE does not reside in the best server to launch the access, it will hope to enter the best server through active set update in the RB setup process (At the same time, the fast signal change will drastically weaken the signals in the cell), but the active set update can only be processed after the RB setup is completed, because the procedures can not be processed alternately (Neither the network nor the terminal supports it). Therefore, RB can only be set up in the cell with weak signals, and the setup is easy to fail. As for this situation, the starting threshold and speed of cofrequency cell reselection should be increased to make the UE reside in the best server and launch the access as soon as possible.
l
RB setup failure may be caused by the poor downlink/uplink coverage. If the failure is caused by downlink coverage, the UE cannot receive the Radio Bearer Setup command, which may be caused by the uplink interference, and this can be fixed through checking RTWP. The poor downlink coverage is partly caused by the bad UE demodulation performance, and other causes should be solved by RF optimization.
11.5 Practical Scenarios of KPI Improvements 11.10 Illustration on RAN and KPI
O&M Handbook on ZTE Radio Technologies
Page 218
KPI has been grouped in following four major Groups and the individual kpi under the group to be monitored in the busy hours and suitable action need to be taken for optimization of the service KPI’s.
a) Usage: i. Cell Availability ii. Ave. Uplink Load iii. Ave. Downlink Load iv. HSDPA Throughput v. Cell Throughput b) Accessibility: i. RRC Setup & Access Rate ii. RAB Setup & Access Rate iii. Call Setup Success Rate iv. PS setup success rate (HSDPA, HSUPA) c) Retain ability: i. RRC Drop Rate ii. RAB Drop Rate iii. PS success rate (HSDPA, HSUPA) d) Mobility: i. SHO/ISHO Success Rate ii. SHO Overhead iii. HDSPA/HSUPA SCC success rate
11.5.1
Call Setup Failure Scenarios – • • –
– – –
11.5.2
RF issue Interference / Dominance / Coverage Missing neighbour System Issue - BTS • No response to “RRC Connection Request” • “RRC Connection Reject” to “RRC Connection Request” System issue - RNC • “CC Disconnect” after “Call Proceeding” due to “DL RRC Connection Release” Core NW • “CM Service Abort” after “CM Service Request” System issue (test number) • “CC Disconnect” after “CC Progress” Call Drop Scenarios
RF issue – Interference / Dominance / Coverage – Missing Neighbours System issue BTS – Sudden “CC Disconnect” due to “DL RRC Connection Release” – Sudden drop to idle, no disconnect messaging System issue RNC
O&M Handbook on ZTE Radio Technologies
Page 219
– 11.5.3
Sudden “CC Disconnect” due to “DL RRC Connection Release” KPI Definitions
The KPIs to be monitored from the RAN are: –
Cell availability
–
Call Setup Success Rate (CSSR)
–
Call Drop rate
–
SHO/ISHO/HSPA SCC success rate
–
Packet Session setup/success rate (NRT( no real time), HSDPA, HSUPA) In MINOS(OSS):
–
RNC counter description
–
NetAct DB description for RNC measurements
–
WCDMA RAN Key Performance Indicators
–
Key Indicator Changes
–
Measurement Changes
11.5.4
AMR CS Call Phases
11.5.5
Call Setup Failure Analysis
O&M Handbook on ZTE Radio Technologies
Page 220
11.5.5.1
Call setup failures – Missing Neighbour – – – –
11.5.5.2
Missing neighbour analysis over the whole route (3G-3G, 3G-2G) Search for failures due to missing 3G-3G neighbours Search for failures due to missing 3G –2G neighbours It is suggested to place 2G scanner to the test vehicle
Call Setup Failure Analysis- Block B The purpose of this activity is to check the Random Access Process is working adequately by investigating whether AI (Acquisition Indicator) has been received through DL AICH If AICH was not received by UE, the cause of the problem can be classified into: Inadequate RAN parameter related to Random Access: RAN parameter settings for preamble transmission or open loop power control information is not correct. UL Coverage limit: UL coverage of UE is smaller compared to serving cells DL coverage so that UE’s Tx power cannot reach serving cell.
O&M Handbook on ZTE Radio Technologies
Page 221
Call Setup Failure Analysis- Block B
Call Setup Failure Analysis- Block B
O&M Handbook on ZTE Radio Technologies
Page 222
11.5.5.3
Call setup failures – System issue BTS-C
“RRC Connection Reject” after “RRC Connection Request” – – –
Good RF conditions Admission Control can reject too many (or admit too many) connection requests due to wrong PrxNoise measurements. PrxNoise statistics, receive link parameters and HW units to be checked 11.5.5.4
Call Setup Failure Analysis-C UE has the appropriate DL/UL coverage but if RNC does not allow to set up the RRC connection of the requested RAB (Radio Access Bearer), Call setup will fail. Admission Control (AC) is involved in RRC connection setup. AC can reject RRC reject RRC connection Setup due the DL Load, UL load or DL Spreading codes – Marginal Load Area: • If measured UL (PrxTotal) or DL (PtxTotal) load exceeds target thresholds (PrxTarget and PtxTarget) AC can still admit new RAB to the cell if a new noncontrollable load keeps below target thresholds (in practice this means that AC can admit only new controllable load RABs i.e. NRT RABs) – Overload Area: • If measured UL (PrxTotal) or DL (PtxTotal) load exceeds overload thresholds (PrxTarget + PrxOffset and PtxTarget+ PtxOffset) then AC can't admit more RABs to the cell
–
– – – 11.5.5.5
During the pre-optimization phase it is unlikely that AC will stop an RRC connection setup during the drive testing because there are normally very few UEs in the network. (Traffic loading is trivial) However, it should be checked that measured PtxTotal and PrxTotal are less than PtxTarget (e.g. 40dBm) and PrxTarget (e.g. 4dB, 60% loading) respectively. If DL AC does not allow RRC setup check the Tx power of WBTS, # of channels transmitted, Signaling messages. If UL AC does not allow RRC setup: Check out if there is an interfering source nearby the serving cell
Call Setup Failure Analysis-D
O&M Handbook on ZTE Radio Technologies
Page 223
– –
To check if Layer 1 Synchronization (slot/frame sync) has failed If “RRC Connection Setup” was received by UE but UE does not send “RRC Connection Setup Completed”, we will report “L1 synchronization failure” and have to check L1 system messages.
Call setup failures – System issue RNC-D “CC Disconnect” after “Call Proceeding” Good RF conditions Failures in RAB setup occur between the “RAB Assignment Request” being received from Core Network and the RAN sending out Radio Bearer Setup. Therefore the failure is between BTS and Core Network.
11.5.6
Low in CSSR?
O&M Handbook on ZTE Radio Technologies
Page 224
Call Setup Phases – – – – –
CSSR affected if any of the followings take place. RRC Conn. Setup Fail RRC Conn. Access Fail RAB Setup Fail RAB Setup Access Fail
RRC/RAB Setup & Access Analysis Process Flow Chart
11.5.6.1
Call Setup Success Rate (CSSR) Poor CSSR could be a result of – Poor coverage or dominance or interference issues in Radio interface – Capacity issues in Radio or Iub interface – Configuration issues in BTS (parameters or HW) CSSR is essentially RRC Setup Success * RAB Setup Success (or successful PS session setups in case of PS call)
O&M Handbook on ZTE Radio Technologies
Page 225
CSSR covers all the steps from the initial RRC connection request from the UE to the network, through the RRC setup phase and the RAB setup phase, and until user data is starting to get transferred.
11.5.6.2
RRC connection set up failure RRC Connection is rejected ICSUcannot process the call – –
11.5.6.3
No processing power on ICSU unit Incoming call request cannot be handled due to lack of Interface Control and Signalling (ICSU) processing “No hand free” is RNC internal clear code.
Call Setup Failures
O&M Handbook on ZTE Radio Technologies
Page 226
11.5.7
11.5.7.1
Call Drop Analysis Process
Call Drop Analysis process – SHO Analysis
O&M Handbook on ZTE Radio Technologies
Page 227
11.5.7.2
Drop call failures – RF issue – – – – – –
11.5.7.3
Drop call failures (Scrambling Code (SC) conflict) – – –
11.5.7.4
RF drops mostly due to poor dominance or interference Poor coverage could lead to ISHO, although poor dominance or interference can cause ISHO to fail. Rapid field drop can cause drop due to coverage Poor dominance or interference can cause Compressed Mode (CM) to start even if RSCP is still good. In CM UE transmits with higher power (more interference) and spends less time on 3G (less accurate measurement reporting) Poor dominance or interference can lead to Active Set update failures and eventually to drop call.
Sudden drop to idle mode (no disconnect messaging) Cause of the failure: overshooting site and SC reuse Short term solution to add overshooting neighbour in ADJS definitions
Drop call failures – System issue RNC or BTS ?
“CC Disconnect” due to “DL RRC Connection Release” is just a consequence of failure which can be due to different reasons From UE point of view L3-messaging does not identify the point of failure distinctly BTS or RNC failure? => Suspect BTS first, then RNC Rule out BTS failures Check the site performance from Counters (Iub, Service level, cell resources SHO, etc) and that site is carrying traffic PrxNoise, receive link parameters, alarms SC( Scrambling Code)-–reuse UE performance ? Identified causes for Active Set Update failure “Deaf” sites (PrxNoise) Faulty HW
O&M Handbook on ZTE Radio Technologies
Page 228
11.5.8
3G Node- Optimization / Tuning Guide ( Followed in UP( E ) Circle )
11.5.8.1 IRAT handover from WCDMA to GSM and Vica-versa ( To optimize the Node-B PS and CS traffic as the case may be ) The details of the various optimization scenarios are shown below. The scenario 7 will maximize both CS and PS but in case DATA traffic is at higher side and there is heavy traffic then Node-B to be off loaded partially by changing CS scenario to optimization set 2 or 3 as per requirement or on which result is better. Inter RAT Measurements (PS)- Cell Reselection
S N
Inter Frequency Measurements (CS & PS)
TRFC ATINT ERMI DX
EVTMEA SRSCP (interfreq)
EVTMEASE CNO (interfreq)
E2D RSCP
E2F RSCP
E2D EcNo
E2F EcNo
1
2013 Multi Strategy
200
3100
3000
-115
-113
-17
-13
2
Highway Improvement Project (HIP) - Step2
100
2100
2000
-96
-93
-12
-9
3
Highway Improvement Project (HIP) - Step1
110
4110
4120
-100
-97
-14
-11
4
Coverage Edge
300
8100
8000
-101
-98
-17
-13
5
Optimization - Set 1
400
4501
4801
-92
-90
-16
-14
6
Optimization - Set 2
410
4502
4802
-95
-92
-14
-11
7
Optimization - Set 3
420
4503
4803
-105
-101
-16
-13
8
Festive_Standby
600
6500
6800
-90
-87
-12
-9
-
9
Optimization
400 499
1 0
500 599
-
Trial/Testing Purpose
1 1
600 699
-
Festive/Special Event
Carrier
4500 4599
-
5500 5599
-
6500 6599
-
4800 - 4899 5800 - 5899 6800 - 6899
Inter RAT Measurements (CS)- Cell Reselection
O&M Handbook on ZTE Radio Technologies
Page 229
S N
Inter RAT Measurements (CS)
TRFC ATINT ERMI DX
1
2013 Multi Strategy
200
1100
1000
-105
-101
-16
-13
2
Highway Improvement Project (HIP) - Step2
100
75
25
-96
-93
-10
-8
3
Highway Improvement Project (HIP) - Step1
110
75
25
-96
-93
-10
-8
4
Coverage Edge
300
45
18
-99
-95
-16
-13
5
Optimization - Set 1
400
4600
4900
-99
-95
-16
-13
6
Optimization - Set 2
410
4600
4900
-99
-95
-16
-13
7
Optimization - Set 3
420
4600
4900
-99
-95
-16
-13
8
Festive_Standby
600
6600
6900
-90
-87
-12
-9
-
9
Optimization
400 499
1 0
500 599
-
Trial/Testing Purpose
1 1
600 699
-
Festive/Special Event
EVTMEA SRSCP2 (interRAT)
EVTMEASE CNO2 (interRAT)
E2D RSCP
E2F RSCP
E2D EcNo
E2F EcNo
Carrier
4600 4699
-
5600 5699
-
6600 6699
-
4900 - 4999 5900 - 5999 6900 - 6999
Note :- UP( E) Circle has adopted Optimization set no 7 and resulting H+ signal through out city and better customer experience in 3G data and High Speech traffic volume in the 3G. 3G even takes load upto 25 Erl in busy hours and easing out congested 2G network 11.5.8.2
Setting HSDPA and HSUPA users and DCH users
Setting Maximum nos. of HSDPA and HSUPA users
The HSDPA and HSUPA users to be made maximum 64 for maximizing the 3GDATA throughput.
Setting Maximum DCH Users in ZTE 3G Node-B. a)
b) c)
The setting of DCH value is a tricky situation. UP(E ) Circle has adapted following practice recently with encouraging results. Otherwise 3G data was stagnated and capacity of 3G node – b was exhausted and per node B data was stagnant. Now with tuning of Max nosof DCH values. The resources has been channelized for HSPA users for better 3G data download volumes. The DCH users are part of R99 users so it has priority and HSPA user get the balance power and code left out after R99 utilisation. In the urban area and high traffic area, in a few cases, it is observed that even on full signal with no browsing, This case is because of very high no of DCH users eating away all resources (code as well as power) of Node-B. Very high nos. of DCH users eat away the all code and power resource of Node-B as smartphone uses very low rate data on the background services and Node-B reaches to its user limit of DCH.
O&M Handbook on ZTE Radio Technologies
Page 230
d) e) f) g)
So as DCH users need to be restricted up to 4 to 16 depending on the targeted coverage area of the Node-B. In case, in dense urban areas where signal do not intended to reach beyond 500 meters and all can get HSPA, DCH can be safely set as 4-6 for users on periphery of the cell. In case, the node-b serving the area a bit larger say 500 to 1500 meters in the outskirts. DCH can be set 6-16 to serve the users at distance more than 500 meters. After application of any kind of change, Drive test is must and KPI to be monitored for any adverse impact. Optimization is always a tradeoffso , the priorities to be defined before application of any optimization set.
O&M Handbook on ZTE Radio Technologies
Page 231
Chapter 12 ZTE NEC-iPasolink200 Mini-link Installation _____________________________________________________ 12.1
Introduction ZTE has provided iPasolink200 mini-links to BSNL. iPasolink is NEC’s most advanced transport product family, providing solution for backhaul optimization and cost efficient integration of both TDM and Ethernet network. It has following features:
iPasolink 200 has two built –in Modems that can support a basic configuration of 1+0 /1+1. iPASOLINK 200 provides up to 460 Mbps with flexible combination of native TDM and/or native Ethernet transmission and advanced adaptive modulation scheme operating in 6, 7, 8, 10, 11, 13, 15, 18, 23, 26, 28, 32, 38 and 42 GHz bands. Full range of synchronization (TDM, Sync Ethernet). Hitless AMR up to 256QAM with adaptive QoS. The following protection is available on a single IDU: Protected (1+1) with hot standby/ space diversity / twin path with hitless switch. Non protected (1+0), back -to-back configuration ((1+0) x 2) or Dual the capacity with XPIC (2+0) on a single IDU. Air capacity: Up to 460 Mbps by single polarization and 920 Mbps by dual polarizations for Ethernet packet transmission.
12.2ODUInterface
O&M Handbook on ZTE Radio Technologies
Page 232
12.3
IDUInterface
DetailsforIDUInterface
O&M Handbook on ZTE Radio Technologies
Page 233
12.4
InstallationModesforOutdoor ForBSNLproject,15G&18Gare available,andall ofthe configurationare 1+0,so the ODUis directlymountedtothe antenna. 1+0 Unprotected(for13to38GHzODU)
12.5ChangethePolarizationofAntenna (Optional) 1.
Loosen thescrewstoallowthefeederboomrotatefreely.
2.
Rotatethefeederboom90 degreestotheleft ortotheright.
3.
Tightenthescrewsand applyglue around thescrews.
Polarizationchange Procedure
O&M Handbook on ZTE Radio Technologies
Page 234
12.6ODUInstallation lApplying theappropriatelubricant.
lInstallingtheODUontheantenna 1. Keeps thepolarizationindicatoron theODUpointingtothepolarizationdirectionof theantenna(Be carefulnot todamagetheO-ring ofAntenna).
O&M Handbook on ZTE Radio Technologies
Page 235
2.
Insertguide pinon thehole ofthebracket tosetthepositionofscrews.
3.
Align theflangeofODUwiththatoftheantenna.
4.
FastenthefourM6 screwstofixODUon theantennabracket.
O&M Handbook on ZTE Radio Technologies
Page 236
12.6.1 ODUGroundingCableInstallation 1.
2.
Connectthegroundingcable tothenearestgroundingpointoftowerorgrounding copperbus bar. (16mm2yellow-green cable). RemovetheantirustcoatingandoxidelayerbeforeconnectingODUgrounding cabletothetowergroundingpoint.Make waterproofandantirusttreatmenttothe grounding pointafterconnecting.
ODUGrounding
3.
Ifgroundingbarisnotavailableonthe tower,connectthegroundingcableto tower body. Thecableshouldbeshortest length. Itisnecessarytousethecrimpingtoolof a propersizeforcrimp theground cable and thelugterminal.
O&M Handbook on ZTE Radio Technologies
Page 237
12.6.2 IFcableInstallation Note: BindtheIFcablefirst to preventits type-Nconnectorfrombeingpulled. Takewaterproof measures (waterproofcurves)forthepartoftheIFcablebelowthe ODUandthepartoftheIFcableoutsidetheIDUroom. DowaterprooftreatmenttotheODUIFcableconnector.Whenwindingtape, theupper layershouldcover 2/3ofthe layerunder it.
ReserveIFcableofproperlength (5m~10mrecommended)attheODUend. Makeitinto a circleandfixontower.
Tiethe cableevery 1.0m~1.5m.IFcablesshall belinedandtied closelytogether. Distancebetweentiesshould be constant.
O&M Handbook on ZTE Radio Technologies
Page 238
Onthetower, ifthe cablecrossing the horizontalmember,thecablewillbeplacedto the sideoftower member toavoiddamagefromtherigging work.
The feeder musthave awaterproofarchbeforeenteringanequipmentroom.
O&M Handbook on ZTE Radio Technologies
Page 239
12.6.3
GroundingIFcable lGrounding Points
1. Theplaceaboutone meter away fromtheIFinterfaceoftheODU 2. Theplaceabout0.5to1 meter away fromthe cableentryofequipmentroomor outdoorcabinet 3.Theplaceontheroofedgeaboutonemeterawayfromtheturning pointofthewiring ladder 4. The middle pointofthe cable(whenthe cableis longerthan60 meters)
5.Theplaceontheroofedgeaboutonemeterawayfromtheturning pointofthewiring ladder(whenthehorizontal portion ofthe cableonthe roof-topislongerthan30 meters) 6. The middlepointofthehorizontal portionofthe cable(whenthehorizontal portion onthe rooftopislongerthan60meters)
Note: Thegroundingpointdepends ontheinstallationmodeandthelengthoftheIFcable. Generally, theIFcableshould begroundedatminimumthreepoints. WhentheIF cableis longerthan60 meters, adda grounding pointforevery extra 30 meters. Antenna shouldbelocatedinprotectiveareaoflightning arrester,andthearea is a 45° arcarea fromthetopoflightning arrester.(This areamay be30°fromthetop according to technicalagreementorprojectdesignrequirements).Lightening
O&M Handbook on ZTE Radio Technologies
Page 240
protectionangleshouldmeet thebelowrequirements:Forplainarea:≤45°, Formountainorlightening area:≤30 o
InstallingGrounding Clip Selectingtheinstallationpositionofthegrounding clipand strippingoffthecable sheath.
Fixingthegrounding clip and waterproofingit. Theanglebetweenthegroundingwireoftheclipand theIFcableshouldnotbe larger than15degrees.WhentheIFcable is verticallyrouted,thegroundingwireoftheclip shouldbe led downwards.
O&M Handbook on ZTE Radio Technologies
Page 241
12.7
IndoorUnitInstallation
12.7.1InstallingtheRack 1.
Confirmtherackinstallationposition
2.
Fix therack
3.
Installrackgroundingcable.
O&M Handbook on ZTE Radio Technologies
Page 242
12.7.2
IDUInstallation BeforeinstallingIDU in19-inch rack,should bere-tightenthe screwsofthebracket whilecorrectingtwobrackets to90 degreesforIDUmount horizontally.
WhentwoIDUormoreis installedin the 19inchrack,itisnecessary tohave the space of1UbetweenIDUforheatradiation.
12.7.3
PowerCableInstallation
The DCpower cable(1.5mm2red/blue)should be keptsomespare lengthforremove the power plug, andfixitto19 inch rack,fixingabout0.2m intervalsby cableties. For st rd BSNLproject,weusethedownoneasthemainPowerinterface,and 1 pinas-48V, 3 pinasGND.
Mustcutoutsomeextrawiresaccording totheholesizeofthepinofthepower plug.
O&M Handbook on ZTE Radio Technologies
Page 243
Itisnecessary touse the crimping tool ofa propersizeforcrimp thepower cableand the pin ofpower cable.Orusesoldering.
12.7.4 IDUGrounding TheIDUgrounding cable(10mm2 yellow-green)should be shortestlength as possible andattachedtothe19 inchrackcommonearthling pointdirectly. lGroundingfor new19 inch rack
lGroundingforexisting19inch rack
O&M Handbook on ZTE Radio Technologies
Page 244
2 Themain grounding cable(16mm yellow-green)connectedthegrounding barand 19inchrackcommon earthingpointbyshortestlength.
12.7.5 E1cableconnectionfor120ohmunbalance interface All120 ohmE1 cablesmustconnectedtothe DDF(Kronepanel)usesby the correct punchingtool
TheE1 cableistobe stripped with sufficientlength toreachtheDDFandunusedwires tobe cut. Andshouldtiecabletogether andwiringtobe neatlyrunaroundsideof19inchracktotheKronepanel.
O&M Handbook on ZTE Radio Technologies
Page 245
DDFwiring fortheE1 pairwiresaccordingtothewirecolorcode. TheE1 PortNo.has beenalreadymarkedonthe cable.
12.7.6 Labeling ForIDU
ForAntenna
Use Mark-Pen towritetherelatedinformation.
O&M Handbook on ZTE Radio Technologies
Page 246
Appendix – A Frequently Asked Questions _____________________________________________ 1
How to reduce SDCHC Congestion when SDCCH_Cong_Rate> 1 %? Reasons a. Check carried Traffic from traffic report b. Defining Proper No of SDCCH Channels (Default value: up to 2TRX->SDCCH 1 TS, above 2TRX to 4TRX->SDCCH 2 TS, above 4TRX to 6TRX->SDCCH 3 TS, above 6TRX->SDCCH 4 TS.) c. Dynamic SDCCH may be defined d. Check Hardware Faults and Transmission Alarms e. Problem in TRX in which SDCCH is defined etc. f. If a cell having SDCCH blocking with less TCH traffic, then increase the SDCCH in that cell. RF Activity
a. Optimize LAC boundary b. BTS Boundary ==èDefine sufficient SDCCH Channels c. Increase Cell Reselection Hysteresis (crh) to shift the Location Area Border 2
How to reduce TCH Congestion when TCH_Cong_Rate > 2 % ?
O&M Handbook on ZTE Radio Technologies
Page 247
Reasons a. b. c. d. e. f. g.
Check carried Traffic from traffic report Check Hardware Faults and Transmission Alarms Check TRX and Time slots Faults—(Idle/ low traffic handling TRX) Power adjustment (BS TX Power max)(in exceptional cases) AMRHR may be done Lowering of HR triggering thresholds. Directed retry/Traffic Handover may be enabled RF Activity
a. Antenna Adjustment for Serving Cell/Neighbor Cells– Increasing Mechanical/Electrical tilt , Lowering Antenna Height , Changing Antenna Azimuth etc. b. Planning for additional Cabinet (1800 band) or increasing TRX/ rearranging the existing configuration.* c. Load sharing in OL/ UL on basis of Path loss Criteria d. Fourth sector may be introduced at the same BTS. e. Last option: Introduction of new BTS 3
How to reduce call drop when call_drop_rate > 2 % ? Reasons a. b. c. d. e. f. g. h. i. j.
Check Hardware Faults and Transmission Alarms Check Transmission error Due to Interference (ICM Band value should be=
