Вы находитесь на странице: 1из 64

WCDMA Product Training Technical Cases

WCDMA 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

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

WCDMA Product Training Technical Cases

4. Handling Process
Increase the flow control threshold for SMS services.
Check alarm and no alarm were found.
Check configuration data, no inconsistency.
Reset RNC and Node B test, status is still the same.
Compare configuration with other RNCs and found some mismatch on the
TRMMAP setting. Use command MOD TRMMAP, change setting and reset
RNC.
ADD TRMMAP: TMI=101, ITFT=IUB, TRANST=IP, VOICEPRIPATH=EF,
PSINTHGHPRIPATH=AF23, HDINTHGHPRIPATH=AF13,
HUINTHGHPRIPATH=AF13.

Problem Solve.

5. Suggestions and Summary


PS cannot make service is because of Tx service mapping is not correct. Which
means in ADD TRMMAP, PS INT is AF23 and HS INT is AF13 but is not configure in
ADD IPPATH for IUB path. Only the CS service can make call because PATHT=EF
already configured in iub path. So PS service should can make service after add
AF23 and AF13 in IUB path.

HUAWEI Confidential

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. Phenomenon Description
J country C network, there is one RNC paging success rate drop from 90% to 75% at
19th Feb., paging success rate of the CN is normally and steadily.

2. Alarm Information
Null

3. Cause Analysis
1)
2)
3)
4)
5)

Iu some RNC configuration change cause the paging SR decreased;


PCH has congestion;
Paging message discard due to the flow control;
2G and 3G has the same LAC area;
Wrong paging message send from the CN.

4. Handling Process
1)
2)

Paging SR was dropped at the 19 Feb, check the RNC operation log, there is no
any LAC/RAC modification.
Check the RNC alarm log, there is no flow control alarm with the paging discard;
and the counter VS.Paging.FC.Disc.Num.CPUS value is 0, so there is no any
paging message discard due to the flow control.

HUAWEI Confidential

WCDMA Product Training Technical Cases

3)

Check
another
two
counter
VS.RANAP.PsPaging.Loss
and
VS.RANAP.CsPaging.Loss value is also 0, so we confirm there is no paging
discard at the RNC side.

4)

Check the counter VS.RRC.Paging1.Loss.PCHCong.Cell, there is almost no


paging discard due to the PCH congestion.

5)

Compare the LAC configuration of the 2G and 3G, there is no same LAC
configured at the BSC and RNC.
Analysis the IU trace, filter the paging message, we find this RNC receive paging
message from 7 LAC area, but this RNC only configure 6 LAC area, paging
message from this abnormal LAC is 15% of total.
Discuss with MSC engineer and confirm the abnormal LAC belong to the 2G,

6)

7)

HUAWEI Confidential

WCDMA Product Training Technical Cases

MSC wrong configure at 19th Feb. after MSC modify it, RNC paging SR become
normally.

5. Suggestions and Summary


KPI decrease suddenlycheck the operation of the network firstly. Exclude RNC and
Cell PCH congestion possibility of doubt, Iu trace is good way to analysis.

HUAWEI Confidential

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

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

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

WCDMA Product Training Technical Cases


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=1;
MOD IPPATH:ANI=238,PATHID=2,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=1;
MOD IPPATH:ANI=238,PATHID=3,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=1;
MOD IPPATH:ANI=238,PATHID=4,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=1;
MOD IPPATH:ANI=26,PATHID=1,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=2;
MOD IPPATH:ANI=26,PATHID=2,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=2;
MOD IPPATH:ANI=26,PATHID=3,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=2;
MOD IPPATH:ANI=26,PATHID=4,ITFT=IUB,CARRYFLAG=IPLGCPORT,LPNSN=20,LPN=2;

From the same counter as shown in the chart below, we can see that the IUB
Bandwidth are normal after activating the IP Overbooking by assigning one
IPLOGICPORT to one NodeB.

5. Suggestions and Summary


More information regarding the impact and parameter settings should be provided in
details in the guide. Also, in the guide should suggest which performance counters to
monitor before and after the activation.

HUAWEI Confidential

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. Phenomenon Description
When a 2G site added, PS traffic decreased sharply.

2. Alarm Information
ALM-21346 IP Connectivity Check Failure
ALM-21347 IP Address Conflict

3. Cause Analysis
ARP check failure lead to this issue

4. Handling Process
1. When added a 2G site, the alarm IP Connectivity Check Failure and IP Address
Conflict appeared.

2. And the PS traffic was also affected.

HUAWEI Confidential

10

WCDMA Product Training Technical Cases

3. All the sites connect to slot 18 of Subrack 0, the next hop address is 10.128.16.73.

4. In slot 18 of Subrack 0, the active link activated ARP detection.


STR IPCHK:SRN=0, SN=18, CHKN=0, CHKTYPE=ARP, CARRYT=ETHPORT, PN=0,
MODE=CHECK_ON_PRIMARY_PORT, PEERIP="10.128.16.73",
WHETHERAFFECTSWAP=NO, ARPTIMEOUT=2, ARPRETRY=2;
5. The ARP detection between BSC01 and gateway failed and the IP Connectivity
Check Failure alarm was reported. This means the link between RNC and
gateway is disconnecting frequently.

6. RNC sent ARP request to router (10.128.16.73), and RNC didnt receive ARP
response, so it lead to ARP check failure. When ARP check failure, RNC will set
the next-hop address unreachable. So RNC will not sent data to the next hop
address. So BSC1 didnt send data to the router (10.128.16.73) until ARP check
success again.
7. At the problem time, BSC1 shielded the rout IP (10.128.16.73), and then the sent
HUAWEI Confidential

11

WCDMA Product Training Technical Cases

and received traffic had a sharply decrease during the ARP check failure of IUB
interface.

8. Also the PS throughput decreased because of the IUB traffic decrease.

5. Suggestions and Summary


When IP address conflict, the router didnt response the ARP request from RNC, so
the ARP check failure and the alarm IP Connectivity Check Failure appeared , it
lead to RNC automatically shields the next-hop IP address (10.128.16.73). So PS
was affected finally.

HUAWEI Confidential

12

WCDMA Product Training Technical Cases

Title

Cell setup failure at two 3G sites due to DPUe hardware fault

Keywords

Cell Setup 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. Phenomenon Description
All the cells of two NodeBs failed to setup at almost the same time. Both sites are on
same SPUb board which has no other sites on this RNC. The reason of the setup
failure was FP synchronization failed.

There are 8*E1s configured for both sites, all the E1 ports are UP on both NodeBs
except for one E1 port on one NodeB.

2. Alarm Information
The following alarms were reporting on both sites
Critical
22214 NodeB Unavailable
Critical
22202 UMTS Cell Unavailable
HUAWEI Confidential

13

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.
Major
21287 SDH/SONET Tributary Alarm Indication Signal

3. Cause Analysis
UMTS cell common channel setup failed with cause code FP synchronization failed.
RNC version: V900R013ENGC00SPH556
NodeB version: V200R013C00SPC521
1. Isolated the transmission fault as the first step because 95% of FP
synchronization failures were related to the transmission issues.
2. It was found that there were E1 transmission mapping issues with both sites.
However, still encountered the same cell setup issue after resolved the
transmission issue.
3. Both sites are binding to the same 0:8 SPUb board which has no other sites;
however the issue persisted after performed reset and swap of the SPUb card, it
is very unlikely to have a hardware fault on both SPUb boards at the same time.
4. There are two DPUe boards (0:15 and 0:16) at subrack 0, they are working on
load sharing mode.
5. Checked the configuration and found that the 0:15 DPUe board is binding to 0:8
MPU subsystems. It means 0:15 DPUe and these two NodeBs are binding to the
same physical 0:8 SPU board. RNC will give priority to use 0:15 DPUe when
setting up the cells of these two problematic NodeBs. However, when checking
the usage of 0:15 DPUe via commands DSP UDSPRESOURCE and DSP
DSPUSAGE, the 0:15 DPUe usage was Zero and there was no user attached to
this DPUe board.
6. 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, we confirmed
there is a hardware issue on DPUe card that locates on Subrack 0 Slot 15.
7. This issue was due to the DPUe hardware faulty which caused the incoming
packets being discarded by the underlying process of DPUe. And there is no
alarm or preventive mechanism in the current RNC software version
(V900R013ENGC00SPH556) to detect the incoming packet loss of DPUe board.
HUAWEI Confidential

14

WCDMA Product Training Technical Cases

4. Handling Process
1. Checked the status of AAL2PATH, NCP and CCP which are all normal.
2. Checked the Operation log to confirm there was no changes have been done on
both sites.
3. Checked the alarm list and log, the following alarms were reporting on both sites.
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.
Major

21287

SDH/SONET Tributary Alarm Indication Signal

4. Fixed the transmission mapping issue for one side by performed the loopback
test.
5. Confirmed there are no transmission quality fault by performing the ATM QoS
tests.
6. Checked the RNC configurations
These two NodeBs are binding to the same 0:8 SPUb board.

The issue persisted after performed reset and swap of the 0:8 SPUb card,
therefore we isolated the SPUb issue. Furthermore, the 0:15 DPUe board is
binding to 0:8 MPU subsystems at the same cabinet 0.

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.
7. Checked the usages of 0:15 DPUe and 0:14 DPUe via command DSP
UDSPRESOURCE and DSP DSPUSAGE, the usage of 0:15 DPUe was Zero and
there was no user attached to this DPUe board.

HUAWEI Confidential

15

WCDMA Product Training Technical Cases

8. From the PFM log, FP synchronize failures were observed at 0:15 DPUe board.

9. Also from the PFM log, the usage of 0:15 DPUe board was zero at the time the
problem occurred.

HUAWEI Confidential

16

WCDMA Product Training Technical Cases

5. 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, we recommend customer replace the faulty DPUe board at
subrack 0 slot 15 on cabinet 0 of this RNC.

HUAWEI Confidential

17

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. Phenomenon Description
A lot of subscriber complained that they could not access internet via 3G service at
one RNC of V network, whereas, 3G voice service was normal at that time. The
problem happened in period: from 4/11/2013 10:21:33 PM to 4/12/2013 6:45:40 AM.
Investigation result showed that control plane of Iu-PS interruption. Customer
complained that Huawei RNC worked unstably and bad quality sometimes.

2. Alarm Information
At complained period, we found there were many alarm related to Control plane of
Iu-PS: "M3UA Link Fault", "M3UA Destination Entity Route Unavailable", "M3UA
Destination Entity Inaccessible" and "SCCP Subsystem Prohibited".
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, we saw that around 10 minutes, these alarms were cleared normally
and happened again. Please check alarm log for more details.

3. Cause Analysis
1. From the CFGMML we found that there is only one M3LNK configured for control
HUAWEI Confidential

18

WCDMA Product Training Technical Cases

plane of IuPS.
ADD M3LNK:SIGLKSX=0, SIGLNKID=0, SRN=0, SN=4, SSN=1, SCTPLNKN=4,
PRIORITY=0, LNKREDFLAG=M3UA_MASTER_MOD, NAME="M3LK1_PS";

2. From the alarm log, it can be found that the problem occurred at 22:21. There
was no alarm and operation which could cause the alarm at the time.
3. After that, every 10 minutes, the M3UA Link fault would be recovered and then
reported again, the reason was that when RNC detect the M3LNK failure, it will
release the SCTP link and reestablish again, so the M3UA link alarm would be
recovered and then reported
4. And the SCTP link which bearing the M3UA link was always fine, which meant
there was no fault on SCTP link and the transmission.
5. From debug log analysis, at the complained period, when RNC sent ASP Active
message to SGSN, SGSN send back to RNC an error message with error code 6,
which made the M3UA link could not be activated. It proved that the probelm
caused by SGSN not RNC.

4. Handling Process
1. After Huawei sent report analysis to customer to request SGSN Vendor doing
some analysis.
They said that one signalling board of SGSN was abnormal at that period.
2. Rectification:
Because there is only one M3LNK configured for Control plane, it was not
followed Huawei rule, and it may has risk of one signalling processing board
failed. It highly recommends that at least two M3LNK configured for Iu-CS/Iu-PS
interface for safe reason and load sharing, and customer added one more link as
our suggestion.
Manually activate M3LNK by command: ACT M3LNK.

5. Suggestions and Summary


1. In engineering period, we should strictly obey configuration rule to configure

HUAWEI Confidential

19

WCDMA Product Training Technical Cases

important interfaces such as Iu-PS, Iu-CS, Iur to ensure safety and load sharing.
2. When problem happened, we should deeply analysis alarm log, operation log,
debug log to find the root cause timely. Please check the problem report analysis
attached to study this case.

HUAWEI Confidential

20

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, 100%, 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. Phenomenon Description
A certain carrier reflects a problem: After IPPM is activated, the command output
shows that DSCIP is modified. Engineers observe the traffic measurement counters
VS.IPPM.Forword.DropMeans and VS.IPPM.Forword.Peak.DropRates. Both reach
100%. The two counters record the lost IPPM packets. 100% indicates that all IPPM
measurement packets are lost. The NodeB flow control may be triggered, which
affects the performance of services on the NodeB.

2. Alarm Information
Null

3. Cause Analysis
1) Traffic statistics analysis
The original traffic statistics show that the 100% packet loss rate is frequently
seen. The M2000 traffic display cause is ruled out.

HUAWEI Confidential

21

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. In an IPPM detection, one end sends an FM message
periodically. The peer end returns a BR reply after receiving the FM message.
The transmit end determines delay, vibration, and packet loss on the transmission
path according to the BR reply sent by the receive end.
3) Generally, the RNC counts transmitted and received IPPM packets by referring to
a four-element group: source IP address, target IP address, protocol type, and
DSCP. When IPPM packet loss rate reaches 100%, one of the four elements may
be faulty for most cases.
4) Packet capturing analysis
We capture packets on both the RNC and NodeB and analyze the result. FM ID is
0x2000 on the RNC, and the corresponding DSCP is 0x2e, as shown in the
following figure. This is the transmit end.

On the NodeB, DSCP is zero for the same packet of FM ID 0x2000. The packet

HUAWEI Confidential

22

WCDMA Product Training Technical Cases

from the RNC of DSCP = 0x2e has been changed to zero on the NodeB. It proves
that an intermediate transmission device modifies the packet DSCP value,
resulting in a 100% IPPM packet loss rate.

4. Handling Process
Disable the DSCP modification function of the intermediate switch. The problem is
resolved.

HUAWEI Confidential

23

WCDMA Product Training Technical Cases

Title

Transmission interference vibration lead to Single-Site Clock


Unlocked

Keywords

Reference clock source abnormality alarm, fast tracking, 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. Phenomenon Description
A certain office reported that a single-site clock cannot be locked. The site version is
DBS3900 WCDMA V200R011C00SPC300. The site services are running properly.

2. Alarm Information
Abnormal reference clock source is reported. The cause is that the clock source is lost
or deviates greatly. The clock state is fast tracking and cannot be locked.

3. Handling Process
1)

The clock source or transmission link may be down. We check other sites under
the same RNC. Their clock sources can be locked and obtain correct clock
signals. The clock source cause is ruled out. Then, we run DSP E1T1. The
transmission link is stable. After we change another E1, the clock still cannot be
locked.

2)

The reference source frequency may differ greatly from the local crystal oscillator
frequency. A clock test finds that the frequency deviation stabilizes at 34 Hz.
The frequency deviation drops to 0 Hz for 44 times during 3 hours. This an
irregular vibration caused by transmission interference. The total frequency
deviation is over +3.7367 Hz (obtained by curve fitting upon clock test values).

HUAWEI Confidential

24

WCDMA Product Training Technical Cases

3)

The previous analysis shows that the transmission interference is the cause of
this problem. We adjust the center DA value to lock the clock signal.
The calculation formula: New center DA = original center DA (65535/40 Hz) x
frequency deviation
LST DARECORD: SN = 7. The current DA is 28460.
New center DA = current DA 1638.4 x frequency deviation = 28460 3.7376 x
1638.4 = 22336.
We run the following commands to set center DA to 22336.

MOD CENTERDA: CN=0, SRN=0, SN=7, DA=22336


MOD CENTERDA: CN=0, SRN=0, SN=6, DA=22336
The clock can be locked. The problem is resolved.

4. Suggestions and Summary


1) The primary and secondary WMPTs should have different center DAs due to the
difference between their crystal oscillator frequencies. 2. Unless you have
confirmed that the clock has drifted and the center DA needs to be modified, do
not use the MOD CENTERDA command.

HUAWEI Confidential

25

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, M2000, ARP, 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, a NodeB uses IP addresses for transmission
and USB flash drives for commissioning. After the transmission test succeeds, the
service IP address of the NodeB can be pinged from the RNC, whereas the logical
OM IP address of the NodeB cannot be pinged from the M2000.
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. IP6 is the IP address of the NodeB
service gateway, which is in VLAN 21. IP4 is the logical IP address of the NodeB. IP7
is the IP address of the NodeB OM gateway, which is in VLAN 31. IP4 communicates
with other NEs through IP3 (OM port IP address). In this networking mode, ARP
proxy is enabled on the IP port.

HUAWEI Confidential

26

WCDMA Product Training Technical Cases

The following table lists the planned IP addresses of this NodeB.


NodeB Service IP

NodeB Service NodeB OM


Gateway to RNC Logical IP

NodeB OM Port NodeB OM


IP
Gateway

10.237.163.230

10.237.163.229

10.237.163.234

10.237.163.235

10.237.163.233

2) Alarm Information
Null

3) Handling Process
1)

Start

the

Configuration

Management

Express

(CME)

to

check

data

configurations, including IP address configuration, IP route configuration, OMCH


configuration, ARP proxy configuration.
No faults are found.
2)

Ping the NodeB OM gateway (10.237.163.233) from the M2000.


The ping operation succeeds.
Ping the OM port IP address (10.237.163.234) of the NodeB from the M2000.
The ping operation succeeds.
Ping the logical OM IP address (10.237.163.235) of the NodeB from the M2000.
The ping operation fails. According to the fault phenomenon, the ARP proxy of
the NodeB may be disabled

3)

Use the OM port IP address (10.237.163.234) of the NodeB to create a NodeB


on the M2000. Then, the NodeB can be remotely maintained through the M2000.

4)

Run an MML command to check the current data configurations of the NodeB.
The ARP proxy of the NodeB is enabled and its IP address configurations are
correct.

5)

Ping the NodeB OM gateway (10.237.163.233) from the logical OM IP address


(10.237.163.235) of the NodeB, but the operation fails. However, pinging the
NodeB OM gateway (10.237.163.233) from the NodeB OM port IP address
(10.237.163.234) succeeds. This indicates that OM VLAN settings on
the transmission device are correct. The customer network segment settings
may be incorrect.
HUAWEI Confidential

27

WCDMA Product Training Technical Cases

6)

Check the configurations on thetransmission device.


The mask settings of the OM gateway IP address are incorrect. The mask is set
to /30 instead of /29. As a result, the OM gateway IP address and the logical OM
IP address are not in the same network segment. Therefore, the M2000 fails to
maintain the NodeB through the logical OM IP address.

7)

Instruct the customer to modify the mask setting.


The mask settings of the OM gateway IP address on the transmission device are
incorrect.

4) Suggestions and Summary


Configure the service IP address on /30 network segment and the OM IP address on
/29 network segment. This fault occurs due to incorrect configurations by the
customer and inflexible network design on this part. At present, 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. This facilitates customers' configurations on devices and reduces
the probability of configuration errors.

HUAWEI Confidential

28

WCDMA Product Training Technical Cases

Title

Reversely Connected Antennas Lead to Abnormal Cell KPIs

Keywords

Reversely connected antennas, RTWP, 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. Phenomenon Description
The access success rate is low in a RAN12.0 macro cell 10111 and its KPIs must be
optimized.

2. Alarm Information
Null

3. 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. When the
system is congested, the call admission control (CAC) or intelligent access control
(IAC) is triggered.
The congestion is determined based on the system resources usage, including the
downlink power, downlink orthogonal variable spreading factor (OVSF) codes, uplink
and downlink CE, Iub bandwidth, and uplink RTWP.
Through the traffic analysis in cell 10111, the traffic volume during the period when
the problem occurs is low and does not reach the threshold for triggering load control.
Only the RTWP may not be linear incremental with the traffic volume. The
interference can improve the uplink RTWP and decrease uplink loads, resulting in
congestion.

HUAWEI Confidential

29

WCDMA Product Training Technical Cases

4. 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. Interference
check shows that internal or external interference may exist.
10. Internal interference check: The internal interference may be caused by improper
hardware installation or multi-frequency intermodulation, resulting in inconsistent
RTWP changes in the main and diversity channels. According to the check result,
the abnormal RTWP is not caused by internal interference.
11. External interference check: All sectors in a certain direction of NodeBs will be
affected due to external interference. RTWP analysis of the neighboring NodeBs
shows that no external interference exists.
12. Reversely connected antennas: The abnormal RTWP may be caused by
reversely connected antennas, also called cross pair connection. When the
RTWP in a cell rises, the RTWP in the cell with reversely connected antennas is
also high. That is because the uplink signal of sector A is received by RF units
connected to sector A when antennas are reversely connected. In this case, the
uplink RTWP of a cell is shared by two cells.

13. The RTWP tracing of the problematic NodeBs shows that the RTWP rises in cells
10111 and 10112 simultaneously and is normal in cell 10113. In the period that
the problem occurs, the traffic volume is high only in cell 10112. Therefore, the
HUAWEI Confidential

30

WCDMA Product Training Technical Cases

high load in cell 10111 is caused by reversely connected antennas with cell
10222.

Reconnect antennas on the RF port in the suspected cell and then check the RTWP in
this cell. The RTWP and the access success rate in cell 10111 become normal.

5. Suggestions and Summary


If antennas are reversely connected during hardware installation, the system does
not generate alarms. In this case, the involved two cells with reversely connected
antennas will share uplink loads, which decreases the cell capacity. This problem
may not occur at the site verification stage due to low traffic volume, but the cell KPI is
affected when the traffic volume rises. When analyzing this problem, you are advised
to check the RTWP in two neighboring cells and observe the RTWP again after
reconnecting antennas.

HUAWEI Confidential

31

WCDMA Product Training Technical Cases

Title

CPU Overload Leads to Abnormal NodeB Reset

Keywords

CPU overload, 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. Phenomenon Description
On site La_Montagne, abnormal NodeB reset frequently occurs during heavy traffic
hours. Besides, the CPU load excceeds80%, and the CPU Overload alarm is
generated.

2. Alarm Information
CPU Overload alarm

3. Handling Process
1)

Analyze the traffic volume on this site.


The result shows that this site is located on the top of a building on a higher
ground. Therefore, this site provides a wider coverage for a large number of
users. However, from the perspective of the number of RRC connection setups
or RAB setups, this site does not sit at the highest place of the entire area.
Therefore, to measure NodeB traffic comprehensively, both access and other
factors should be considered.
Check related materials and perform consultation.
The result proves that traffic measurement can be complete only by taking
access, handover, and reconfiguration factors into consideration rather than only
access. The number of attempts per second that reflects the actual traffic on this
site can be calculated using the formula ATTACH = RLM.AttRLSetupIub +
RLM.AttRLAddIub + VS.IUB.AttRLRecfg x 2in the attachment.
HUAWEI Confidential

32

WCDMA Product Training Technical Cases

For example:
Site: La_Montagne
The CHR analysis result is as follows:
According to formula ATTACH = RLM.AttRLSetupIub+RLM.AttRLAddIub +
VS.IUB.AttRLRecfg x 2 = 42540, the attempt times is 47.26 per second, which is
close to the upper threshold of hardware processing capability (50 times per
second).
On site Midstream_Estates, the number of RAB setups is higher than those on
site La_Montagne.
The CHR analysis result is as follows:
According to formula ATTACH = RLM.AttRLSetupIub + RLM.AttRLAddIub +
VS.IUB.AttRLRecfg x 2 = 12698, the attempt times is 14.11 per second, which is
far lower than that on site La_Montagne. 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%.
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. However, the problem persists
after the WMPT board is replaced.

3)

Analyze the reason


After this analysis, it is found that the flow control mechanism over the Iub
interface fails when the CPU load is extremely high. In this case, the NodeB
continues to receive data from the RNC and sends it to the WMPT board. No
spare CPU load is available for processing more data because the CPU of the
WMPT board is overloaded. Consequently, the protection mechanism is
triggered and the NodeB resets unexpectedly. This problem is caused by limited
hardware processing capability. In DBS3900- BTS3900 V200R011C00SPC320,
this problem has been resolved.

4)

Advice

operators

to

upgrade

the

HUAWEI Confidential

NodeB

to

version

DBS3900

33

WCDMA Product Training Technical Cases

- BTS3900 V200R011C00SPC320, and deploy a new site around site


La_Montagne to relieve its traffic load. Currently, this La_Montagne site runs
normally.

4. Suggestions and Summary


A problem may be caused by several reasons. Therefore, analyze a problem from
different dimensions one by one.

HUAWEI Confidential

34

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. Phenomenon Description
NodeB transmission has been changed from E1 (ATM) to IP. The Cell cannot setup
and services cannot be launched after cutover of the site to fully IP.

NodeB Version: DBS3900 V2R0013C00SPC330.

RNC: BSC6900V900R013C00SPC586

2. Alarm Information
There is NO alarm, but on DSP UCELL- the feedback is only that the cell is not setup.

HUAWEI Confidential

35

WCDMA Product Training Technical Cases

3. Cause Analysis
1)

No alarms both on RNC and NodeB site.

2)

Cell Cannot Setup and subscribers cannot make call.

3)

Ping between RNC and NodeB is OK (Ping size 32 bytes).

4)

When increase Ping size from the default 32 bytes to a larger value of 1468
bytes.

The Ping is not successful and we have several timeouts.

4. Handling Process
Reduce MTU size on NodeB Ethernet port settings, the default NodeB settings for
MTU size is 1500, so we reduce to the Value 1400.
Reduce MTU size on Gou Board, we also confirmed the port Attributes on the RNC,
the result is the same as the default size is 1500, we then reduce the sizr e to 1400.
Ping large packets and Ping is Successful and Cell is Set UP.
The Transmission Topology is such that the NodeB was connected VIA Huawei ATN
and in between CISCO routers were used.
Since CISCO engineers were not available to change and Confirm MTU size.
Tx Engineer and RAN Engineer change MTU packet size and Cell is setup, to 1400.

5. Suggestions and Summary


End to end MTU Size should be considered while setting up all IP networks.

HUAWEI Confidential

36

WCDMA Product Training Technical Cases

RAN Optimization Cases


Title

Abnormal Feeder Connection Causes KPI Deterioration

Keywords

RTWP, repeater interference, 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. Phenomenon Description
After capacity expansion, a site comes with low RRC/RAB success rates and high
RTWP values in multiple cells.

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

WCDMA Product Training Technical Cases

2. Alarm Information
NULL

3. Handling Process
Initially, it is suspected that abnormal RTWP is caused by external interference from
specific directions. This is because product faults produce no increase of diversity
RTWP.
1) Collect logs of RRU boards.
The logs show that RTWP increase is caused by high UE transmit power.

High RTWP caused by UE transmit power rise

2) Analyze the NodeB configurations.


The analysis result shows that cells on this site ate configured in the 3 x 3 mode,
namely nine cells altogether are configured for this NodeB. Sectors are
configured in combined subracks and each sector is configured in two combined
MTRU subracks that share the same set of antennas. Configurations of sectors
and cells prove to be normal. This site features layered coverage. Frequency 1
carrier carry access services and CS services, and frequency 2 and frequency 3

HUAWEI Confidential

38

WCDMA Product Training Technical Cases

carry HSPA services through DRD.

Sectors configured in combined subracks

3) Check the neighboring cell configurations.


If coverage layers are inconsistent, RAB DRD may also fail and RTWP values
increase. The configurations are normal. In addition, the script shows that the
drive channel configurations are also normal. After checking the RNC version, it is
found that known problems for site configurations are not available. However,
KPIs are still abnormal after checking so many items. In this case, there is no way
but to analyze the KPIs. It is found that KPI changes in two abnormal cells are
completely opposite after the NodeB is reset.

Opposite KPI changes in abnormal cells after the NodeB reset

HUAWEI Confidential

39

WCDMA Product Training Technical Cases

These two abnormal cells are set up on MTRU 0 and MTRU 4. Meanwhile, the
diversity RTWP value on MTRU 4 is abnormally high

High diversity RTWP values on MTRUs

HUAWEI Confidential

40

WCDMA Product Training Technical Cases

4) Observe RTWP values of the two MTRUs together by combing them.


The result shows that change of the diversity RTWP is completely the same as
that of the main RTWP.

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. After a thorough checking, the cause is abnormal feeder
connection.
HUAWEI Confidential

41

WCDMA Product Training Technical Cases

4. Suggestions and Summary


Abnormal feeder connection usually affects services in a diversified way. It is
obviously demonstrated in the RTWP change trend. 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.

HUAWEI Confidential

42

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, 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. Phenomenon Description
The RRC connection setup success rate is low on some NodeBs at site S of country F.
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. Cause Analysis
The problem may be caused by any of the following faults:
1.

For 90% of UEs that fail to establish RRC connections, their TP delay is greater
than 100. Calculate the distance between the UE and NodeB using the delay
calculation formula. The distance between the UEs and NodeBs is more than 23
km.

2.

UEs cannot access the network because they are too far from NodeBs. In
addition, uplink signals cannot be searched. The uplink coverage may not reach
such a long distance.

3.

Check configurations on faulty NodeBs. Relevant configurations are as follows:


HUAWEI Confidential

43

WCDMA Product Training Technical Cases

Transmit power: 430 dBm

Pilot power: 35 dBm

Uplink coverage distance: 29 km

According to the preceding configurations, the downlink signal quality is good, but
uplink signals cannot be searched within this distance.

4. Handling Process
1) Analyze the traffic statistics.
The RRC connection setup success rate is low due to no response during RRC
setup. 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.
According to further analysis, uplink signals cannot be searched.
3) Measure UEs that fail to access the network.
The distance between 95% UEs and the NodeB is longer than 24 km. The
downlink coverage signals are good, but uplink signals cannot be searched.
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). As a result, uplink
synchronization fails during RRC setup, causing RRC connection setup failure.
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. Based on the live-network conditions,
reduce the pilot power of cells from 35 dBm to 32 dBm. Then, the RRC access
success rate increases.

5. Suggestions and Summary


First analyze the geographical distribution of faulty NodeBs. They are located in
suburbs, the inter-site distance is long, and the coverage area of a single NodeB is
large. By analyzing TP, you can determine the distribution conditions of faulty NodeBs
and locate faults quickly.

HUAWEI Confidential

44

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. Phenomenon Description
When the first cell (37021 W_BOKO_1) of the new site is enabled, the call drop rate
is high, and the reason is radio frequency (RF) errors (irresponsive Uu interfaces).

HUAWEI Confidential

45

WCDMA Product Training Technical Cases

2. Alarm Information
Null

3. Handling Process
Analyze the over-coverage:
Subcontractors adjust the electrical downtilt on October 2, and the call drop rate does
not change. The subcontractors perform a drive test, and the result shows that no
over-coverage exists.
Check the complementation of the neighboring configuration: Search for the
neighboring configuration relationship, and import NASTAR to do the check. The
result is shown as follows:

The configurations of the bidirectional neighboring cells are complete based on the
above figure. The incomplete neighboring configuration is eliminated. Check the
neighboring configuration data, 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.
Analyze carefully and find that the number of soft handover is rather large. It is 100

HUAWEI Confidential

46

WCDMA Product Training Technical Cases

times as large as other two sites.

The reason of call drops is irresponsive Uu interfaces. It may be late soft handovers
that cause the problem. Check the site-to-site handovers by the M2000, and find that
the number of handovers to neighboring cell 35151 is the largest.

The positions of the two sites are as follows:

HUAWEI Confidential

47

WCDMA Product Training Technical Cases

Analyze the call drop reasons by the tool NPmaster, and find that the reason is
ASU_TIMEOUT during handovers to cell 35151. Therefore, it is the handover failure
from cell 37021 to cell 35151 that causes the problem. Call drops occur on two users.
The core network personnel search for the configurations of the two users, and no
fault is found.
It may be the interference that causes call drops after eliminating the coverage and
configuration. The UMTS is a network of the same frequency. The counters of
neighboring cells do not become worse, so the interference is from inside. Firstly, we
check the PSC interference, and find that the PSCs of cell 37023, W_Boko_3 and cell
35151 are all 8 based on the data configurations. Someone changed the PSC of cell
35151 and did not tell us, we do not take the change into consideration when
configuring the PSC of the W_Boko, so the scrambling code conflict causes
interference, and results in the problem. Finally, change the PSC of cell 35151 to 12,
and the problem is solved.

4. Suggestions and Summary


In a UMTS project, especially in a newly created network, pay much attention to the
check of neighboring cells and scrambling codes, because they always affect the
counters when there are no alarm or parameter configuration faults.

HUAWEI Confidential

48

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. 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. Alarm Information
KPI threshold alarm

3. Cause Analysis
No critical alarm, reported by RNC: only KPIs threshold alarms (advising that PS RAB
rate is under the threshold set) and IUB Ippath intermittently alarm are reported.
From operation logs we can confirm that no operation has been executed in the RNC.
We also can confirm that RAB PS attempt has increased gradually due to user retries
HUAWEI Confidential

49

WCDMA Product Training Technical Cases

after PS RAB establishment is refused.


Since only Primary operator is affected, issue seems to be related to the IUPS
interface.
Checking all SGSN DPC we can confirm that all of them are available. Also as told
before not alarms related to IUPS interface or SGSN DPC is reported by RNC.
Checking PS RAB KPIs at cell level we can confirm that RAB establishment failure
cause is Congestion.
From the callfault log, the main reason for PS RAB setup failure is port forward
bandwidth limited, which mean the admission bandwidth for the UL IUPS port was not
enough.

Note: For all the graph bellow we need to take into account that customer blocked the
router port for IUPS interface during some minutes , this is one RAb setup get down
sunddenly at around 17:15.
The four IUPS adjnode related to the SGSN/GGSN in pool for primary operator are
affected, for all of them we can confirm that resource allocation failure has increased
due to no enough available bandwidth.

HUAWEI Confidential

50

WCDMA Product Training Technical Cases

From RNC configuration, 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.
When the problem occurred, the sum of alloced forward bandwith
(OS.ANI.IP.AllocedFwd) for the four adjnode have exceeded 2000Mbps, so RAB
setup should be failed with reason port forward bandwidth is not enough.

4. Handling Process
The Reason for High Forward Allocated Bandwidth
From the performance files, most of the PS service was interactive type.
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.
From the configuration we can confirm that: TRM factor for PS interactive service was
40%. For the R99 service, the ULGBR was 64Kbps. So the admission bandwidth for
HUAWEI Confidential

51

WCDMA Product Training Technical Cases

one R99 active user would be 64*0.4 =25.6kpbs UL BW.


From RNC performance files, the mean HSUPA UE numbers was not large compared
with the total IUPS active users. Most of the service was UL R99 service. For the four
ADJNODE, there were more than 90,000 active users when the problem occurred.

Suppose there was 10000 HSUPA user and 80000 R99 users, as each R99 user
would occupy 25.6kbps UL bandwidth for IUPS, the total IUPS bandwidth would be
80000*25.6= 2048Mbps. So we can conclude that the high number of active users
lead the forward bandwidth congestion on the IUPS port.
The Reason for High Amount of R99 Active Users
From the performance counters for one week, we can see that the Saturday was the
busiest time for this RNC.
Comparing the data with Saturday of the week before, it can be found there was an
increase of active users and the PS throughput, which mean that the service was
increasing for this RNC. (Summer time has just started and RNC cover an area near
the cost).

HUAWEI Confidential

52

WCDMA Product Training Technical Cases

Before this increase, the used admission bandwidth for the IUPS was already almost
reaching the upper limit of 2000Mbps. So the increase of users during the last days
finally leads the PS RAB setup failures. As the UEs, especially the smart phone,
would always try to reconnect the network when rejected, the total RAB attempts
increased a lot, and the RAB setup rate dropped sharply. But the throughput of the
RNC was not affected much.

Also we can confirm that the EFD (Enhanced Fast Dormancy) is enabled for this RNC,
so the EFD UE capable would change to CELL_PCH and URA_PCH status rather
than release the connection, thats the reason for so many R99 active users on the
IUPS IPPATH.
When EFD is enabled, it is needed to adjust the activity factor to prevent PS service
admission failures. In this case the recommended value of the IUPS activity factor is
10%.
Since current value of IUPS activity factor is 40%, we suggest customer to decrease
activity factor to 10%. After the change, the admittance bandwidth on the IUPS
ADJNODE sharply reduced and the problem recovered.

5. Suggestions and Summary


When a feature is enabled, we need to be careful to adjust all related parameter for
HUAWEI Confidential

53

WCDMA Product Training Technical Cases

the new scenario. When it is well known that traffic condition in an RNC will change
(As during Chrismans eve, Summer time, special event), it is recommended to health
check RNC to avoid service degradation due to congestion.

HUAWEI Confidential

54

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. Phenomenon Description
Customer complained that under RNC X there was a PS performance degradation.
Graph below show us PS performance degradation for RNC X.

HUAWEI Confidential

55

WCDMA Product Training Technical Cases

2. Alarm Information
Null

3. Cause Analysis
1.

Based on the RNC performance data , we can find the most contribute of PS
RAB ESTAB failed is recorded on VS.RAB.FailEstabPS.TNL Which means the
problem was cause on user plan.

2.

From the RNC PCHR logs , it is clearly showed that most of RAB assignment

HUAWEI Confidential

56

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.

According the RNC debug logs, we found there were many


SIG_ERR_TRMP_062C error code was recorded, 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.195.47.254 and 10.192.221.254.

HUAWEI Confidential

57

WCDMA Product Training Technical Cases

4. Handling Process
By checking this RNC IUPS interface configuration file, we cannot find this ANI peer
IP address is: 10.195.47.254 and 10.192.221.254 were in the current IUPS interface
IPPATH.
Solution:
We need to add the IPPATH for missing IP Address (10.195.47.254 and
10.192.221.254). After the execution, the KPI recovers.

HUAWEI Confidential

58

WCDMA Product Training Technical Cases

5. Suggestions and Summary


Please make sure that configuration between RNC and core side is synchronous.
Especially user plane configuration in this case. 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.

HUAWEI Confidential

59

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. Phenomenon Description
We found low RAB Success in Speech and Packet after ATM to IP Migration.
BSC 6900 UMTS version: V900R013ENGC00SPH552.

2. Alarm Information
Low RAB Success in RNC

3. Cause Analysis
Iub bandwidth is congestion both in UL and DL. Congestion on the transmission to
RNC port 0-24-0, there are lots of RAB failure caused by DL and UL Iub congestion.

4. Handling Process
Action: Temporary modify the TRMFACTOR.

HUAWEI Confidential

60

WCDMA Product Training Technical Cases

Remark: Temporary solution, change the factor to decrease the speed of the access,
in order not to generate the RAB Att Fail when few of transmission can be used. As
the issue is caused by IU-b congestion upon solved, it is better return the
TRMFACTOR back to keep old parameter.
MOD TRMFACTOR: FTI=20, REMARK="IuB_IP", GENCCHDL=70, GENCCHUL=70, SIPDL=15,
SIPUL=15, MBMSCCHDL=10, SRBDL=15, SRBUL=15, VOICEDL=70, VOICEUL=70, CSCONVDL=10,
CSCONVUL=10, CSSTRMDL=10, CSSTRMUL=10, PSCONVDL=70, PSCONVUL=70, PSSTRMDL=10,
PSSTRMUL=10, PSINTERDL=10, PSINTERUL=10, PSBKGDL=10, PSBKGUL=10, HDSRBDL=50,
HDSIPDL=15, HDVOICEDL=10, HDCONVDL=70, HDSTRMDL=10, HDINTERDL=10, HDBKGDL=10,
HUSRBUL=50, HUSIPUL=15, HUVOICEUL=10, HUCONVUL=10, HUSTRMUL=10, HUINTERUL=10,
HUBKGUL=10, EFACHDL=20;
MOD TRMFACTOR: FTI=31, REMARK="IuB_60", GENCCHDL=70, GENCCHUL=70, SIPDL=15,
SIPUL=15, MBMSCCHDL=10, SRBDL=15, SRBUL=15, VOICEDL=70, VOICEUL=70, CSCONVDL=10,
CSCONVUL=10, CSSTRMDL=10, CSSTRMUL=10, PSCONVDL=70, PSCONVUL=70, PSSTRMDL=10,
PSSTRMUL=10, PSINTERDL=60, PSINTERUL=60, PSBKGDL=60, PSBKGUL=60, HDSRBDL=50,
HDSIPDL=15, HDVOICEDL=70, HDCONVDL=70, HDSTRMDL=10, HDINTERDL=60, HDBKGDL=60,
HUSRBUL=50, HUSIPUL=15, HUVOICEUL=70, HUCONVUL=70, HUSTRMUL=10, HUINTERUL=10,
HUBKGUL=10, EFACHDL=20;

The KPI for the Iub congest has been recovered after modify TRMFACTOR, please
refer to the graph below.

HUAWEI Confidential

61

WCDMA Product Training Technical Cases

5. Suggestions and Summary


1.

Temporary Solution: Temporary modify the TRMFACTOR

2.

Solution: Expand the transmission bandwidth

HUAWEI Confidential

62