UMTS Product Training Technical Cases PDF

WCDMA Product Training Technical Cases
WCDMA Product Training

Technical Cases
2013
HUAWEI Confidential
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
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
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
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
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.
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
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
MSC wrong configure at 19th Feb. after MSC modify it, RNC paging SR become
normally.

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
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
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
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
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;
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
2)
After modification on the data configuration. One IP Logic Port is assigned to one
Node B.
PN=0, RSCMNGMODE=SHARE, BWADJ=OFF, CIR=1562, FLOWCTRLSWITCH=ON,
FCINDEX=0, OPSEPFLAG=OFF;
HUAWEI Confidential

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.

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

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
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
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.
The following alarms were reporting on both sites
Critical
22214 NodeB Unavailable
Critical
22202 UMTS Cell Unavailable
HUAWEI Confidential
13
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
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
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

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
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

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.
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
4/12/2013 6:35
4/12/2013 6:45
4/12/2013 6:35
4/12/2013 6:45
4/12/2013 6:35
4/12/2013 6:45
M3UA Link Fault
4/12/2013 6:35
4/12/2013 6:45
4/12/2013 6:25
4/12/2013 6:35
4/12/2013 6:25
4/12/2013 6:35
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
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.

1. In engineering period, we should strictly obey configuration rule to configure
HUAWEI Confidential
19
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
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
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.
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
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
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
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
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.
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
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.

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

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
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

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.
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
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
- BTS3900 V200R011C00SPC320, and deploy a new site around site

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

A problem may be caused by several reasons. Therefore, analyze a problem from
different dimensions one by one.
HUAWEI Confidential
34
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

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
There is NO alarm, but on DSP UCELL- the feedback is only that the cell is not setup.
HUAWEI Confidential
35
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.

End to end MTU Size should be considered while setting up all IP networks.
HUAWEI Confidential
36
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

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
HUAWEI Confidential
37
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
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
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
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

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
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
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
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
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.

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
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
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
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
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
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.

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
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
PS RAB setup success rate dropped a lot from 12:00
It is a RAN Sharing RNC but only Primary operator is affected
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
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
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
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
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.

When a feature is enabled, we need to be careful to adjust all related parameter for
HUAWEI Confidential
53
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
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'

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
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
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
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

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
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

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

1.
Temporary Solution: Temporary modify the TRMFACTOR
2.
Solution: Expand the transmission bandwidth
HUAWEI Confidential
62

UMTS Product Training Technical Cases PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UMTS Product Training Technical Cases PDF

Încărcat de

Drepturi de autor:

Formate disponibile

WCDMA Product Training Technical Cases

WCDMA Product Training

WCDMA Product Training Technical Cases

WCDMA Product Training Technical Cases

BSC6900 Troubleshooting Cases

Cannot connect to internet(IUPS)

Request Maximum bit rate for UL not availabe

Huawei Support site

Case1 PS Paging Loss due to high CPU load

WCDMA Product Training Technical Cases

5. Suggestions and Summary

WCDMA Product Training Technical Cases

RNC paging SR drop to 75 due to the MSC wrong LAC configuration

Paging LAC PCH Congestion low Control

Huawei Support site

Case2 RNC paging SR drop to 75 due to the MSC wrong LAC

Iu some RNC configuration change cause the paging SR decreased;

WCDMA Product Training Technical Cases

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

WCDMA Product Training Technical Cases

5. Suggestions and Summary

WCDMA Product Training Technical Cases

IP Overbooking activation causing abnormal CS calls and PS calls

Huawei Support site

Case3 IP Overbooking activation causing abnormal CS calls

WCDMA Product Training Technical Cases

Through checking Counter (VS.FEGE.TXMAXSPEED) on two of the RNC as

WCDMA Product Training Technical Cases

WCDMA Product Training Technical Cases

5. Suggestions and Summary

WCDMA Product Training Technical Cases

Analysis for IP Address Conflict Effected PS traffic Problem

IP address conflict ARP check

Huawei Support site

Case4 Analysis for IP Address Conflict Effected PS traffic

2. And the PS traffic was also affected.

WCDMA Product Training Technical Cases

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

WCDMA Product Training Technical Cases

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

5. Suggestions and Summary

WCDMA Product Training Technical Cases

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

Cell Setup FP Synchronization Failed, DPUe

Huawei Support site

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

WCDMA Product Training Technical Cases

WCDMA Product Training Technical Cases

22214 NodeB Unavailable

22202 UMTS Cell Unavailable

22208 UMTS Cell Common Channel Setup Failed

SDH/SONET Tributary Alarm Indication Signal

WCDMA Product Training Technical Cases

WCDMA Product Training Technical Cases

5. Suggestions and Summary

WCDMA Product Training Technical Cases

M3UA Link of Iu-PS caused Iu-PS service interruption

IuPS interruption M3UA Link Fauly

Huawei Support site

Case6 The Report of IUPS Load share Problem

Alarm raised time

M3UA Destination Entity Route Unavailable