WCDMA Product Training Technical CasesWCDMA Product Training Technical Cases 2013 HUAWEI Confidential WCDMA Product Training Technical Cases Table of Contents BSC6900 Troubleshooting Cases ............................................................................................... 1 Case1 PS Paging Loss due to high CPU load ........................................................................ 1 Case2 RNC paging SR drop to 75 due to the MSC wrong LAC configuration.......................... 3 Case3 IP Overbooking activation causing abnormal CS calls and PS calls ............................. 6 Case4 Analysis for IP Address Conflict Effected PS traffic Problem .......................................10 Case5 Cell setup failure at two 3G sites due to DPUe hardware fault ....................................13 Case6 The Report of IUPS Load share Problem ...................................................................18 NodeB Troubleshooting Cases..................................................................................................21 Case1 IPPM Traffic Measurement Counter Showing a 100% Packet Loss Rate Due to DSCP Modification ................................................................................................................21 Case2 Transmission interference vibration lead to Single-Site Clock Unlock..........................24 Case3 M2000 Fails to Maintain NodeB Using OM IP Due to Incorrect Mask Settings at IP Segment of Transmission Device ..........................................................................................26 Case4 Reversely Connected Antennas Lead to Abnormal Cell KPIs......................................29 Case5 CPU Overload Leads to Abnormal NodeB Reset ........................................................66 Case6 3G Cells Cannot Setup ..............................................................................................69 RAN Optimization Cases............................................................................................................73 Case1 Abnormal Feeder Connection Causes KPI Deterioration ............................................73 Case2 RRC Access Success Rate Decreases Due to Inconsistency Between the Uplink and Downlink Coverage of Remote Cells ..............................................................................83 Case3 Analysis for High Call Drop Rates of a Single Cell on a New Site................................85 Case4 PS RAB Setup Rate degradation due to forward bandwidth congestion ......................87 Case5 PS performance degradation under RNC 'X' ...............................................................89 Case6 Low RAB Success in RNC .........................................................................................92 HUAWEI Confidential i WCDMA Product Training Technical Cases BSC6900 Troubleshooting Cases Title Cannot connect to internet(IUPS) Keywords Request Maximum bit rate for UL not availabe Case code BSC6900-001 Case type Data Configuration Case is from Huawei Support site Update Time 20130823 Product Family BSC6900 Product BSC6900 Case1 PS Paging Loss due to high CPU load 1. Phenomenon Description New commission RNC cannot attach to internet . Configuration data have been check and RNC been reset. 2. Alarm Information No alarm found. UE trace indicate: 'radioNetwork:0x14(20): requested-maximum-bit-rate- not-available 3. Cause Analysis The subscriber can make test call(IUCS) but cannot connect to internet(IUPS). After done UE trace, it was found that there is insufficient in the radio resource. HUAWEI Confidential 1 Only the CS service can make call because PATHT=EF already configured in iub path. HDINTHGHPRIPATH=AF13. change setting and reset RNC. PSINTHGHPRIPATH=AF23. ADD TRMMAP: TMI=101. Check alarm and no alarm were found. Reset RNC and Node B test. 5. HUINTHGHPRIPATH=AF13. TRANST=IP. Compare configuration with other RNC’s and found some mismatch on the TRMMAP setting. VOICEPRIPATH=EF. Use command MOD TRMMAP. So PS service should can make service after add AF23 and AF13 in IUB path. no inconsistency. Handling Process Increase the flow control threshold for SMS services. PS INT is AF23 and HS INT is AF13 but is not configure in ADD IPPATH for IUB path. Problem Solve. ITFT=IUB. HUAWEI Confidential 2 . Suggestions and Summary PS cannot make service is because of Tx service mapping is not correct.WCDMA Product Training Technical Cases 4. Check configuration data. status is still the same. Which means in ADD TRMMAP. and the counter VS. Alarm Information Null 3. 4. Wrong paging message send from the CN. 2G and 3G has the same LAC area. there is no any LAC/RAC modification.Num. Phenomenon Description J country C network. check the RNC operation log.WCDMA Product Training Technical Cases Title RNC paging SR drop to 75 due to the MSC wrong LAC configuration Keywords Paging LAC PCH Congestion low Control Case code BSC6900-002 Case type Service Case is from Huawei Support site Update Time 20130719 Product Family BSC6900 Product BSC6900 Case2 RNC paging SR drop to 75 due to the MSC wrong LAC configuration 1. 2. Handling Process 1) 2) Paging SR was dropped at the 19 Feb.Disc. Paging message discard due to the flow control. Cause Analysis 1) 2) 3) 4) 5) Iu some RNC configuration change cause the paging SR decreased.CPUS value is 0. paging success rate of the CN is normally and steadily. there is one RNC paging success rate drop from 90% to 75% at 19th Feb. Check the RNC alarm log.Paging.FC.. HUAWEI Confidential 3 . PCH has congestion. there is no flow control alarm with the paging discard. so there is no any paging message discard due to the flow control. PsPaging.Paging1. there is almost no paging discard due to the PCH congestion. paging message from this abnormal LAC is 15% of total. 5) Compare the LAC configuration of the 2G and 3G.Loss.CsPaging. there is no same LAC configured at the BSC and RNC. but this RNC only configure 6 LAC area.Loss and VS.Loss value is also 0.Cell.WCDMA Product Training Technical Cases 3) Check another two counter VS. we find this RNC receive paging message from 7 LAC area. 6) 7) HUAWEI Confidential 4 .RRC.PCHCong. 4) Check the counter VS. so we confirm there is no paging discard at the RNC side. Analysis the IU trace.RANAP. Discuss with MSC engineer and confirm the abnormal LAC belong to the 2G. filter the paging message.RANAP. HUAWEI Confidential 5 . Exclude RNC and Cell PCH congestion possibility of doubt. RNC paging SR become normally. Iu trace is good way to analysis. 5. Suggestions and Summary KPI decrease suddenly，check the operation of the network firstly. after MSC modify it.WCDMA Product Training Technical Cases MSC wrong configure at 19th Feb. WCDMA Product Training Technical Cases Title IP Overbooking activation causing abnormal CS calls and PS calls Keywords IP Overbooking Case code BSC6900-003 Case type Data Configuration Case is from Huawei Support site Update Time 20130621 Product Family BSC6900 Product BSC6900 Case3 IP Overbooking activation causing abnormal CS calls and PS calls 1. Phenomenon Description After reconfigure the IUB and activate the IP Overbooking function for 7 RNCs and their NodeBs, received multiple end user complaints regarding difficulty to make CS and PS calls. The services return to normal after rollback is performed. But the issue arises when IP Overbooking is enabled again. RNC Version: V900R014C00SPC520 NodeB Version: V200R014ENGC00SPC350 2. Alarm Information Null 3. Cause Analysis Due to not all the RNCs and NodeBs are having end users complaints, focus is shifted towards troubleshooting the RNC with majority of complaints. When IP Overbooking is rolled back, the UE under the NodeB tied to the RNC Interface board can use the services normally. From Counter “VS.FEGE.TXMAXSPEED”, we observed that the throughput is capped at around 65Mbps for the Port 0 of the RNC Interface board. Verification on the commands to activate IP Overbooking from the RAN Feature Activation user guide is done and found no special remarks on the limitation for the IP LOGICPORT, which means when one NodeB's IUB bandwidth setting exceeds the IP Logic Port setting, one IP Logic Port can only assign to one NodeB. Else it will result HUAWEI Confidential 6 WCDMA Product Training Technical Cases in packet loss on the port due to the capping of the IP Logic Port. That is why some of the UEs are facing CS and PS issue. 4. Handling Process 1) Initial data configuration for IP overbooking: Multiple NodeBs are sharing the same IP Logic Port. ADD IPLOGICPORT: SRN=2, SN=20, BT=GOUc, LPNTYPE=Leaf, LPN=0, CARRYT=ETHER, PN=0, RSCMNGMODE=SHARE, BWADJ=OFF, CIR=1000, FLOWCTRLSWITCH=ON, FCINDEX=0, OPSEPFLAG=OFF; MOD IPPATH:ANI=219,PATHID=1,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=219,PATHID=2,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=219,PATHID=3,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=219,PATHID=4,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=238,PATHID=1,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=238,PATHID=2,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=238,PATHID=3,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=238,PATHID=4,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=26,PATHID=1,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=26,PATHID=2,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=26,PATHID=3,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=26,PATHID=4,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; Through checking Counter (VS.FEGE.TXMAXSPEED) on two of the RNC as shown in the charts below, we can see that the IUB Bandwidth is limited at around 65Mbps after activating the IP Overbooking. Also, the bandwidth went back to normal after fallback is done. HUAWEI Confidential 7 WCDMA Product Training Technical Cases 2) After modification on the data configuration. One IP Logic Port is assigned to one Node B. ADD IPLOGICPORT: SRN=2, SN=20, BT=GOUc, LPNTYPE=Leaf, LPN=0, CARRYT=ETHER, PN=0, RSCMNGMODE=SHARE, BWADJ=OFF, CIR=1562, FLOWCTRLSWITCH=ON, FCINDEX=0, OPSEPFLAG=OFF; ADD IPLOGICPORT: SRN=2, SN=20, BT=GOUc, LPNTYPE=Leaf, LPN=1, CARRYT=ETHER, PN=0, RSCMNGMODE=SHARE, BWADJ=OFF, CIR=1562, FLOWCTRLSWITCH=ON, FCINDEX=0, OPSEPFLAG=OFF; ADD IPLOGICPORT: SRN=2, SN=20, BT=GOUc, LPNTYPE=Leaf, LPN=2, CARRYT=ETHER, PN=0, RSCMNGMODE=SHARE, BWADJ=OFF, CIR=1562, FLOWCTRLSWITCH=ON, FCINDEX=0, OPSEPFLAG=OFF; MOD IPPATH:ANI=219,PATHID=1,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; MOD IPPATH:ANI=219,PATHID=2,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=0; HUAWEI Confidential 8 PATHID=2.ITFT=IUB.PATHID=3.LPN=1. 5.PATHID=1.CARRYFLAG=IPLGCPORT.LPNSN=20.ITFT=IUB.ITFT=IUB.LPNSN=20.PATHID=4.LPNSN=20.CARRYFLAG=IPLGCPORT. MOD IPPATH:ANI=26. we can see that the IUB Bandwidth are normal after activating the IP Overbooking by assigning one IPLOGICPORT to one NodeB.LPN=2. MOD IPPATH:ANI=238. MOD IPPATH:ANI=238.LPN=2.LPNSN=20. MOD IPPATH:ANI=26.ITFT=IUB.CARRYFLAG=IPLGCPORT.CARRYFLAG=IPLGCPORT.LPN=0.LPN=2.WCDMA Product Training Technical Cases MOD IPPATH:ANI=219. MOD IPPATH:ANI=26. HUAWEI Confidential 9 . MOD IPPATH:ANI=26.ITFT=IUB. Also. From the same counter as shown in the chart below.LPN=1.PATHID=2.LPN=0.LPN=1.CARRYFLAG=IPLGCPORT. Suggestions and Summary More information regarding the impact and parameter settings should be provided in details in the guide.ITFT=IUB.ITFT=IUB.LPNSN=20.LPNSN=20.PATHID=1.PATHID=3. in the guide should suggest which performance counters to monitor before and after the activation.ITFT=IUB. MOD IPPATH:ANI=219. MOD IPPATH:ANI=238.ITFT=IUB.LPNSN=20.CARRYFLAG=IPLGCPORT.LPN=1.PATHID=3.LPNSN=20.LPNSN=20.CARRYFLAG=IPLGCPORT.CARRYFLAG=IPLGCPORT.LPN=2. MOD IPPATH:ANI=238.CARRYFLAG=IPLGCPORT.LPNSN=20.PATHID=4.ITFT=IUB.PATHID=4.CARRYFLAG=IPLGCPORT. 2. PS traffic decreased sharply. the alarm “IP Connectivity Check Failure” and “IP Address Conflict” appeared. And the PS traffic was also affected. Handling Process 1. Cause Analysis ARP check failure lead to this issue 4. HUAWEI Confidential 10 .WCDMA Product Training Technical Cases Title Analysis for IP Address Conflict Effected PS traffic Problem Keywords IP address conflict ARP check Case code BSC6900-004 Case type OM Case is from Huawei Support site Update Time 20130522 Product Family BSC6900 Product BSC6900 Case4 Analysis for IP Address Conflict Effected PS traffic Problem 1. Alarm Information ALM-21346 IP Connectivity Check Failure ALM-21347 IP Address Conflict 3. Phenomenon Description When a 2G site added. 2. When added a 2G site. STR IPCHK:SRN=0. WHETHERAFFECTSWAP=NO.16. PN=0. CHKN=0.73). PEERIP="10. This means the link between RNC and gateway is disconnecting frequently.16.128. ARPRETRY=2. RNC sent ARP request to router (10.16. the active link activated ARP detection. CHKTYPE=ARP. When ARP check failure.73) until ARP check success again. SN=18. 5. BSC1 shielded the rout IP (10.WCDMA Product Training Technical Cases 3.128. CARRYT=ETHPORT.128. RNC will set the next-hop address unreachable.16. so it lead to ARP check failure.73". ARPTIMEOUT=2.128. and then the sent HUAWEI Confidential 11 .16. At the problem time. the next hop address is 10. 4. 6. MODE=CHECK_ON_PRIMARY_PORT. All the sites connect to slot 18 of Subrack 0.73). The ARP detection between BSC01 and gateway failed and the IP Connectivity Check Failure alarm was reported.73. and RNC didn’t receive ARP response. So RNC will not sent data to the next hop address.128. So BSC1 didn’t send data to the router (10. 7. In slot 18 of Subrack 0. so the ARP check failure and the alarm “IP Connectivity Check Failure” appeared .WCDMA Product Training Technical Cases and received traffic had a sharply decrease during the ARP check failure of IUB interface.73). Suggestions and Summary When IP address conflict. the router didn’t response the ARP request from RNC.16. HUAWEI Confidential 12 . 5. Also the PS throughput decreased because of the IUB traffic decrease. So PS was affected finally.128. it lead to RNC automatically shields the next-hop IP address (10. 8. There are 8*E1s configured for both sites. Phenomenon Description All the cells of two NodeBs failed to setup at almost the same time.WCDMA Product Training Technical Cases Title Cell setup failure at two 3G sites due to DPUe hardware fault Keywords Cell Setup FP Synchronization Failed. 2. Alarm Information The following alarms were reporting on both sites Critical 22214 NodeB Unavailable Critical 22202 UMTS Cell Unavailable HUAWEI Confidential 13 . Both sites are on same SPUb board which has no other sites on this RNC. all the E1 ports are UP on both NodeBs except for one E1 port on one NodeB. The reason of the setup failure was “FP synchronization failed”. DPUe Case code BSC6900-005 Case type Hardware Case is from Huawei Support site Update Time 20130520 Product Family BSC6900 Product BSC6900 Case5 Cell setup failure at two 3G sites due to DPUe hardware fault 1. However. 7. still encountered the same cell setup issue after resolved the transmission issue. 2.WCDMA Product Training Technical Cases Minor 22208 UMTS Cell Common Channel Setup Failed Having the following Major alarm on one of the NodeBs for one E1 port. Two sites were restored after reset the 0:15 DPUe board and based on the deeper analysis of PFM log and Cell trace that captured from RNC. 6. This issue was due to the DPUe hardware faulty which caused the incoming packets being discarded by the underlying process of DPUe. Isolated the transmission fault as the first step because 95% of FP synchronization failures were related to the transmission issues. 4. the 0:15 DPUe usage was Zero and there was no user attached to this DPUe board. when checking the usage of 0:15 DPUe via commands DSP UDSPRESOURCE and DSP DSPUSAGE. Cause Analysis UMTS cell common channel setup failed with cause code ‘FP synchronization failed’. However. Both sites are binding to the same 0:8 SPUb board which has no other sites. Checked the configuration and found that the 0:15 DPUe board is binding to 0:8 MPU subsystems. we confirmed there is a hardware issue on DPUe card that locates on Subrack 0 Slot 15. There are two DPUe boards (0:15 and 0:16) at subrack 0. It was found that there were E1 transmission mapping issues with both sites. And there is no alarm or preventive mechanism in the current RNC software version (V900R013ENGC00SPH556) to detect the incoming packet loss of DPUe board. It means 0:15 DPUe and these two NodeBs are binding to the same physical 0:8 SPU board. 3. RNC version: V900R013ENGC00SPH556 NodeB version: V200R013C00SPC521 1. RNC will give priority to use 0:15 DPUe when setting up the cells of these two problematic NodeBs. they are working on load sharing mode. however the issue persisted after performed reset and swap of the SPUb card. HUAWEI Confidential 14 . Major 21287 SDH/SONET Tributary Alarm Indication Signal 3. 5. it is very unlikely to have a hardware fault on both SPUb boards at the same time. The issue persisted after performed reset and swap of the 0:8 SPUb card. Handling Process 1. 2. 5. HUAWEI Confidential 15 . Major 21287 SDH/SONET Tributary Alarm Indication Signal 4. Checked the usages of 0:15 DPUe and 0:14 DPUe via command DSP UDSPRESOURCE and DSP DSPUSAGE. Critical 22214 NodeB Unavailable Critical 22202 UMTS Cell Unavailable Minor 22208 UMTS Cell Common Channel Setup Failed It also has the following major alarm on one of the NodeBs for one E1 port.WCDMA Product Training Technical Cases 4. Checked the status of AAL2PATH. NCP and CCP which are all normal. Confirmed there are no transmission quality fault by performing the ATM QoS tests. the usage of 0:15 DPUe was Zero and there was no user attached to this DPUe board. RNC will give priority to use 0:15 DPUe when setting up the cells of these two problematic NodeBs because 0:15 DPUe and these two NodeBs are binding to the same physical 0:8 SPU board. Fixed the transmission mapping issue for one side by performed the loopback test. Checked the alarm list and log. Checked the Operation log to confirm there was no changes have been done on both sites. 7. Checked the RNC configurations These two NodeBs are binding to the same 0:8 SPUb board. 6. the following alarms were reporting on both sites. the 0:15 DPUe board is binding to 0:8 MPU subsystems at the same cabinet 0. therefore we isolated the SPUb issue. 3. Furthermore. HUAWEI Confidential 16 . the usage of 0:15 DPUe board was zero at the time the problem occurred. FP synchronize failures were observed at 0:15 DPUe board. Also from the PFM log.WCDMA Product Training Technical Cases 8. 9. From the PFM log. Suggestions and Summary The root cause of this issue is due to the ASIC hardware fault at DPUe (0:15) board which casued the incoming packets being discarded by the underlying process of DPUe. Therefore.WCDMA Product Training Technical Cases 5. HUAWEI Confidential 17 . we recommend customer replace the faulty DPUe board at subrack 0 slot 15 on cabinet 0 of this RNC. The problem happened in period: from 4/11/2013 10:21:33 PM to 4/12/2013 6:45:40 AM. Alarm Information At complained period. we found there were many alarm related to Control plane of Iu-PS: "M3UA Link Fault". Phenomenon Description A lot of subscriber complained that they could not access internet via 3G service at one RNC of V network. 2. From the CFGMML we found that there is only one M3LNK configured for control HUAWEI Confidential 18 . we saw that around 10 minutes. Alarm name Alarm raised time Cleared time M3UA Destination Entity Route Unavailable 4/12/2013 6:45 4/12/2013 6:51 M3UA Destination Entity Inaccessible 4/12/2013 6:45 4/12/2013 6:51 SCCP Subsystem Prohibited 4/12/2013 6:45 4/12/2013 6:51 M3UA Link Fault 4/12/2013 6:45 4/12/2013 6:51 M3UA Destination Entity Route Unavailable 4/12/2013 6:35 4/12/2013 6:45 M3UA Destination Entity Inaccessible 4/12/2013 6:35 4/12/2013 6:45 SCCP Subsystem Prohibited 4/12/2013 6:35 4/12/2013 6:45 M3UA Link Fault 4/12/2013 6:35 4/12/2013 6:45 M3UA Destination Entity Route Unavailable 4/12/2013 6:25 4/12/2013 6:35 M3UA Destination Entity Inaccessible 4/12/2013 6:25 4/12/2013 6:35 SCCP Subsystem Prohibited 4/12/2013 6:25 4/12/2013 6:35 M3UA Link Fault 4/12/2013 6:25 4/12/2013 6:35 From alarm log. these alarms were cleared normally and happened again. 3G voice service was normal at that time. "M3UA Destination Entity Inaccessible" and "SCCP Subsystem Prohibited". Please check alarm log for more details. Investigation result showed that control plane of Iu-PS interruption. whereas. 3. Customer complained that Huawei RNC worked unstably and bad quality sometimes.WCDMA Product Training Technical Cases Title M3UA Link of Iu-PS caused Iu-PS service interruption Keywords IuPS interruption M3UA Link Fauly Case code BSC6900-006 Case type Service Case is from Huawei Support site Update Time 20130520 Product Family BSC6900 Product BSC6900 Case6 The Report of IUPS Load share Problem 1. "M3UA Destination Entity Route Unavailable". Cause Analysis 1. at the complained period. which made the M3UA link could not be activated. Suggestions and Summary 1. 2. And the SCTP link which bearing the M3UA link was always fine. and customer added one more link as our suggestion. It highly recommends that at least two M3LNK configured for Iu-CS/Iu-PS interface for safe reason and load sharing. 5. 4. SGSN send back to RNC an error message with error code 6. which meant there was no fault on SCTP link and the transmission. when RNC sent ASP Active message to SGSN. the reason was that when RNC detect the M3LNK failure. it was not followed Huawei rule. SSN=1. it can be found that the problem occurred at 22:21. and it may has risk of one signalling processing board failed.WCDMA Product Training Technical Cases plane of IuPS. the M3UA Link fault would be recovered and then reported again. It proved that the probelm caused by SGSN not RNC. From debug log analysis. Manually activate M3LNK by command: ACT M3LNK. 2. After Huawei sent report analysis to customer to request SGSN Vendor doing some analysis. SN=4. In engineering period. From the alarm log. SIGLNKID=0. 5. PRIORITY=0. 3. Rectification: Because there is only one M3LNK configured for Control plane. it will release the SCTP link and reestablish again. SCTPLNKN=4. every 10 minutes. Handling Process 1. we should strictly obey configuration rule to configure HUAWEI Confidential 19 . so the M3UA link alarm would be recovered and then reported 4. They said that one signalling board of SGSN was abnormal at that period. ADD M3LNK:SIGLKSX=0. SRN=0. After that. NAME="M3LK1_PS". LNKREDFLAG=M3UA_MASTER_MOD. There was no alarm and operation which could cause the alarm at the time. Iu-CS. Please check the problem report analysis attached to study this case. Iur to ensure safety and load sharing. When problem happened. HUAWEI Confidential 20 . debug log to find the root cause timely. 2. operation log.WCDMA Product Training Technical Cases important interfaces such as Iu-PS. we should deeply analysis alarm log. Both reach 100%.WCDMA Product Training Technical Cases NodeB Troubleshooting Cases Title IPPM Traffic Measurement Counter Showing a 100% Packet Loss Rate Due to DSCP Modification Keywords IPPM.DropRates. 2. Cause Analysis 1) Traffic statistics analysis The original traffic statistics show that the 100% packet loss rate is frequently seen. 100% indicates that all IPPM measurement packets are lost.IPPM. Engineers observe the traffic measurement counters VS. The two counters record the lost IPPM packets.Forword.DropMeans and VS. The M2000 traffic display cause is ruled out. HUAWEI Confidential 21 .IPPM.Peak. the command output shows that DSCIP is modified. Alarm Information Null 3. which affects the performance of services on the NodeB. Phenomenon Description A certain carrier reflects a problem: After IPPM is activated. The NodeB flow control may be triggered. DSCP Case code NodeB-001 Case type Interconnection Case is from Huawei Support site Update Time 20130816 Product Family NodeB Product NodeB Case1 IPPM Traffic Measurement Counter Showing a 100% Packet Loss Rate Due to DSCP Modification 1. 100%.Forword. 3) Generally. The packet HUAWEI Confidential 22 .WCDMA Product Training Technical Cases 2) IPPM implementation mechanism analysis IPPM uses forward monitoring (FM) and backward reporting (BR) to detect packet loss on the path. The peer end returns a BR reply after receiving the FM message. In an IPPM detection. one end sends an FM message periodically. and DSCP. the RNC counts transmitted and received IPPM packets by referring to a four-element group: source IP address. and the corresponding DSCP is 0x2e. one of the four elements may be faulty for most cases. FM ID is 0x2000 on the RNC. protocol type. The transmit end determines delay. When IPPM packet loss rate reaches 100%. 4) Packet capturing analysis We capture packets on both the RNC and NodeB and analyze the result. DSCP is zero for the same packet of FM ID 0x2000. On the NodeB. as shown in the following figure. and packet loss on the transmission path according to the BR reply sent by the receive end. target IP address. This is the transmit end. vibration. WCDMA Product Training Technical Cases from the RNC of DSCP = 0x2e has been changed to zero on the NodeB. The problem is resolved. resulting in a 100% IPPM packet loss rate. Handling Process Disable the DSCP modification function of the intermediate switch. It proves that an intermediate transmission device modifies the packet DSCP value. HUAWEI Confidential 23 . 4. 7367 Hz (obtained by curve fitting upon clock test values). The transmission link is stable. The cause is that the clock source is lost or deviates greatly. The clock state is fast tracking and cannot be locked. Phenomenon Description A certain office reported that a single-site clock cannot be locked. The total frequency deviation is over +3. The site services are running properly. Handling Process 1) The clock source or transmission link may be down. the clock still cannot be locked. After we change another E1. 2.WCDMA Product Training Technical Cases Title Transmission interference vibration lead to Single-Site Clock Unlocked Keywords Reference clock source abnormality alarm. Alarm Information Abnormal reference clock source is reported. The frequency deviation drops to 0 Hz for 44 times during 3 hours. We check other sites under the same RNC. 2) The reference source frequency may differ greatly from the local crystal oscillator frequency. we run DSP E1T1. 3. The site version is DBS3900 WCDMA V200R011C00SPC300. clock Case code NodeB-002 Case type Clock and time Case is from Huawei Support site Update Time 20130815 Product Family NodeB Product NodeB Case2 Transmission interference vibration lead to Single-Site Clock Unlock 1. The clock source cause is ruled out. Their clock sources can be locked and obtain correct clock signals. fast tracking. A clock test finds that the frequency deviation stabilizes at 3–4 Hz. This an irregular vibration caused by transmission interference. Then. HUAWEI Confidential 24 . do not use the MOD CENTERDA command.4 = 22336. The calculation formula: New center DA = original center DA – (65535/40 Hz) x frequency deviation LST DARECORD: SN = 7. SN=6.WCDMA Product Training Technical Cases 3) The previous analysis shows that the transmission interference is the cause of this problem. Suggestions and Summary 1) The primary and secondary WMPTs should have different center DAs due to the difference between their crystal oscillator frequencies. MOD CENTERDA: CN=0. SRN=0. DA=22336 The clock can be locked. The current DA is 28460. We adjust the center DA value to lock the clock signal. The problem is resolved.4 x frequency deviation = 28460 – 3.7376 x 1638. 2. 4. HUAWEI Confidential 25 . SRN=0. DA=22336 MOD CENTERDA: CN=0. SN=7. We run the following commands to set center DA to 22336. New center DA = current DA –1638. Unless you have confirmed that the clock has drifted and the center DA needs to be modified. IP6 is the IP address of the NodeB service gateway.WCDMA Product Training Technical Cases Title M2000 Fails to Maintain NodeB Using OM IP Address Due to Incorrect Mask Settings at IP Segment of Transmission Device Keywords OMCH. IP4 is the logical IP address of the NodeB. ARP proxy is enabled on the IP port. ARP. The OM IP address and service IP address of the NodeB are designed as shown in the following figure. IP2 is the service IP address. In this networking mode. IP4 communicates with other NEs through IP3 (OM port IP address). which is in VLAN 21. the service IP address of the NodeB can be pinged from the RNC. After the transmission test succeeds. HUAWEI Confidential 26 . whereas the logical OM IP address of the NodeB cannot be pinged from the M2000. a NodeB uses IP addresses for transmission and USB flash drives for commissioning. M2000. network segment Case code NodeB-003 Case type Operation and maintenance Case is from Huawei Support site Update Time 20130803 Product Family NodeB Product NodeB Case3 M2000 Fails to Maintain NodeB Using OM IP Due to Incorrect Mask Settings at IP Segment of Transmission Device 1) Phenomenon Description In a 3G network migration at country N. IP7 is the IP address of the NodeB OM gateway. which is in VLAN 31. HUAWEI Confidential 27 .163.237.237. Then. The ping operation fails. including IP address configuration.237.235) of the NodeB from the M2000.230 10.235 10.163. OMCH configuration.233) from the M2000. 2) Ping the NodeB OM gateway (10.163. Ping the logical OM IP address (10.235) of the NodeB. The ping operation succeeds.237. According to the fault phenomenon.163. The ping operation succeeds.237.237. NodeB Service IP NodeB Service NodeB OM Gateway to RNC Logical IP NodeB OM Port NodeB OM IP Gateway 10.234) of the NodeB to create a NodeB on the M2000. The ARP proxy of the NodeB is enabled and its IP address configurations are correct.234 10.163. pinging the NodeB OM gateway (10. the NodeB can be remotely maintained through the M2000. Ping the OM port IP address (10.163. ARP proxy configuration. However. IP route configuration. 5) Ping the NodeB OM gateway (10.237.237.163. The customer network segment settings may be incorrect. 4) Run an MML command to check the current data configurations of the NodeB. the ARP proxy of the NodeB may be disabled 3) Use the OM port IP address (10.237.237.163.233) from the logical OM IP address (10.229 10.163.233 2) Alarm Information Null 3) Handling Process 1) Start the Configuration Management Express (CME) to check data configurations.237. but the operation fails.234) succeeds.234) of the NodeB from the M2000.163.163.163. This indicates that OM VLAN settings on the transmission device are correct.WCDMA Product Training Technical Cases The following table lists the planned IP addresses of this NodeB.163.233) from the NodeB OM port IP address (10. No faults are found.237.237. Therefore. The mask settings of the OM gateway IP address on the transmission device are incorrect. 7) Instruct the customer to modify the mask setting. This fault occurs due to incorrect configurations by the customer and inflexible network design on this part.WCDMA Product Training Technical Cases 6) Check the configurations on thetransmission device. HUAWEI Confidential 28 . the M2000 fails to maintain the NodeB through the logical OM IP address. As a result. the OM gateway IP address and the logical OM IP address are not in the same network segment. Huawei devices combine the NodeB OM port IP address and the logical OM IP address into one to ensure that the service IP address and the OM IP address can be planned on the /30 network segment. The mask is set to /30 instead of /29. The mask settings of the OM gateway IP address are incorrect. This facilitates customers' configurations on devices and reduces the probability of configuration errors. At present. 4) Suggestions and Summary Configure the service IP address on /30 network segment and the OM IP address on /29 network segment. Phenomenon Description The access success rate is low in a RAN12. including the downlink power.0 macro cell 10111 and its KPIs must be optimized. 2. The congestion is determined based on the system resources usage. The interference can improve the uplink RTWP and decrease uplink loads. Iub bandwidth. and uplink RTWP. downlink orthogonal variable spreading factor (OVSF) codes.WCDMA Product Training Technical Cases Title Reversely Connected Antennas Lead to Abnormal Cell KPIs Keywords Reversely connected antennas. When the system is congested. Cause Analysis The problem may be caused by any of the following faults: The access success rate is greatly affected by the load control algorithm. uplink and downlink CE. the traffic volume during the period when the problem occurs is low and does not reach the threshold for triggering load control. the call admission control (CAC) or intelligent access control (IAC) is triggered. Only the RTWP may not be linear incremental with the traffic volume. HUAWEI Confidential 29 . RTWP. Alarm Information Null 3. access success rate Case code NodeB-004 Case type Performance Case is from Huawei Support site Update Time 20130205 Product Family NodeB Product NodeB Case4 Reversely Connected Antennas Lead to Abnormal Cell KPIs 1. resulting in congestion. Through the traffic analysis in cell 10111. the uplink RTWP of a cell is shared by two cells. Internal interference check: The internal interference may be caused by improper hardware installation or multi-frequency intermodulation. When the RTWP in a cell rises. In this case. 11. the traffic volume is high only in cell 10112. Reversely connected antennas: The abnormal RTWP may be caused by reversely connected antennas. Interference check shows that internal or external interference may exist. 10. The RTWP tracing of the problematic NodeBs shows that the RTWP rises in cells 10111 and 10112 simultaneously and is normal in cell 10113. resulting in inconsistent RTWP changes in the main and diversity channels. RTWP analysis of the neighboring NodeBs shows that no external interference exists. That is because the uplink signal of sector A is received by RF units connected to sector A when antennas are reversely connected. External interference check: All sectors in a certain direction of NodeBs will be affected due to external interference.WCDMA Product Training Technical Cases 4. 13. According to the check result. 12. the HUAWEI Confidential 30 . the RTWP in the cell with reversely connected antennas is also high. In the period that the problem occurs. Handling Process RTWP tracing shows that high RTWP is in cell 10111 It is proved that the abnormal RTWP is not caused by high traffic volume. Therefore. also called cross pair connection. the abnormal RTWP is not caused by internal interference. In this case. When analyzing this problem. The RTWP and the access success rate in cell 10111 become normal. This problem may not occur at the site verification stage due to low traffic volume. 5. Suggestions and Summary If antennas are reversely connected during hardware installation. you are advised to check the RTWP in two neighboring cells and observe the RTWP again after reconnecting antennas.WCDMA Product Training Technical Cases high load in cell 10111 is caused by reversely connected antennas with cell 10222. HUAWEI Confidential 31 . the involved two cells with reversely connected antennas will share uplink loads. Reconnect antennas on the RF port in the suspected cell and then check the RTWP in this cell. the system does not generate alarms. which decreases the cell capacity. but the cell KPI is affected when the traffic volume rises. from the perspective of the number of RRC connection setups or RAB setups. to measure NodeB traffic comprehensively. Therefore. and the CPU Overload alarm is generated. HUAWEI Confidential 32 . Alarm Information CPU Overload alarm 3. Check related materials and perform consultation. However. The result shows that this site is located on the top of a building on a higher ground. abnormal NodeB reset Case code NodeB-005 Case type Service Case is from Huawei Support site Update Time 20130205 Product Family NodeB Product NodeB Case5 CPU Overload Leads to Abnormal NodeB Reset 1. the CPU load excceeds80%. Therefore. Phenomenon Description On site La_Montagne. 2. both access and other factors should be considered. Besides. this site does not sit at the highest place of the entire area.WCDMA Product Training Technical Cases Title CPU Overload Leads to Abnormal NodeB Reset Keywords CPU overload. handover. this site provides a wider coverage for a large number of users. The result proves that traffic measurement can be complete only by taking access.AttRLSetupIub + RLM. The number of attempts per second that reflects the actual traffic on this site can be calculated using the formula ATTACH = RLM. Handling Process 1) Analyze the traffic volume on this site. and reconfiguration factors into consideration rather than only access. abnormal NodeB reset frequently occurs during heavy traffic hours.AttRLAddIub + VS.IUB.AttRLRecfg x 2in the attachment. The CHR analysis result is as follows: According to formula ATTACH = RLM. it is found that the flow control mechanism over the Iub interface fails when the CPU load is extremely high. which is close to the upper threshold of hardware processing capability (50 times per second). the protection mechanism is triggered and the NodeB resets unexpectedly.IUB. This problem is caused by limited hardware processing capability. the number of RAB setups is higher than those on site La_Montagne. On site Midstream_Estates.AttRLSetupIub + RLM. However. Consequently. In DBS3900.AttRLRecfg x 2 = 42540. This is why the CPU is heavily loaded on site La_Montagne but the CPU load on site Midstream_Estates is only between 30% and 40%. In this case. the NodeB continues to receive data from the RNC and sends it to the WMPT board. this problem has been resolved.26 per second. 3) Analyze the reason After this analysis. 2) Continue to check the reason for frequent reset It is assumed that the NodeB repeatedly reset during heavy traffic hours on site La_Montagne because of WMPT board faults. the problem persists after the WMPT board is replaced.AttRLAddIub + VS. No spare CPU load is available for processing more data because the CPU of the WMPT board is overloaded.11 per second.IUB. the attempt times is 47. the attempt times is 14.WCDMA Product Training Technical Cases For example: Site: La_Montagne The CHR analysis result is as follows: According to formula ATTACH = RLM.BTS3900 V200R011C00SPC320.AttRLSetupIub+RLM. which is far lower than that on site La_Montagne. 4) Advice operators to upgrade the HUAWEI Confidential NodeB to version DBS3900 33 .AttRLAddIub + VS.AttRLRecfg x 2 = 12698. 4. Therefore.BTS3900 V200R011C00SPC320. analyze a problem from different dimensions one by one.WCDMA Product Training Technical Cases . and deploy a new site around site La_Montagne to relieve its traffic load. HUAWEI Confidential 34 . Suggestions and Summary A problem may be caused by several reasons. this La_Montagne site runs normally. Currently. HUAWEI Confidential 35 . The Cell cannot setup and services cannot be launched after cutover of the site to fully IP. Alarm Information There is NO alarm.the feedback is only that the cell is not setup. NodeB Version: DBS3900 V2R0013C00SPC330. but on DSP UCELL.WCDMA Product Training Technical Cases Title 3G Cells Cannot Setup Keywords MTU Size Case code NodeB-006 Case type Data Configuration Case is from Huawei Support site Update Time 20130822 Product Family NodeB Product NodeB Case6 3G Cells Cannot Setup 1. RNC: BSC6900V900R013C00SPC586 2. Phenomenon Description NodeB transmission has been changed from E1 (ATM) to IP. 2) Cell Cannot Setup and subscribers cannot make call. The Transmission Topology is such that the NodeB was connected VIA Huawei ATN and in between CISCO routers were used. Cause Analysis 1) No alarms both on RNC and NodeB site. Suggestions and Summary End to end MTU Size should be considered while setting up all IP networks. The Ping is not successful and we have several timeouts. HUAWEI Confidential 36 . so we reduce to the Value 1400. the result is the same as the default size is 1500. to 1400. 5. 3) Ping between RNC and NodeB is OK (Ping size 32 bytes). Since CISCO engineers were not available to change and Confirm MTU size. Ping large packets and Ping is Successful and Cell is Set UP. the default NodeB settings for MTU size is 1500. Tx Engineer and RAN Engineer change MTU packet size and Cell is setup.WCDMA Product Training Technical Cases 3. 4. Handling Process Reduce MTU size on NodeB Ethernet port settings. Reduce MTU size on Gou Board. we then reduce the sizr e to 1400. 4) When increase Ping size from the default 32 bytes to a larger value of 1468 bytes. we also confirmed the port Attributes on the RNC. background noise Case code RNO-001 Case type KPI Case is from Huawei Support site Update Time 20130802 Product Family NodeB Product NodeB Case1 Abnormal Feeder Connection Causes KPI Deterioration 1. a site comes with low RRC/RAB success rates and high RTWP values in multiple cells.WCDMA Product Training Technical Cases RAN Optimization Cases Title Abnormal Feeder Connection Causes KPI Deterioration Keywords RTWP. Phenomenon Description After capacity expansion. The following are the versions of the NodeB and RNC on this site: NodeB version: BTS3812E-12AC-12AE-BTS3812AV100R012C00SPC200 RNC version: V900R012ENGC01SPH206 HUAWEI Confidential 37 . repeater interference. The analysis result shows that cells on this site ate configured in the 3 x 3 mode. Handling Process Initially. 1) Collect logs of RRU boards. This is because product faults produce no increase of diversity RTWP. Frequency 1 carrier carry access services and CS services. This site features layered coverage. Alarm Information NULL 3. and frequency 2 and frequency 3 HUAWEI Confidential 38 . The logs show that RTWP increase is caused by high UE transmit power. namely nine cells altogether are configured for this NodeB. Configurations of sectors and cells prove to be normal. High RTWP caused by UE transmit power rise 2) Analyze the NodeB configurations. Sectors are configured in combined subracks and each sector is configured in two combined MTRU subracks that share the same set of antennas.WCDMA Product Training Technical Cases 2. it is suspected that abnormal RTWP is caused by external interference from specific directions. In this case. KPIs are still abnormal after checking so many items. It is found that KPI changes in two abnormal cells are completely opposite after the NodeB is reset. RAB DRD may also fail and RTWP values increase. However. there is no way but to analyze the KPIs. The configurations are normal. In addition. the script shows that the drive channel configurations are also normal. it is found that known problems for site configurations are not available. After checking the RNC version. Opposite KPI changes in abnormal cells after the NodeB reset HUAWEI Confidential 39 .WCDMA Product Training Technical Cases carry HSPA services through DRD. If coverage layers are inconsistent. Sectors configured in combined subracks 3) Check the neighboring cell configurations. WCDMA Product Training Technical Cases These two abnormal cells are set up on MTRU 0 and MTRU 4. the diversity RTWP value on MTRU 4 is abnormally high High diversity RTWP values on MTRUs HUAWEI Confidential 40 . Meanwhile. The result shows that change of the diversity RTWP is completely the same as that of the main RTWP. After a thorough checking.WCDMA Product Training Technical Cases 4) Observe RTWP values of the two MTRUs together by combing them. the cause is abnormal feeder connection. Same RTWP change curves The preceding figure indicates that the diversity RTWP on MTRU 0 shares the same antenna with the main RTWP on MTRU 4. They do not share the same sector. Impacts from this kind of configuration are unpredictable but KPIs necessarily deteriorate. HUAWEI Confidential 41 . WCDMA Product Training Technical Cases 4. HUAWEI Confidential 42 . Suggestions and Summary Abnormal feeder connection usually affects services in a diversified way. When the same problem occurs again. first check the RTWP change trend if configurations and versions of NodeBs are correct and RTWP values are abnormal. It is obviously demonstrated in the RTWP change trend. their TP delay is greater than 100. For 90% of UEs that fail to establish RRC connections. In addition. 2. The uplink coverage may not reach such a long distance. uplink signals cannot be searched. Phenomenon Description The RRC connection setup success rate is low on some NodeBs at site S of country F. Cause Analysis The problem may be caused by any of the following faults: 1.WCDMA Product Training Technical Cases Title RRC Access Success Rate Decreases Due to Inconsistency Between the Uplink and Downlink Coverage of Remote Cells Keywords Super-distance coverage. Check configurations on faulty NodeBs. The distance between the UEs and NodeBs is more than 23 km. 3. UEs cannot access the network because they are too far from NodeBs. Relevant configurations are as follows: HUAWEI Confidential 43 . RRC connection setup success rate Case code RNO-002 Case type Performance Case is from Huawei Support site Update Time 20130725 Product Family RAN Product RAN Case2 RRC Access Success Rate Decreases Due to Inconsistency Between the Uplink and Downlink Coverage of Remote Cells 1. Calculate the distance between the UE and NodeB using the delay calculation formula. The MBSC version and MBTS version at the site are as follows: MBSC Version: V900R011ENGC00SPH721 MBTS Version: DBS3900 WCDMA V200R011ENGC01SPC500/700 2. Alarm Information Null 3. Based on the live-network conditions. Then. the RRC access success rate increases. 5) Narrow down the downlink coverage area by changing the pilot power and reducing coverage angles of RET antennas to achieve the same coverage area between the uplink and the downlink. Handling Process 1) Analyze the traffic statistics.WCDMA Product Training Technical Cases Transmit power: 430 dBm Pilot power: 35 dBm Uplink coverage distance: 29 km According to the preceding configurations. you can determine the distribution conditions of faulty NodeBs and locate faults quickly. According to further analysis. The RRC connection setup success rate is low due to no response during RRC setup. By analyzing TP. the downlink signal quality is good. and the coverage area of a single NodeB is large. They are located in suburbs. the inter-site distance is long. 5. The distance between 95% UEs and the NodeB is longer than 24 km. HUAWEI Confidential 44 . but uplink signals cannot be searched within this distance. causing RRC connection setup failure. uplink signals cannot be searched. uplink synchronization fails during RRC setup. The downlink coverage signals are good. reduce the pilot power of cells from 35 dBm to 32 dBm. 4. 4) Check configurations of the uplink and downlink coverage: The downlink coverage area is larger than the uplink coverage area (the downlink coverage area overlaps the uplink coverage area). Suggestions and Summary First analyze the geographical distribution of faulty NodeBs. 3) Measure UEs that fail to access the network. but uplink signals cannot be searched. Check in which step of RRC setup no response is received by analyzing signaling messages. 2) Analyze the signaling flow: Uplink synchronization fails during RRC setup. As a result. and the reason is radio frequency (RF) errors (irresponsive Uu interfaces).WCDMA Product Training Technical Cases Title Analysis for High Call Drop Rates of a Single Cell on a New Site Keywords Call drop. new site Case code RNO-003 Case type Service Case is from Huawei Support site Update Time 20130107 Product Family RAN Product RAN Case3 Analysis for High Call Drop Rates of a Single Cell on a New Site 1. the call drop rate is high. HUAWEI Confidential 45 . Phenomenon Description When the first cell (37021 W_BOKO_1) of the new site is enabled. It is 100 HUAWEI Confidential 46 . and the result shows that no over-coverage exists.WCDMA Product Training Technical Cases 2. and the call drop rate does not change. and no fault is found because they are configured by default. Fault analysis of neighboring sites: no fault is found based on the analysis of the KPIs and alarm information of the neighboring sites. Check the complementation of the neighboring configuration: Search for the neighboring configuration relationship. The subcontractors perform a drive test. The result is shown as follows: The configurations of the bidirectional neighboring cells are complete based on the above figure. Alarm Information Null 3. Check the neighboring configuration data. Analyze carefully and find that the number of soft handover is rather large. Handling Process Analyze the over-coverage: Subcontractors adjust the electrical downtilt on October 2. The incomplete neighboring configuration is eliminated. and import NASTAR to do the check. The reason of call drops is irresponsive Uu interfaces. It may be late soft handovers that cause the problem.WCDMA Product Training Technical Cases times as large as other two sites. Check the site-to-site handovers by the M2000. The positions of the two sites are as follows: HUAWEI Confidential 47 . and find that the number of handovers to neighboring cell 35151 is the largest. The counters of neighboring cells do not become worse. HUAWEI Confidential 48 .WCDMA Product Training Technical Cases Analyze the call drop reasons by the tool NPmaster. we check the PSC interference. we do not take the change into consideration when configuring the PSC of the W_Boko. so the scrambling code conflict causes interference. and no fault is found. and find that the reason is ASU_TIMEOUT during handovers to cell 35151. it is the handover failure from cell 37021 to cell 35151 that causes the problem. and find that the PSCs of cell 37023. Finally. The UMTS is a network of the same frequency. 4. pay much attention to the check of neighboring cells and scrambling codes. Therefore. and the problem is solved. so the interference is from inside. It may be the interference that causes call drops after eliminating the coverage and configuration. because they always affect the counters when there are no alarm or parameter configuration faults. Call drops occur on two users. Firstly. change the PSC of cell 35151 to 12. especially in a newly created network. Suggestions and Summary In a UMTS project. and results in the problem. Someone changed the PSC of cell 35151 and did not tell us. The core network personnel search for the configurations of the two users. W_Boko_3 and cell 35151 are all 8 based on the data configurations. WCDMA Product Training Technical Cases Title PS RAB Setup Rate degradation due to forward bandwidth congestion Keywords PS RAB degradation forward bandwidth Case code RNO-004 Case type Data Configuration Case is from Huawei Support site Update Time 20130823 Product Family RNC Product RNC Case4 PS RAB Setup Rate degradation due to forward bandwidth congestion 1. Cause Analysis No critical alarm. From operation logs we can confirm that no operation has been executed in the RNC. reported by RNC: only KPIs threshold alarms (advising that PS RAB rate is under the threshold set) and IUB Ippath intermittently alarm are reported. Phenomenon Description RNC version: V900R014ENGC00SPH532 PS RAB setup success rate dropped a lot from 12:00 It is a RAN Sharing RNC but only Primary operator is affected 2. We also can confirm that RAB PS attempt has increased gradually due to user retries HUAWEI Confidential 49 . Alarm Information KPI threshold alarm 3. issue seems to be related to the IUPS interface. The four IUPS adjnode related to the SGSN/GGSN in pool for primary operator are affected. Note: For all the graph bellow we need to take into account that customer blocked the router port for IUPS interface during some minutes . From the callfault log. the main reason for PS RAB setup failure is port forward bandwidth limited. Checking all SGSN DPC we can confirm that all of them are available. Since only Primary operator is affected. this is one RAb setup get down sunddenly at around 17:15. HUAWEI Confidential 50 . for all of them we can confirm that resource allocation failure has increased due to no enough available bandwidth.WCDMA Product Training Technical Cases after PS RAB establishment is refused. Checking PS RAB KPIs at cell level we can confirm that RAB establishment failure cause is Congestion. Also as told before not alarms related to IUPS interface or SGSN DPC is reported by RNC. which mean the admission bandwidth for the UL IUPS port was not enough. so RAB setup should be failed with reason port forward bandwidth is not enough. For the R99 service.AllocedFwd) for the four adjnode have exceeded 2000Mbps. Taking into account that Admission bandwidth = Bandwidth at the transport layer * Activation factor/100 and that for NTR service it will be--> Reserved bandwidth = GBR x Activity factor. we can confirm that these four adjnode are all bearing on the GOUc port 0:20:1 and 0:21:1and that the avaible admission bandwidth for the adjnode is 2000Mbps. 4. So the admission bandwidth for HUAWEI Confidential 51 . Handling Process The Reason for High Forward Allocated Bandwidth From the performance files. the ULGBR was 64Kbps. From the configuration we can confirm that: TRM factor for PS interactive service was 40%.ANI. the sum of alloced forward bandwith (OS.IP. When the problem occurred. most of the PS service was interactive type.WCDMA Product Training Technical Cases From RNC configuration. it can be found there was an increase of active users and the PS throughput.6kpbs UL BW.6= 2048Mbps.6kbps UL bandwidth for IUPS. which mean that the service was increasing for this RNC. For the four ADJNODE. Suppose there was 10000 HSUPA user and 80000 R99 users. The Reason for High Amount of R99 Active Users From the performance counters for one week.000 active users when the problem occurred. HUAWEI Confidential 52 . (Summer time has just started and RNC cover an area near the cost). the mean HSUPA UE numbers was not large compared with the total IUPS active users. Comparing the data with Saturday of the week before. Most of the service was UL R99 service. So we can conclude that the high number of active users lead the forward bandwidth congestion on the IUPS port. we can see that the Saturday was the busiest time for this RNC. From RNC performance files.4 =25. as each R99 user would occupy 25.WCDMA Product Training Technical Cases one R99 active user would be 64*0. there were more than 90. the total IUPS bandwidth would be 80000*25. it is needed to adjust the activity factor to prevent PS service admission failures. When EFD is enabled. Also we can confirm that the EFD (Enhanced Fast Dormancy) is enabled for this RNC. that’s the reason for so many R99 active users on the IUPS IPPATH. would always try to reconnect the network when rejected. In this case the recommended value of the IUPS activity factor is 10%. So the increase of users during the last days finally leads the PS RAB setup failures. we need to be careful to adjust all related parameter for HUAWEI Confidential 53 . the admittance bandwidth on the IUPS ADJNODE sharply reduced and the problem recovered. As the UEs. Since current value of IUPS activity factor is 40%. the total RAB attempts increased a lot. we suggest customer to decrease activity factor to 10%. the used admission bandwidth for the IUPS was already almost reaching the upper limit of 2000Mbps. especially the smart phone. After the change. Suggestions and Summary When a feature is enabled.WCDMA Product Training Technical Cases Before this increase. But the throughput of the RNC was not affected much. so the EFD UE capable would change to CELL_PCH and URA_PCH status rather than release the connection. and the RAB setup rate dropped sharply. 5. HUAWEI Confidential 54 .WCDMA Product Training Technical Cases the new scenario. Summer time. special event). When it is well known that traffic condition in an RNC will change (As during Chrisman’s eve. it is recommended to health check RNC to avoid service degradation due to congestion. Phenomenon Description Customer complained that under RNC X there was a PS performance degradation. Graph below show us PS performance degradation for RNC X.WCDMA Product Training Technical Cases Title PS performance degradation under RNC 'X' Keywords PS degradation Case code RNO-005 Case type Service Case is from Huawei Support site Update Time 20130503 Product Family RNC Product RNC Case5 PS performance degradation under RNC 'X' 1. HUAWEI Confidential 55 . 2. Cause Analysis 1.WCDMA Product Training Technical Cases 2.RAB. Alarm Information Null 3. it is clearly showed that most of RAB assignment HUAWEI Confidential 56 . From the RNC PCHR logs .FailEstabPS. we can find the most contribute of PS RAB ESTAB failed is recorded on VS.TNL Which means the problem was cause on user plan. Based on the RNC performance data . 254. According the RNC debug logs.254 and 10. this error code means PS side related ANI peer IP address cannot find in the current RNC IUPS interface IPPATHs. This ANI peer IP address is: 10. we found there were many “SIG_ERR_TRMP_062C” error code was recorded.221.192.WCDMA Product Training Technical Cases REQ fault was recorded on RNCAP L2CFG FAIL. And all of the RNCAP L2CFG FAIL reason is caused by “IU Transport Connection Failed to Establish”. 3. HUAWEI Confidential 57 .47.195. 254).47.WCDMA Product Training Technical Cases 4.47.192.254 and 10.221.254 and 10. HUAWEI Confidential 58 . Solution: We need to add the IPPATH for missing IP Address (10. the KPI recovers. Handling Process By checking this RNC IUPS interface configuration file. we cannot find this ANI peer IP address is: 10.195.221.192.195.254 were in the current IUPS interface IPPATH. After the execution. HUAWEI Confidential 59 . Suggestions and Summary Please make sure that configuration between RNC and core side is synchronous. We should configure all IPPATH's IP at RNC side which configured in core side. Please make sure and coordinate this with core team directly.WCDMA Product Training Technical Cases 5. Especially user plane configuration in this case. Congestion on the transmission to RNC port 0-24-0. there are lots of RAB failure caused by DL and UL Iub congestion.WCDMA Product Training Technical Cases Title Low RAB Success in RNC Keywords Low RAB Success at RNC cause DL/UL Iub bandwidth congestion Case code RNO-006 Case type Data Configuration Case is from Huawei Support site Update Time 20130426 Product Family RNC Product RNC Case6 Low RAB Success in RNC 1. BSC 6900 UMTS version: V900R013ENGC00SPH552. 2. Cause Analysis Iub bandwidth is congestion both in UL and DL. Phenomenon Description We found low RAB Success in Speech and Packet after ATM to IP Migration. Handling Process Action: Temporary modify the TRMFACTOR. Alarm Information Low RAB Success in RNC 3. HUAWEI Confidential 60 . 4. HDVOICEDL=70. please refer to the graph below. PSSTRMDL=10. CSSTRMDL=10. HUSRBUL=50. HUCONVUL=10. HUSRBUL=50. HUSIPUL=15. HDBKGDL=10. HUCONVUL=70. PSINTERDL=10. HDSRBDL=50. it is better return the TRMFACTOR back to keep old parameter. MBMSCCHDL=10. HUAWEI Confidential 61 . CSCONVUL=10. HUINTERUL=10. CSSTRMUL=10. SIPUL=15. HDSTRMDL=10. HDCONVDL=70. SRBDL=15. REMARK="IuB_60". GENCCHUL=70. PSSTRMDL=10. VOICEDL=70. VOICEUL=70. HDSIPDL=15. PSBKGDL=10. MOD TRMFACTOR: FTI=31. PSINTERUL=60. PSCONVUL=70. HDSIPDL=15. PSINTERDL=60. HUSTRMUL=10. SIPUL=15. CSSTRMUL=10. VOICEUL=70. SRBUL=15. PSSTRMUL=10. CSCONVDL=10. HDSRBDL=50. MBMSCCHDL=10.WCDMA Product Training Technical Cases Remark: Temporary solution. HUBKGUL=10. HDCONVDL=70. HUVOICEUL=10. PSCONVDL=70. SRBUL=15. GENCCHUL=70. CSCONVUL=10. VOICEDL=70. PSCONVDL=70. EFACHDL=20. PSBKGUL=10. PSBKGDL=60. change the factor to decrease the speed of the access. PSINTERUL=10. GENCCHDL=70. MOD TRMFACTOR: FTI=20. SIPDL=15. EFACHDL=20. in order not to generate the RAB Att Fail when few of transmission can be used. HDBKGDL=60. CSSTRMDL=10. HUBKGUL=10. HDVOICEDL=10. HUINTERUL=10. As the issue is caused by IU-b congestion upon solved. REMARK="IuB_IP". SRBDL=15. PSSTRMUL=10. SIPDL=15. CSCONVDL=10. HDSTRMDL=10. PSBKGUL=60. The KPI for the Iub congest has been recovered after modify TRMFACTOR. HDINTERDL=10. HUVOICEUL=70. PSCONVUL=70. HUSIPUL=15. GENCCHDL=70. HDINTERDL=60. HUSTRMUL=10. Temporary Solution: Temporary modify the TRMFACTOR 2.WCDMA Product Training Technical Cases 5. Suggestions and Summary 1. Solution: Expand the transmission bandwidth HUAWEI Confidential 62 .
Report "UMTS Product Training Technical Cases.pdf"