GSM Product Training Technical Cases HUAWEI Confidential GSM Product Training Technical Cases 2013 GSM Product Training Technical Cases HUAWEI Confidentiali Table of Contents BSC6900 Troubleshooting Cases ............................................................................................... 1 Case1. Cannot login weblmt in some office due to different IP proxy settings ......................... 1 Case2.A interface main and standby boards frequently switch in one BSC caused by other BSC in BM-TC separated when done A over IP ............................................................. 3 Case3.Can register network but can't call due to GTC type set error ................................... 4 Case4.Problem adding SPU boards in GU mode ................................................................ 5 Case5.SPUb board unavailable in new subrack .................................................................. 7 Case6.Problem in integrating TC subrack with BM .............................................................. 8 Case7.OMU IP Address Configuration Error due to BSC6900 upgrading from V9R13 to V9R15 ..................................................................................................................................10 Case8.Direct tunneling between MBSC and GGSN is not working .....................................12 Case9.Can't active cell due to Configuration & License inconsistent...................................14 Case10.Low downlink TBF establishment successful rate due to paging congestion ..........16 Case11.Rebalance XPU CPU Load ...................................................................................18 GBTS Troubleshooting Cases ...................................................................................................22 Case1. Tracing GSM Interference Problem ...........................................................................22 Case2. PDCH faulty & TCH Carrying no traffic in BTS ...........................................................26 Case3.Low TCH availability when site shifted to batteries ..................................................28 Low TCH availability when site shifted to batteries.................................................................28 Case4.GSM extended Cell with 2 trx's congestion .............................................................30 GSM extended Cell with 2 trx's congestion ............................................................................30 Case5.The wrong IPPATH type to make PDTCH Fault ......................................................32 Case6.Difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated .........................................................34 Case7.Low CSSR..............................................................................................................35 Case8.BTS 3900 Antenna mode of S444 type configure is wrong result in VSWR alarm .............................................................................................................................................36 Case9.Tilt & Azimuth error cause TCH assignment successfully rate is low and Handover failure ...................................................................................................................38 Case10.GSM Cell Transmission Delay Abnormal in Abis over IP .......................................39 Case11.2G to 3G cell reselection unsuccessful..................................................................41 Case12.Technical Case Regarding HUAWEI GSM BTS ....................................................42 Case12.GSM Cell UL Quality abnormal .............................................................................43 Case14. GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell ...........................................................................................................45 GSM Product Training Technical Cases HUAWEI Confidential1 BSC6900 Troubleshooting Cases Case1. Cannot login weblmt in some office due to different IP proxy settings TitleCannot login weblmt in some office due to different IP proxy settings KeywordswebLMT, login, proxy Case codeBSC6900-001Case typeO&M tools Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6910 1.Phenomenon Description We have new BSC6910 deployed. In Office A of Customer we can login weblmt in IE or Modzilla. But in Office B our customer cannot login weblmt. 2.Alarm Information Null. 3.Cause Analysis 1. Ping to external virtual IP of BSC6910 10.251.169.153 both in office A and office B is OK. But we still cannot login in Office B; 2. Try other laptop and computer, update java also same; 3. According to below snapshot this could be a cache error in IE; GSM Product Training Technical Cases HUAWEI Confidential2 4. Clear Cache problem persist; 5. Use HTTP watcher and save the snapshot during login process. It is found that IE can only get 3333 bytes data from the RNC LMT Server. Thehttpresponseisnotcomplete,onlyget3333bytesdata,thatswhytheerror happened. 6.AlsofromtheHttpresponseheader,aproxyserverisworkingbetweenPCandthe RNC LMT server in office B;

HTTP/1.0 200 OK Date: Thu, 30 May 2013 08:33:47 GMT Server: Huawei VPP EWS Last-Modified: Fri, 03 May 2013 08:43:15 GMT Content-Type: application/x-javascript Cache-Control: max-age=2592000, public, no-check=2592000 Content-Length: 8036 Content-Encoding: gzip Age: 0 X-Cache: MISS from proxy2.local X-Cache-Lookup: MISS from proxy2.local:3128 Via: 1.0 proxy2.local (squid/3.1.15) Connection: close 7. In office A, it is found that we are using IP proxy set 10.1.89.231 in IE, meanwhile we are using IP proxy 10.2.154.202 in Office B. The login failed when we are using IP proxy 10.2.154.202 and it reject the HTTP request to RNC server, but when we use 10.1.89.231 we can login again in Office B. Customer decide to use IP 10.1.89.231 at all office. 4.Handling Process 1. Test ping at both office, if in specific office which has the problem, then there is no issue in RNC server; 2. Check using other laptop; 3. Try to clear cache in browser; 4. Check whether Java already updated; 5.UseHTTPwatchertools,thistoolhelptoanalyzethepacketexchangeduringl ogin process; 6. Check whether customer using different proxy ip setting in different office. GSM Product Training Technical Cases HUAWEI Confidential3 5.Suggestions and Summary Login access problem in some office is not critical problem, what we have to make sure is that connection to external link in that office is still there. If ping is OK and in other office we still can login, then there is no problem in network or RNC server. We must check other setting related with client, in this case different proxy setting in customer Office B was the root cause. Case2.A interface main and standby boards frequently switch in one BSC caused by other BSC in BM-TC separated when done A over IP Title A interface main and standby boards frequently switch in one BSC caused by other BSC in BM-TC separated when done A over IP KeywordsAoIP BM/TC separated frequently switch Case codeBSC6900-002Case type Configuration&Commissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description One BSC in BM/TC separated mode in one office, after A interface from TMD to IP mode, service mode also has been changed to be BM/TC combined. The TC subrack together with its data has been deleted. After modification, BSC2 works normally but a pair of main and standby GOUc boards in BSC8 frequently switch. Following illustration is before A interface modification. 2.Alarm Information MTP3 signal link fault alarms about A interface. GSM Product Training Technical Cases HUAWEI Confidential4 3.Cause Analysis TheBSCwhichBM/TCcombined,afterdeletedAinterfacedata,therelatedboards remained. Thatmeansthephysicalopticalchannelwasstillthrough.SoonMGW side,theGOUc boards can detect the signal from the other side. But the BSC which BM/TC separated, after GOUc boards removed, physical channel was through, but the MGW side cant receive the stable optical signal. But the MS2L boardsopen the protected group lead to main and standby MS2L boards frequentlyswitchandthemainandstandbyGOUcboardswhichontheotherside frequently switch. 4.Handling Process 1. Plug out the fiber connected to GOUc boards which not configured on BSC side. 2. Delete the optical interface protected group which connected to GOUc boards on MGW side. 5.Suggestions and Summary 1. Check the board logical function on BSC device panel before A over IP (BSC in BM/TC separated mode) , plug out the fiber which not actually used. 2. Delete related optical interface protected group in MGW side. Case3.Can register network but can't call due to GTC type set error TitleCan register network but can't call due to GTC type set error KeywordsGTC, ITC, DPUc Case codeBSC6900-003Case type Configuration &Commissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description One test bed office in country Y, using MBSC6900V900R013 (GU), the property of Subrack0 is UO and Subrack1 is GO. After debugging by local engineer, the mobile phone can register network but cant call setup. It shows network busy after dialing numbers few seconds. We found that after MSC send assignment command, BSC replied assignment failure GSM Product Training Technical Cases HUAWEI Confidential5 message and cause value shows: equipment failure. 2.Alarm Information None. 3.Cause Analysis 1. There are two DPUd for inner PCU for data process and two DPUc for inner TC; 2. A interface is in IP mode and Abis interface is in TDM mode; 3. Can register network but cant call setup. So we focus on user panel rather than signaling panel; 4.We entered the Device Maintenance by WebLMT and selected Display Logic Function. We found as follows: DPUd boards work in GPCU mode in slot8 and slot9. DPUc boards work in GTC mode in slot10 and slot11. 4.Handling Process DPUc board works in three mode: GTC: TC resources that support normal voice coding/decoding and packet conversion.The TC resource support packet conversion In BM/TC separated mode, when abis interface transmission mode is abis over IP or HDLC.It's different from ITC. UTC: TC resources that support only the optimized handover on the Iur-g interface. ITC: TC resources that support only packet conversion.It is only used in A over IP. After changing it to ITC for DPUc in slot10, we solved this issue. 5.Suggestions and Summary DPUcworksinthesethreemodesbutallshowsGTCinlogicaltype.Wesuggest developing one function to identify them. Case4.Problem adding SPU boards in GU mode TitleProblem adding SPU boards in GU mode KeywordsSubrack, GU, UO, GO MOD Case codeBSC6900-004Case typeConfiguration&Commissioning Case is from Huawei Support site Update Time Product Family GSM BSSProductBSC6900 1.Phenomenon Description The BSC unable to add SPU boards at slot 4 GSM Product Training Technical Cases HUAWEI Confidential6 BSC Version: V900R013C00 2.Alarm Information None. 3.Cause Analysis Actually we were told to configure MBSC in GU mode but the boards were delivered as 2 subracks for RNC and 1 subrack for BSC. By default TNU boards were apearing on the slot 4 whereas we need to add SPU board on the same slot for RNC services Following steps were followed on site: 1. Reset the subrack 2. Checked the subrack mode 3. Tried to remove TNU boards 4.Handling Process When wefollowedthecommissioning procedureonebyonethenwefoundthatatone step we need to define MBSC mode which we selected as GU. This is correct as MBSC which shares the same OMU need to be defined the same way, but when we define it as GU mode then MBSC by default takes subrack-0 as GU mode which means it configures TNU board automatically for 2G services. SoforMBSC'sinwhichco-transmissionisnotbeingusedwehavetoconfigureeach subrack as per its desired mode, i.e if the subrack is for GSM we need to select GO mode and if the subrack is for WCDMA services we need to select UO mode. So we followed following steps: 1. while commissioning we put the mode as GU because we need to share same alarm and trace mangement platform 2.Aftercommissioning weneedtochangethemodeofeachsubrackfromLMTasper desired design, even for subrack-0 also by MOD SUBRACK command. 3. when we changed the subrack-0 mode to UO then whole MBSC mode was GU but of subrack -0 was UO means now we can add SPU boards on slot-4 5.Suggestions and Summary Whenever we are using MBSC in UO mode as a whole then we always need to change GSM Product Training Technical Cases HUAWEI Confidential7 the mode of subrack-0 as well as. Per desired design means as UO or GO , but by default it will be GU. Case5.SPUb board unavailable in new subrack TitleSPUb board unavailable in new subrack KeywordsSPU, SPUb, MPU board unavailable, backplane Case codeBSC6900-005Case typeEngineering&Installation Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description Customer in country F added new UMTS subrack in MBSC. The SPUb in subrack 4 slot 0 (MPU) reports Board Unavailable after the new subrack was powered on. Rests of the boards are in status Normal. 2.Alarm Information Board Unavailable 3.Cause Analysis When only one board fails, possible causes are as follow: Board failure OMU failure (does not respond to BOOTP messages) Configuration issues Backplane slot faulty 4.Handling Process 1. Checking First the onsite engineer swapped board in slot 0 with the standby SPUb in slot 2 and restarted the subrack (no NodeBs defined in the new subrack yet); after restart, SPUb slot 2 started up normally and slot 0 still unavailable. This was an abnormal behavior, so we performed the test again, with another SPU card but with the same result. A board issue was excluded so the subrack backplane could cause the problem. 2. Troubleshooting No MML command can be performed on the SPUb in slot 0; If we inhibit the card, the uninhibit command will timeout and the board will remain in blocked mode. GSM Product Training Technical Cases HUAWEI Confidential8 After checking the OMU log Software module we can check if there were any BOOTP requested from subrack 4 slot 0 (the first step of starting the board is to send a BOOTP request to OMU and download software). All boars from subrack 4 are sending BOOTP request but no request from slot 0; First the SCU starts in slot 6 then SPU slot 1, after that the rest of the boards from subrack 4. If we check the backplane ports on subrack 4 (DSP BACKPLANEPORT) we can see both ports are down (Link state = DOWN, Administrative state = Enable). We sent field service on site to remove the SPUb from slot 0 and 2, and make photos of the backplane; we saw that in slot 0, one pin is binded. We collected all the logs and together with photos we requested HQ expert to confirm for what the pin is used and is we should attempts to fix it. Hardware R&D confirmed the pin is used as 2ms connector. If the pin is faulty, the board will fail to get the number info about subrack and slot. Then the BOOTP process will fail. 5.Suggestions and Summary The broken pin in the backplane causes board unavailable. The solution is to replace the subrack. Case6.Problem in integrating TC subrack with BM TitleProblem in integrating TC subrack with BM Keywords Case codeBSC6900-006Case typeEngineering&Installation Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description While intergrating 2nd TC subrack with BM, software was not getting uploaded and cards were not getting activated. MBSC version: V900R013C00SPH558 VER. 2.Alarm Information None. GSM Product Training Technical Cases HUAWEI Confidential9 3.Cause Analysis We checked following information to handle this problem. 1. Whether TC subracks are in Effective mode. 2. Whether TC subracks are power on. 3. Whether physical connection between TC subracks and BM is proper. 4. Whether clock cables and TNU cables are properly conected. 5. Whether mapping between SCU board of TC subrack and that of BM subrack is Okay. these were the basic steps and we started analysing all these things becuase all the cards and whole subrack cannot be faulty. 4.Handling Process We started handling the problem as per our analysis, so we took following steps : 1. We checked TC subrack mode and found that it was in active mode. 2. We checked and found TC subracks were power on. 3. We checked physical connections between BM and TC subracks and found them that they were mapped properly. 4. Other cables like clock cable and TNU cable were also properly connected. 5. We run the command DSP PANELPORT to check the mapping of subracks and found the following result. In the above picture we can see the mapping between 3rd subrack (i.e. TC subrack) is with the 2nd subrack (i.e BM subrack) and the 0 subrack (i.e BM subrack), while 2nd subrack is showing mapping with only 0 subrack and which is correct, Noramally the mapping of all other BM subrack should only be with 0 BM subrack and 1st TC subrack should be mapped with 0 BM subrack and then all other TC subracks should be connected to the main and first TC subrack. With this analysis we concluded one point that there is definetly some problem in commissioning related activity as phisical connection were proper. Then we started cheking the same for other BSC's and was correct in that and we found that, in all otherBSC's the mapping of 3rd subrack (i.e 1st TC subrack) is with 0 BM GSM Product Training Technical Cases HUAWEI Confidential10 subrack and other TC subrack means subrack 4 and subrack 5, as shown in the figure below : So we came to know that somehow 2nd TC subrack is not configured as subrack 4 instead it is configured as subrack 2. Then we checked and found software configuration was okay, so we cheked the DIP switch settings and found that they were like subrack 2 of BM subrack. We then power off the subrack and made the DIP switch settings as subrack-4 and again powered it on. Finally the communication between BM and TC subrack became okay and software loading also started. 5.Suggestions and Summary Whenever we are integrating TC with BM subrack we should always remember that the numbering of subracks and thier DIP switch settings will be counted as all the subracks of BM first and then all the subracks of TC, they should not be treated as separate even in case of separate cabinet. Case7.OMU IP Address Configuration Error due to BSC6900 upgrading from V9R13 to V9R15 Title OMU IP Address Configuration Error due to BSC6900 upgrading from V9R13 to V9R15 KeywordsAter interface protection BSC6900 Case codeBSC6900-007Case typesoftware upgrading Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description 1. NCRVLNZLABSC1 BSC6900 upgrade from V9R13 to V9R15, before upgrading there are no alarm, but after upgrading there is OMU IP Address Configuration Error, alarm ID--20721.there are 2 pcs OMUc board on slot 24 and slot 25 on this BSC. 2. Run the MML command DSP OMU: GSM Product Training Technical Cases HUAWEI Confidential11 %%DSP OMU:;%% RETCODE = 0Execution succeeded. OMU server state ---------------- Subrack No.=0 Slot No.=24 Computer name=OMU_NCRVLNZLABSC1_S24 Internal network fixed IP=80.168.3.50 External network fixed IP=10.157.63.51 Backup network IP=192.168.9.50 Operational state=Active normal Version=V900R013ENGC00SPH532 Subrack No.=0 Slot No.=25 Computer name=OMU_NCRVLNZLABSC1_S25 Internal network fixed IP=80.168.3.60 External network fixed IP=10.157.63.50 Backup network IP=192.168.9.60 Operational state=Standby normal Version=V900R013ENGC00SPH532 (Number of results = 2) Other state ----------- Internal network virtual IP=80.168.3.40 Internal network virtual IP mask=255.0.0.0 External network virtual IP=10.157.63.49 External network virtual IP mask=255.255.255.240 Internal network virtual IP state=Normal External network virtual IP state=Normal Data-sync state=Data synchronization is successful Internal network link state=Normal External network link state=Normal Backup network link state=Normal (Number of results = 1)scenatio. 2.Alarm Information Alarm ID: 20721 OMU IP Address Configuration Error GSM Product Training Technical Cases HUAWEI Confidential12 3.Cause Analysis Use putty to login in OMU , check the IP and findthe MASK of10.157.63.50is 255.255.255.192, but the MASK of10.157.63.49 and 10.157.63.51 are 255.255.255.240. Due to diffierent MASK launch this alarm. During commision this BSC, they made error configuration. 4.Handling Process 1. Look for one line cable which can ping 10.157.63.50 in the NOC room; 2. Use putty to login in OMUc board, choose the IP as 10.157.63.50; 3. Command "ifconfig", and check the mask of bond1 is 255.255.255.192; 4. Command "/etc/rc.d/omud status" , check the running status of OMU, if running, command "/etc/rc.d/omud stop", stop OMUd firstly; 5. Command " cd /mbsc/bam/version_b/bin/bam" , handover to file omutool; 6. Command "./omutool extercard 10.157.63.50 255.255.255.240", correct the mask; 7. Command "/etc/rc.d/omud start" , start OMU . 5.Suggestions and Summary 1. Before upgrading we need check the mask of OMU IP, make sure they are the same; 2. Inform the customer in advance that maybe there are some new alarms due to upgrading, if the alarm doesn't affect service, tell them do not worry; 3. Check the root cause of alarm after upgrading ASAP, and solve the issue especially the major alarm. Case8.Direct tunneling between MBSC and GGSN is not working TitleDirect tunneling between MBSC and GGSN is not working Keywordsdirect tunneling OSPF routing GGSN MBSC Case codeBSC6900-008Case typeConfiguration &Commissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description We activated direct tunneling between MBSC and GGSN by using following command. //ADD IPRT GSM Product Training Technical Cases HUAWEI Confidential13 ADD IPRT: SRN=4, SN=26, DSTIP="81.192.60.168", DSTMASK="255.255.255.248", NEXTHOP="10.231.70.67", PRIORITY=HIGH, REMARK="IPRT2_TAF_MBSC CASA GARE2 to RC_GGSN2"; But the direct tunneling was not working properly. 2.Alarm Information By doing ping from GGSN to MBSC, ping was not OK as following: TRC IPADDR:SRN=4,SN=26,DESTIP="81.192.60.168",NEXTHOP="10.231.70.67"; MBSC_Hay_Nahda 1 10.231.70.68 3 ms3 ms1 ms 2 10.231.71.110 7 ms7 ms7 ms 3 192.168.180.65 3 ms19 ms9 ms 4 192.168.180.66 3 ms7 ms5 ms 5*** 6*** 7*** 8*** 9*** 10*** 11*** 12*** 13*** 14*** 15*** 16*** 17 reports in total (Number of results = 1) 3.Cause Analysis By checking the routing table of GGSN, the GGSN receive the wrong IP from OSPF side,Its not the user plan of MBSC Means that problem was a wrong configuration on OSPF side. OSPF should configure the routing table using BSC user plan(but the configuration was wrong) 10.231.30.36/32 O_ASE1501D192.168.187.46Eth-Trunk6.116 O_ASE1501D192.168.187.38Eth-Trunk0.114 O_ASE1501D192.168.187.174 Eth-Trunk7.216 O_ASE1501D192.168.187.166 Eth-Trunk1.214 10.231.70.36/32 O_ASE1501D192.168.187.46Eth-Trunk6.116 O_ASE1501D192.168.187.38Eth-Trunk0.114 O_ASE1501D192.168.187.174 Eth-Trunk7.216 GSM Product Training Technical Cases HUAWEI Confidential14 O_ASE1501D192.168.187.166 Eth-Trunk1.214 4.Handling Process OSPF engineer corrected the configuration by correcting the routing tables and adding user plan IP of BSC and problem was solved. 5.Suggestions and Summary While doing OSPF routing table configuration, it should be done using the user plane IP of BSC. Case9.Can't active cell due to Configuration & License inconsistent TitleCan't active cell due to Configuration & License inconsistent Keywordslicense inconsistent Case codeBSC6900-009Case typeConfiguration&Commissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description When implement the command ACT GCELL by LMT, it shows faulty, and the error code is: the system is in system-level configuration restricted mode. 2.Alarm Information None. 3.Cause Analysis For this error code, it means the cell configuration & license inconsistent. GSM Product Training Technical Cases HUAWEI Confidential15 4.Handling Process 1, Implement the command CHK DATA2LIC to check the license. The result as below: License File Attributes ----------------------- LicenseSerialNo=LIC2012122602DC00 CreatedTime=2012-12-26 17:04:12 Product=BSC6900 Version=V900R014 Authorization Type=COMM ESN=B218E2582B9106184E889BD647A8A1842AACD9FF (Number of results = 1) Feature information ------------------- Feature=LGMIBA Authorization Type=COMM Running Deadline=PERMANENT Number of Trial Days=60 Feature=LGMIBA2 Authorization Type=COMM Running Deadline=PERMANENT Number of Trial Days=60 (Number of results = 2) License Check ------------- ESN=Check consistent Version=Check consistent Work Mode=Check consistent Configuration Data=Check inconsistent (Number of results = 1) Configuration Data Check Result ------------------------------- Result=Configuration data exceeding license capacity info: =Cell [0,0], "SD Quick Ho" or "SI 6 Filling Random Bits After Cipher" is set to Yes, which is inconsistent with the setting "A5/1 Encryption Flow Optimization (per TRX)" in the license (or the default setting without the license). ="Info Exchange Content" of the neighboring RNC index (0) is set to "NACC Info", which is inconsistent with the setting of the license GSM Product Training Technical Cases HUAWEI Confidential16 (or the default setting without the license). =The total number of configured TRUs that support WB_AMR is [2], which exceeds the value [0] allowed by the license (or the default value without the license). =The number of Radio resource reserved handover between GSM and TD-SCDMA based on Iur-g (per TRX) is [2], which exceeds the value [0] allowed by the license (or the default value without the license). (Number of results = 1) The part which mark in red, Configuration Data Check Result, it shows the configuration data exceeding license capacity info. 2, Change the configuration of cell to obey the license, then issue solved. 5.Suggestions and Summary For this type of issue, we have two ways to deal it: 1, The resource or function is not necessary in the configruation, modify the configuration to obey the license. 2, The resource or function is necessary in the configruation, apply the new license. Case10.Low downlink TBF establishment successful rate due to paging congestion Title Low downlink TBF establishment successful rate due to paging congestion Keywordsdowlink TBF establishment successful rate, paging channel congestion Case codeBSC6900-010Case typePerformance KPI Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description The downlink TBF establishment successful rate degraded unstably everyday. BSC software version: V900R013ENGC01SPH213 GSM Product Training Technical Cases HUAWEI Confidential17 2.Alarm Information None 3.Cause Analysis 1. Some abnormal terminals. 2. The Packet Downlink Assignment message is with some error, which can not be accepted by MS. 3. LAPD congestion. 4. Paging channel congestion. 4.Handling Process 1. From the GPSR logs, we can see that not only one TLLI or IMSI fails, so there is not abnormal terminal. 2. To compare two pieces of the Packet Downlink Assignment messages, one is OK and the other one is not OK. There is no difference betwen the two messages. 3. There is no congestion on LAPD by checking the counter class "PAGE.DiscForOverload.LAPDLINK". 4. There is congestion and message discarding in PCH channel when the downlink immediate assignment successful rate and the downlink TBF establishment successful rate is low. GSM Product Training Technical Cases HUAWEI Confidential18 Because the PS downlink immediate assignment message is sent through the PCH channel and the PS message discarding priority is higher than the CS one, if there is congestion in PCH channel, the PS downlink immediate assignment message will be discarded firstly, which makes the downlink TBF establishment successful rate is low. Checking the configuration, we find that there is a very large LAC, which has almost 600 cells. It will makes a lot of paging message in every cell under this LAC, and it will make the paging channel congestion. After dividing the LAC, the number of paging message decreases, and the problem is solved. 5.Suggestions and Summary PS and CS use the same channel to send the downlink immediate assignment message. If the paging channel is congested, the PS downlink immediate assignment message will be discarded firstly, which will affect the downlink TBF establishement successful rate. If the paging channel is congested, there are two methods to solve the problem: 1. To divide the LAC to two or more smaller one. 2. To configure BCH to add paging channel. Case11.Rebalance XPU CPU Load TitleRebalance XPU CPU Load KeywordsXPUa, XPUb, CPU Load Case codeBSC6900-011Case typeConfiguration&Commissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBSC6900 1.Phenomenon Description CPU processthesignalingoftheBTS.IftheloadoftheCPU isoverload,thensome signaling will be not be proceeded by CPU and the KPI will be degraded. SowehavetomovesomesitesthatconnectedtothehighCPULoadtothelowCPU Load. Amount of sites that have to move can be calculated use the BHCA value of the sites. GSM Product Training Technical Cases HUAWEI Confidential19 On the picture below, some CPU Load already reach 70%, to keep the network is stable we have to maintain the CPU load under 70%. 2.Alarm Information: ALM-20256 CPU Overload. 3.Cause Analysis: Inside XPU board there is CPU subsystem (XPUa have 4 CPU subsystem, XPUb have 8 subsystem). If the BTS is unblocked, the site will be automatically connected to the specific CPU. Thesystem willdistributethesiteontheCPUsubsystemandthedistributionsystemis based on the TRX Quantity. The TRX Quantity of each CPU is almost same. For example: 1 XPUa process 100 TRX, then the site will be automatically distribute: CPU 0: 26 TRX CPU 1: 23 TRX CPU 2: 24 TRX CPU 3: 27 TRX In fact, every site have different. It make the BHCA of every site is different even the TRX Qty of the site if the same. SoeveryCPUcanhavebigdifferentBHCAvaluethatmadetheCPUloadofevery subsystem also different. ThenweneedtorebalancemanuallytomaketheCPUloadofeverysubsystemis balance. 4.Handling Process: Take the BHCA Data for all the site on the BSC. BHCA =Num of Service Category* BHCA Weight BHCA of a site =BHCA of the cell Take the data for BHCA and CPU Load on Busy Hour on the same time. Service Category BHCA Weight Counter Description GSM Product Training Technical Cases HUAWEI Confidential20 LocationUpdating(Times)0.3A3030F:CallSetupIndications(LocationUpdating) (SDCCH) IMSI detach(Times) 0.3 A3030G:Call Setup Indications (IMSI Detach) (SDCCH) CS calls to CS call 1 CA313:Successful Assignments MR Reports to CS call 0.008 S3013:MRs of Serving Cells CSSMStoCScall0.5A3030B:CallSetupIndications(MOCSMS) (SDCCH)+A3340B:Downlink Point-to-Point Short Messages on SDCCH Intra-HOstoCScall0.3CH311:NumberofOutgoingInternalInter-CellHandover Commands+CH303:Successful Internal Intra-Cell Handovers Inter-HOs to CS call 0.4 CH343:Successful Incoming External Inter-Cell Handovers CSPagingtoCScall0.5A0300:NumberofMSC-initiatedCSpaging requests+A0301:Number of SGSN-initiated CS paging requests UplinkTBFEst&ReltoCScall0.049A9002:NumberofSuccessfulUplinkGPRSTBF Establishments+A9202:Number of Successful Uplink EGPRS TBF Establishments Downlink TBD Est & Rel to CS call 0.049 A9102:Number of Successful Downlink GPRS TBFEstablishments+A9302:NumberofSuccessfulDownlinkEGPRSTBF Establishments PS Paging/Second to CS call 0.283 A031:Number of SGSN-Initiated PS Paging Requests The CPU Load for each CPU: HR9780:Maximum CPU Usage of the XPU EspeciallyfortheCPUthatprocessingforMTP3andRGCP,suggestednotuseasa destination for CPU rebalance. To check the site connection to the CPU, we can use command: LST BTS, then we get the data: GSM Product Training Technical Cases HUAWEI Confidential21 Thenwecompilethedatalikebelowtable,weanalyzetheBHCAvalueandtheCPU Load. We can make correlation for the value of BHCA and CPU Load. For example if the BHCA is 90000 the CPU Load will be 70%. Thenwe movesitethatconnectedtotheCPUthathaveLoadmorethan70% untilthe CPU BHCA is less than 90000. For the destination CPU, after we move the site we calculate that on the destination CPU the BHCA not more than 90000. Then make the script. The script execution is DEACTIVATE SCRIPT --> REBALANCING SCRIPT --> ACTIVATE SCRIPT 5.Suggestions and Summary: After Rebalancing we can get the highest CPU Load is decrease. We can keep maintain this activity to the BSC if find CPU have high utilization. Note: 1. If we have high CPU load on the CPU as RGCP then we can add more XPU configure as RGCP 2.If wehavehigh CPU loadontheCPUthatprocessSS7,wecanadd moreHSLand assign the ther CPU to process the new HSL. GSM Product Training Technical Cases HUAWEI Confidential22 GBTS Troubleshooting Cases Case1. Tracing GSM Interference Problem TitleTracing GSM Interference Problem KeywordsTracing, GSM Interference, Interference Band, bursting Case code BTS3900-001 Case type Configuration&Commissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description Badvoicequality.Userexperiencedoftencanthearvoiceclearlyundersite Bantarbolang GSM under BSC Jatibarang (Telkomsel Central Java). 2.Alarm Information None 3.Cause Analysis BecauseoftheresnoalarminformationrelatedtoBTShardwareandE1Abis transmission. Further check is investigate interference problem. 1. Check the measurement of Interference Band Measurement per TRX from M2000. Found that cell Bantarbolang-2 has interference band 3 and band 4. GSM Product Training Technical Cases HUAWEI Confidential23 2.Perform uplink frequency scanning to the suspect cell, if found average signal several frequencies are greater than -95 dBm, it indicates uplink interference exist. Interference BandDefault Power Level Range Interference band 1110 dBm to 105 dBm Interference band 2105 dBm to 98 dBm Interference band 398 dBm to 92 dBm Interference band 492 dBm to 87 dBm Interference band 587 dBm to 47 dBm GSM Product Training Technical Cases HUAWEI Confidential24 Uplinkfrequencyscanresultshowonlyseveralfrequencyhaslevelinterference GSM Product Training Technical Cases HUAWEI Confidential25 band3andband4,wecaneliminatedtheprobabilityinterferenceiscausedby co-channel interference. 3.Next step is checking interference is caused by CDMA network using LMT, but for getting the valid and precision test result we have to use Spectrum Analyzer. Perform CDMA interference test for all non BCCH TRX, result CDMA interference is not exist. 4.Further step is check intermodulation interference which caused by bad RF board, loose feeder connector or bad antenna. PerformburstidleTRXatlowtraffic,ifinterferencebandchangeincreasefrom interference band 1 or 2 to interference 3 , 4 or 5 we can infer that intermodulation has exist. Perform real time monitoring channel interference band. Step 1 : Capture BEFORE bursting Step 2 : do Test Idle Slot / bursting Step 3 : Capture AFTER bursting From these result, we indicate that interference is caused by intermodulation. GSM Product Training Technical Cases HUAWEI Confidential26 5.Performtheothertesttomakesurethatinterferenceiscausedby intermodulation. 4.Handling Process From analysis above we infer that interference is caused by intermodulation, and perform the following steps : 1.Check connector of jumper feeder installation and antenna port. 2.Check and replace RF board if any fault is found. 3.Check and replace existing antenna if any fault if found. 4.Check filter installation or replace if the existing is using bad filter. 5.Suggestions and Summary Forgettingvalidandprecisionmeasurementtestofinterference,highlyrecommendto use Spectrum Analyzer. Case2. PDCH faulty & TCH Carrying no traffic in BTS TitlePDCH faulty & TCH Carrying no traffic in BTS KeywordsPDCH faulty,TCH Carrying no traffic,QOS Case codeBTS3900-002Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description ThiscasestudyhelptofamiliariseandunderstandwhenallsettingsandparametersasperDSDand cellplanningareOkbutnotrafficonTCHandPDCHshowingfaulty. BTS PDCH channels are showing faulty&noTCHactivites in all three cells and they are not able to access anyservices resultinghighrevenuelossforcustomer. BSCVersion:BSC6900(V900R013ENGC00SPH529) BTSversion:BTS3900A(BTS3000V100R013C00SP31) GSM Product Training Technical Cases HUAWEI Confidential27 2.Alarm Information InalarmwindowonlyRLFinwarningimpactedQOSatsite. 3.Cause Analysis Resulting KPI degraded randomly for this site and impacted neighbours cell HO and QOS. Only SD assignment successfully as showing in Figure above. WecheckallCellstatusenabledandsetupandalsoallTRXoperationalstatein working condition. Apart from this Ping test from BSC to BTS ok. GSM Product Training Technical Cases HUAWEI Confidential28 4.Handling Process Step-1 Check all parameters RF and Cell as per Cell Planning and Data Base. Step-2 Check BTS software version and current release. Step-3 Check BSC licence for PDTCH and TCH and if any dynamic assignment or not at site. Step-4 Check IP path for particular site. In this case previously IP path added and all conditions call and data are working but randomly due to faulty timeslots all services hampered and no call voice and data. WeseeIPpathnotshowingatthissiteandnodatafoundregardingassignmentofIPtothis BTS/ANI and QoS setting. Nowfrom IP plancheck the BW for this site and re add theIPpath again.Now check again call status and data every thing will be OK. AsIconcludeinthiscasestudy ifsitestatusnormalandnohardwarefaultatsite exceptvoice and data traffic, check IP path settings and bandwidth configurations as per plan. 5.Suggestions and Summary Null. Case3.Low TCH availability when site shifted to batteries TitleLow TCH availability when site shifted to batteries KeywordsLow TCH, batteries,BCCHCase codeBTS3900-003Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS 3012AE GSM Product Training Technical Cases HUAWEI Confidential29 1.Phenomenon Description when the site is shifted to batteries all the channels are converted to Blocked stat and we have to manually unblock them or we have to wait for commercial power to be restored. Noserviceeffectingalarmreportedduringthistime.BTSType3012AEandSoftware Version is V100R008C11SPC026. 2.Alarm Information: Null 3.Cause Analysis: DC Power problem On-site configuration and LMT configuration mismatch. 4. Handling Process: In the initial analysis it was found that TCH availability is low on all the sectors of the site. Aftercheckingthestatsandalarmsitwasconfirmedthatwheneversiteisshiftedto batteries TCH availability goes down without any alarm. AfterdetailanalysisitwasfoundoutthatthereisoneoptionBTS POWEROFFLOCKBCCH in BTS attributes which was set to yes. Description is below. BTS POWEROFFLOCKBCCH Explanation: This parameter specifies that when the site is powered off, the BCCH TRX is locked. When the BSC receives the call drop report from the BTS and this function is disabled, onlytheTRXs(configuredasShutDownEnable)ratherthanmainBCCHTRXsare disabled; if this function is set toyes, all TRXsunder the site including the main BCCH TRXs are disabled so as to fulfill energy efficiency. 5. Suggestions and Summary: TCH fluctuation on site resolved after changing the parameter Locking BCCH Trx When Site Power Off Allowed to NO in BTS Attributes. GSM Product Training Technical Cases HUAWEI Confidential30 Case4.GSM extended Cell with 2 trx's congestion TitleGSM extended Cell with 2 trx's congestion KeywordsGSM extended Cell, congestionCase codeBTS3900-004Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS 3900 1.Phenomenon Description Operator x from conuntryy complained that on a gsm extended cell with 2 TRX's,there were enough timeslot for traffic butcellwassufferingfromcongestion.Itseemedthatsecond TRXisnotinvolvedwith cells traffic. 2.Alarm Information: Null 3. Cause Analysis: Null 4. Handling Process: Checking the bsc CFG MML for this cell it looked like it was something wrong with the configuration for the second TRX. It can bee seen from the fig 1 that the second TRX was not configured as an extended cell TRX. The MML configuration for those TRX's was: add gtrx:trxid=466, freq=21, trxno=0, cellid=307, idtype=byid, ismainbcch=yes; add trxbind2phybrd:trxid=466, trxtp=mrru, trxpn=0, cn=0, srn=60, sn=0, antpassno=a, rxuidtype=srnsn; set gtrxchan:trxid=466, chno=2, chtype=sdcch8, tspriority=0; set gtrxchan:trxid=466, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; GSM Product Training Technical Cases HUAWEI Confidential31 set gtrxchan:trxid=466, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch; add gtrx:trxid=608, freq=60, trxno=3, cellid=307, idtype=byid, ismainbcch=no; add trxbind2phybrd:trxid=608, trxtp=mrru, trxpn=1, cn=0, srn=60, sn=0, antpassno=a, rxuidtype=srnsn; set gtrxchan:trxid=608, chno=0, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=1, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=2, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=3, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=5, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=7, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxiuo:trxid=608, iuo=overlaid; to set gtrxiuo:trxid=608, iuo=underlaid. And the issue was that on the second TRX the time slot configuration has to be changed from: set gtrxchan:trxid=608, chno=0, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=1, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=2, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=3, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=5, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=7, chtype=tchfr, tspriority=0, gprschpri=egprsnorch. To: set gtrxchan:trxid=608, chno=0, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=2, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch. Also a change has been perfomed to set the cell to extended configuration. add gcell: cellid=307, cellname="niekkh1", type=gsm900, mcc="244", mnc="91", lac=6291, ci=11755, exttp=dualts_extcell, iuotp=concentric_cell, eniuo=on, flexmaio=off; Both TRX's were set to underlaind configuration, and here appeared a problem. lst gtrxiuo: idtype=byname, cellname="niekkh1"; %%/*3599099*/lst gtrxiuo: idtype=byname, cellname="niekkh1";%% retcode = 0 execution succeeded. list concentric attributes of trx --------------------------------- trx id concentric attribute 466 underlaid subcell 608 underlaid subcell (number of results = 2) When trying to set Concentric Circles HO Allowed to "yes", following occurs: set gcellhobasic: idtype=byname, cellname="niekkh1", conhoen=yes; GSM Product Training Technical Cases HUAWEI Confidential32 %%/*445778*/set gcellhobasic: idtype=byname, cellname="niekkh1", conhoen=yes;%% retcode = 235233480 cell [linseh4] is not a concentric cell or does not have trxs in either the underlaid subcell or the overlaid subcell. concentric circles ho allowed must be set to NO. To solve this one of the TRX's was set back to overlaid. lst gtrxiuo: idtype=byname, cellname="niekkh1"; list concentric attributes of trx --------------------------------- trx id concentric attribute 466 underlaid subcell 608 overlaid subcell (number of results = 2) Fig.2 is the final configuration which appears in weblmt. 5. Suggestions and Summary: Null Case5.The wrong IPPATH type to make PDTCH Fault TitleThe wrong IPPATH type to make PDTCH Fault KeywordsPDTCH fault, IPPATH TYPE, AF43,IP Case codeBTS3900-005Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3000 6.Phenomenon Description M operator usesBSC6900 (V900R011C00SPC732) with GBSS9.0 GOtype. The MBTS version is BTS3000V100R009C00SP75. When we tested voice service , it worked normally. WhenwetestedGPRSservice,itwasfailed.ButtherewerenoanyalarmsinMonitor Channel status. Then we found PDTCH fault, and the reason was ABIS failed GSM Product Training Technical Cases HUAWEI Confidential33 7.Alarm Information: Null 8.Cause Analysis: For GPRS service failed issue, the possible reasons in the list: 1. The transmission quality is not good, so the GPRS does not work. 2. We use inner PCU. Maybe the GDPUd board and DSP system have problem. 3. Gb interface has problem. 4. PDTCH and cell configuration has problem. 5. GRFU hardware has problem. 6. Software has bug. 9.Handling Process: 1. Because voice traffic worked normally and the transmission worked for old site had not this problem. So it was not transmission quality problem. 2. We tried to change the GRFU board, it is not useful. The fault still appeared in PDTCH channel, so it was not hardware problem. 3. Check the DSP which the cell used, and reset the DSP (Digital Signal Processing), It was not useful. 4. Check the GB interface, the PTPBVC and NSVL worked normally. 5. Compared configuration with old BTS, old BTS used Abis over E1, the new BTS used Abis over IP, andthefaulttypewasshowedas:Abis fault,So wethoughtAbisinterfaceconfiguration had problem . We checked the command one by one. IPPATH Seemed had problem, because we have so many IPPATH types can be chosen, but in our configuration, we just used EF and AF43. After we GSM Product Training Technical Cases HUAWEI Confidential34 checkedAbis&Iub ConfigurationRecommendation_IP, We found the service type of Abis interface like Picture2,and For PS Low Pri need AF43. and we do not confige the type of AF43. After we configured one more IPPATH, The type of AF33, GPRS worked normally. 10. Suggestions and Summary: Compared with Abis over TDM, We should understand very well about ALL IP network. Case6.Difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated Title Difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated KeywordsTRXs cannot be activated due to ARFCNs out of default range Case codeBTS3900-006Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description BSC6900 OMU SW version: BSC6900V900R011C00SPH734. BTS3900 SW version: BTS3000V100R009C00SP79. Abis over TDM (GOIUB). Phenomenon:whenassigningcellTRXs(boundtosendpassofMRFUboard):ifthe difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated. 2.Alarm Information: Null.pop up message:when trying to activate the site a pop up message will appear stating that the assigned frequencies (ARFCNs) related tothe corresponding RFU exceeds the default send BW range which is 15 MHz. GSM Product Training Technical Cases HUAWEI Confidential35 3.Cause Analysis: Fromthepopupmessage,itisnoticedthatTheupperthresholdofthetotalsend bandwidth of all the TRXs bound to send pass of RFU board is out of default range. realtedparameteristhe:FORWARDBANDWIDTHparameter(BRDTXBW)intheADD BTSRXUBRD command. this parameter default value is 150 which means that the total send bandwidth should not exceed 15MHz (bound to send pass of MRFU board). 4.Handling Process: a.wehaveto modifytheabove mentionedparameterFORWARDBANDWIDTHbut we have to ensure that the HardWare support the modified send BW. b. ensure the delivered MRFU is V2 (support 20MHz) not V1. c. apply the command to be BRDTXBW = 200:eg: ADDBTSRXUBRD:IDTYPE=BYID,BTSID=54,BT=GRFU,CN=0,SRN=4,SN=3, RXUNAME="RXU_3", RXUCHAINNO=3, RXUPOS=1, ISCONFIGTHD=YES,BRDTXBW=200,BRDRXBW=600,PWRMODE=CLASS2, TrxNum = 6. 5.Suggestions and Summary: a. confirm the range of frequencies used in the project for 900M & 1800M b. confirm the type of RFU board delivered on site. c.forDCS1800:firstlyensuretheGRFU1800type:L60(from1805Mto1865M)or H60(from 1820 to 1880) to be matched with the planned frequencies. d. modify the FORWARD BANDWIDTH parameter (as above) to be 20MHz if needed. Case7.Low CSSR TitleLow CSSR Keywordslow CSSR,KPI, Flex abis mode Case codeBTS3900-007Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description when the traffic increases (specially in the busy hours), abnormally the CSSR became low in some cases less than 10%. GSM Product Training Technical Cases HUAWEI Confidential36 2.Alarm Information: there is no alarms on the boards just the KPI has been affected (Low CSSR). 3.Cause Analysis: 1- check the current and history alarms of BTS . 2- check the KPI for finding where is the problem. 3- check the relevant configuration according the KPI. 4- change the configuration . 4.Handling Process: 1- we checked the hardware for any alarms in the boards, there was no alarm. 2-wecheckedtheconfigurationforanymisconfigurationjustfindmorethan15TRX configured on one E1 and have been used Flex abis mode. 3- then, we checked the KPI and find, when the traffic increases and TCH assignments increases we have low CSSR and other hours CSSR is near to normal. 4- we resulted in the resources aren't enough because of many TRX on one E1. 5- we decreased the number of Idle TS and change the multiplexing mode to 4:1 6- we monitored the KPI recovered. 5.Suggestions and Summary: in the places that has more traffic fluctuations,we shouldn't use the Flex abis mode because in high traffic we won't have enough resources.it is better to expand. Case8.BTS 3900 Antenna mode of S444 type configure is wrong result in VSWR alarm Title BTS3900 Antenna mode of S444 type configure is wrong result in VSWR alarm KeywordsVSWR, DRFU, Antenna Case codeBTS3900-008Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 GSM Product Training Technical Cases HUAWEI Confidential37 1.Phenomenon Description G country BSS project need to complete old BTS swap, old tower BTS installation and on air in XX important area. Old tower site TRX configure is S222 for the area. Swap site all TRX expansion to S444. using new BTS3900 of huawei, oldtowersiteneedtoinstallantennasystem,swapsitesrequirementswapantenna system. We test VSWR for each site each cable in during swap. Test result is normal, no appear VSWR alarm. But about 2 hour later, S444 site each cell is appear VSWR alarm. 2.Alarm Information: VSWR alarm of DRFU. 3.Cause Analysis: 1. Antenna cable tie-in is no good 2. Cable connective is wrong. 3. DRFU is snag. 4. Antenna Mode configure is wrong. 4.Handling Process: 1.RestarDRFU,theVSWRalarmisdisappear,onemoment,theVSWRisappearat once. 2.Change the DRFU board, the VSWR is disappear when change finished, but 30 minute later, the VSWR alarm is appear. Check DRFU cable connect, the connection is right. 3.Touch DRFU board, discover the DRFU board temperature is very high. Maybe because of DRFU transmit too high. So we check data configure in BSC , discover S222 siteSend Receive Mode is Double Antenna in TRX configure site Board attributes. But S444 site Send Receive Mode is Double Antenna in TRX configure site Board attributes also. ResultinDRFUboardtemperatureisveryhigh.ModificationS444siteSendReceive Mode to Single Antenna Double Receive. RetouchDRFUboard,theDRFUtemperaturedepressed,about10minutelater,the VSWR alarm is disappear. The problem is resolved. 5.Suggestions and Summary: Astheskillreuseatpresent,onestaffwithresponsibilityforsitesswapandnetwork optimization is possibility. So for new BTS we need to know the performance, but also need to know difference of data configure with old BTS. GSM Product Training Technical Cases HUAWEI Confidential38 And we must to check the rationality of data configure in before cut over. In older to reduce risk of swap, and to improve success rate of swap Case9.Tilt & Azimuth error cause TCH assignment successfully rate is low and Handover failure Title Tilt & Azimuth error cause TCH assignment successfully rate is low and Handover failure KeywordsTCH assignment successfully rate,Handover failure, antennas tilt Case codeBTS3900-009Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description TherewasnoPhysicalAlarmonthesite,butaccordingtothestatstherewasTCH assignmentsuccessfulratewasverylowandalsositewasexperiencinghandover failures. 2.Alarm Information: there was no hardware or software alarm on the site. 3.Cause Analysis: Therecanbemanyreasonsofthiscase.Thecallsarenotbeinghandedovertothe neighboring cells. Traffic congestion is very high. Some channels of the TRX are fault. TRX transmitting power is very low or other following cases. 1) check the internal RF connections, they all were Ok. 2) check and traced the Feeder cables from the Antenna side to the BTS side. 3) Check DTRU's and DDPU's of the effected sector. 4.Handling Process: Step1: Checkedthe internal RF cables and configuration with that of the BSC's Step 2:Trace the Feeder cables so that there would be no partial or full swap between serving sectors. Step 3: Check whether DDPU or DTRU is faulty or not. GSM Product Training Technical Cases HUAWEI Confidential39 Step4:WhencheckedtheAzimuthandmechanical&ElectricalTiltoftheeffected Antenna it was found totally changed when compared to the RF plan, where mechanical tilt have to be Zero '0' but that antennas tilt was 4 and also azimuth was not ok. after making changes TCH assignment successful rate become normal and handover failure issue was also resolved. 5.Suggestions and Summary: InTCHassingmentsuccessfulrate/Handoverfailure/calldropingissuesfirstgetthe accuraterecordofazimuths,MechanicalTilts&ElectricalTiltsfromtheprojectteamor fromtheoperatorandcheckit.iffindinaccuratethanmakechangesaccordingtothe plan . Case10.GSM Cell Transmission Delay Abnormal in Abis over IP TitleGSM Cell Transmission Delay Abnormal in Abis over IP KeywordsTransmission, delay, abis, ping Case codeBTS3900-0010Case type Data Configuration&Commissioning Case is from Huawei Support site Update Time 2012 Product Family GSM BSSProductBTS3900 1.Phenomenon Description The event "GSM Cell Transmission Delay Abnormal " is intermittently generated indicating a high transmission delay between BSC and BTS. The value showed in the event content is about 180ms, which is lower than the threshold for this event to be generated.(240ms for terrestrial transmission type / 800ms for satellite transmission type). 2.Alarm Information: Event: GSM Cell Transmission Delay Abnormal. 3.Cause Analysis: When ping from BSC interface board to the BTS is performed, the response time seems to be low. (lower than 50ms) GSM Product Training Technical Cases HUAWEI Confidential40 However, if a continuous ping is performed, the result has some particularity, like: Reply from 10.223.86.66: bytes=56 Sequence=1 ttl=255 time=23 ms Reply from 10.223.86.66: bytes=56 Sequence=2 ttl=255 time=24 ms Reply from 10.223.86.66: bytes=56 Sequence=3 ttl=255 time=37 ms Reply from 10.223.86.66: bytes=56 Sequence=4 ttl=255 time=71 ms Reply from 10.223.86.66: bytes=56 Sequence=5 ttl=255 time=29 ms Reply from 10.223.86.66: bytes=56 Sequence=6 ttl=255 time=36 ms 3 minutes later... Reply from 10.223.86.66: bytes=56 Sequence=15 ttl=255 time=838 ms Reply from 10.223.86.66: bytes=56 Sequence=16 ttl=255 time=37 ms Reply from 10.223.86.66: bytes=56 Sequence=17 ttl=255 time=32 ms 2 minutes later Reply from 10.223.86.66: bytes=56 Sequence=15 ttl=255 time=1638 ms Reply from 10.223.86.66: bytes=56 Sequence=18 ttl=255 time=39 ms ... Whenweobserveforalongtime,therecanbesporadicallypacketswithlongdelay response time. 4.Handling Process: Althoughtheaverageresponsetimeislow,therearemanysporadicpacketswith response time above the thresholds. Thisisinfactresponsibleforthealarmtobegenerated,evenwithadelayindication, inside the event, lower than the threshold. This is how this analysis can be developed from product point of view when transmission does not indicate any problem looking just at average response time and loss of packets. 5.Suggestions and Summary: It is good to evaluate the delay and decide if it worths to maintain the transmission state in such conditions. If the conditions are not so bad (not so big delays and not so often), a reconfiguration of some parameters* can be done and the network can operate without serious impact. * transmission type, BTS clock, T200 timer, MS Max Retrans. GSM Product Training Technical Cases HUAWEI Confidential41 Case11.2G to 3G cell reselection unsuccessful Title2G to 3G cell reselection unsuccessful Keywords2G, 3G, cell reselection Case codeBTS3900-0011Case typeData Configuration Case is from Huawei Support site Update Time 2012 Product Family GSM BSSProductBTS3900 1.Phenomenon Description GSM BSC 6900 V900R013C00SPC500 While testing for 2G to 3G cell reselection, we were not able to perform it successfully, and it was geeting failed for both ways i.e from 2G to 3G and from 3G to 2G, and also there was not much information in the Trace as well. 2.Alarm Information: Null 3.Cause Analysis: We started cheking the cause one by one in the following step. 1. Check the configuration of 2G cell. For eg: Routing Area and other information 2. Check the configuration of 3G external cell. 3. check the defined relation between 2G and 3G cells 4.CheckthereselectionparameterswithcommandsLSTGCELLHOBASICandLST GCELLCCUTRANSYS 4.Handling Process: As per our analysis, we started with one by one step as follows 1. we checked the configuration of 2G cell and found it okay. the configuration including routing area was as per given parameters 2. After this we checked the parameters of 3G external cell by command LSTGEXT3GCELLandLSTG3NCELLandfoundtheywerealsoaspergiven parameters. 3.AfterthiswecheckedthereselectionparameterswithcommandsLST GCELLHOBASIC and LST GCELLCCUTRANSYS and these parameters were also okay and were as per Hedex. 4. Then we looked again on the details of these two commands and while looking into the details of these commands, GSM Product Training Technical Cases HUAWEI Confidential42 we found that there was one parameter named as "MSC Version Indication" in SET GCELLCCUTRANSYS command and in this parameter it was given thatifourBSCisconnectedtotheMSCthatistakingonly2GsignallingthenMSC version should be set as R98_or_below. And if the MSC is taking 2G and3G both signalling then MSC version should be set as R99_or_above. SooninquiringabouttheMSCwecametoknowthattheMSCwashandlingonly2G signalling so we set the MSC version as R98_or_below. After this we performed the testing again and it was successfull this time. 5.Suggestions and Summary: Whileconfiguring for2G/3Greselectionwe mustnotonlypayattentiontoRoutingarea parametrs but also to MSC version,and we should always get the details of MSC to which the BSC is getting connected. Case12.Technical Case Regarding HUAWEI GSM BTS TitleTechnical Case Regarding HUAWEI GSM BTS KeywordsDCTB, DTRU, DDPU Case codeBTS3900-0012Case typeCommissioning Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description DealtwithHUAWEIGSMBTS.It'sreportedthatthetwosectorsarecontinously fluctuating with escalated alarm of DTRU Communication Abnormal & the sectors are brought back to the working state after two minutes. 2.Alarm Information: Alarm generated as per the report is " DTRU Communication Abnormal" for 1ST & 2nd Sector of Huawei GSM BTS. 3.Cause Analysis: Aaccording to the Alarm generated,it can be infer intially that DTRU or DDPU can cause the issue. GSM Product Training Technical Cases HUAWEI Confidential43 It can also be assumed that Back plane should also be a reason for the fluctuation as the Upper subrack of sectors are only fluctuating for the time being. 4.Handling Process: EachDTRUfromfluctuatingsectorshasaddedto3rdsector&Created&checkedfor consistency. It's came to found that thoseDTRU has not got down at 3rd sector.So DTMU,DDPU & Back plane changed accordingly. But the site status remain unchanged & started fluctuating again for the 1ST & 2nd sectors indefinitely. Finally changed DCTB of BTS & Issue successfully shown to be cleared. 5.Suggestions and Summary: No alarms are generated /found corresponding to DCTB board.So find difficult to analyse at first stage. So as to resolve the issue,particular alarms should be analysed or tracked out for the root clearance of BTS sector down. Case12.GSM Cell UL Quality abnormal TitleGSM Cell UL Quality abnormal KeywordsGSM bad uplink quality, TMSI Case codeBTS3900-0013Case typeO&M Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 1.Phenomenon Description CustomerXfromcountryYhasreportedbaduplinkquality&uplinkstrengthinthe3rd sector of GSM site Z. 2.Alarm Information: Null 3.Cause Analysis: FrompartofthemessagesfeedbackitshowstheSDCCHdroprateis11.76%.The reasons are error indication messages, GSM Product Training Technical Cases HUAWEI Confidential44 with message T200 expired. TCH drop is zero. Figure 1 shows the service of the cellis not affected. T200expirationshouldindicatethattheMShasnoinformationofsystemlocation updating request. Take one of the process the MR shows during the location updating for example . The MR has a lot of 7/-110dB records because theres no response from MS. At the same time the downlink is normal.

Fig.1. But it causes the cell uplink quality abnormal as in figure 2. Fig.2. Location updating successful rate of the cell is only 28.5%.Part of the reason is the MS no response,other causes are location updating reject with reason is PLMN not allowed. GSM Product Training Technical Cases HUAWEI Confidential45 Fig.3. For the trace it can be used TMSI( fig 4), the IMSI of the MS is unavailable. . 4.Handling Process: Null 5.Suggestions and Summary: The issue caused by abnormal location updating process.MS is not responding to the location update request. The service of the cell is not affected. Only the ULquality of the cell is abnormal. Faulty terminal issue. Case14. GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell Title GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell KeywordsNeighbouring Cell, TMSI Case codeBTS3900-0014Case typeData Configuration Case is from Huawei Support site Update Time 2013 Product Family GSM BSSProductBTS3900 GSM Product Training Technical Cases HUAWEI Confidential46 1.Phenomenon Description ProblemDescription:UsercomplaintNastarAnalysisFunction"GSMNeighboringCell AnalysisData"doesnotshowsomemeasurementreportforsomecellInIManager Nastar V600R008C01SPC200. Please refer to below screenshot: : 2.Alarm Information: Null 3.Cause Analysis: 1. From the screenshot provided by user, we found out some of the "GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell". 2.SuspectcustomerdidntenablethecounteronM2000,advicecustomercheckthe counter setting on M2000 and found out customer didnt enable some of the counter. 3.AdvicecustomertoenableallthecounterinordertofacilitateGSMNeighboringCell Analysis in IManager Nastar V600R008C01SPC200. Cause : Customer didn't enable some of the counter in M2000, hence some of the "GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell". GSM Product Training Technical Cases HUAWEI Confidential47 4.Handling Process: 1. Request screenshot and raw data file from user. 2. Wesuspectuserdidntenablebelowcounterin M2000tofacilitateGSMNeighboring Cell Analysis in IManager Nastar V600R008C01SPC200. 3. In order to to facilitate GSM Neighboring Cell Analysis, all the counters of the subsets need to be activated in M2000. A. MR Measurement -> Number of MRs per Cell B. MR Measurement -> Neighbor Cell Level Measurement per Cell C. MR Measurement -> Uplink-and-Downlink Balance Measurement per TRX D. MR Measurement -> Number of MRs based on TA per TRX E. MR Measurement -> TCHF Receive Level Measurement per TRX F. MR Measurement -> TCHH Receive Level Measurementper TRX G. MR Measurement -> Receive Quality Measurement per TRX H. Call Measurement -> GSM Cell to GSM Cell Outgoing Handover Measurement. 4.Afterconfirmwithuser,wefoundthatuserdidn'tenablecounterofthesubsetwhen perform GSM Neighboring Cell Analysis. 5. We provide the steps to customer to activate the 8 function subsets. A. Log in the M2000 client and make sure the username has got the privilege to finish the following steps. B. Open the page: M2000 -> Performance -> Measurement Management. C.Activateallthe8subsetsonebyoneaccordingtothefollowingpictureandclick Apply" GSM Product Training Technical Cases HUAWEI Confidential48 7. After activate the counter, the problem has been solved, user is able to facilitate Nastar Analysis Function "GSM Neighboring Cell Analysis Data" please refer to below screenshot. Note:Method above to activate counter in M2000 is applicable to all version of M2000. GSM Product Training Technical Cases HUAWEI Confidential49 5.Suggestions and Summary: PleaseenableandcheckallthecounterinM2000beforefacilitateNastarAnalysis Function "GSM Neighboring Cell Analysis Data"in IManager Nastar System.