2013Q4 WCDMA Product Trainning Technical Cases (2013-11)

WCDMA Product Training Technical Cases
WCDMA Product Training

Technical Cases
2013.11
HUAWEI Confidential
Table of Contents
RNC Troubleshooting Cases ........................................................................................................... 1

Case1 CS Terminate Call Establish Failure ............................................................................... 1
Case2 M3UA and SCCP link fluctuation For PS Services ......................................................... 4
Case3 IP CPU overloads issue in RNC ...................................................................................... 8
Case4 Test RNC unblocked lead to SCCP successful rate low ............................................... 13
Case5 New integrated RNC Video call failure analysis ............................................................ 16
Case6 RAB establishment failure due to CN expansion .......................................................... 20
Case7 Low SCCP success rate ................................................................................................ 24
NodeB Troubleshooting Cases ..................................................................................................... 29

Case1 Analysis for IP Address Conflict Effected PS Service Problems ................................... 29
Case2 WMPT board fault cause the NodeB External Clock Reference alarm ......................... 32
Case3 Non-transmitting RRU in a given sector cannot report RTWP ...................................... 35
Case4 Call Drop due to low availability of resources at NodeB ............................................... 40
Case5 IPPATH Became unavailable after re-homing from one RNC to another RNC due
to IP path check flag Enable ..................................................................................................... 43
Case6 HSDPA users reached MAX and DL power congestion on busy sites ......................... 46
Case7 Incorrect NodeB GPS configuration cause no e911 services for users located over
300 Km from the RNC configured with GPS ............................................................................. 52
RAN Optimization Cases ............................................................................................................... 59

Case1 HSDPA call drop increased after upgrading to RAN13 ................................................. 59
Case2 PS Background service RAB success rate decreased due to miss configuration ........ 62
Case3 Relocation radio link setup failure between Huawei and NSN RNC ............................. 66
Case4 Reduce UL CE Congestion without traffic decrease ..................................................... 70
Case5 Analysis Report for bad IFHO SR in one RNC after 2nd carrier Implementation ......... 75
Case6 PS RAB access issue after implement second carrier in one NodeB ........................... 79
HUAWEI Confidential i
RNC Troubleshooting Cases
Title CS Terminate Call Establish Failure
Keywords CS Terminate Call, Failure
Case code RNC-001 Case type Service

Case is Update
Huawei Support site 20131105
from Time
Product
BSC6900 Product BSC6900
Family
Case1 CS Terminate Call Establish Failure
1. Phenomenon Description
The calling & called numbers are having full signal bars. It takes several call attempts
for the calls to be successful, also experienced SMS problem, "IMSI unknown in
VLR".
BSC6900 version: V900R013ENGC00SPH532
2. Alarm Information
No alarms
3. Cause Analysis
As the four tests on the live network, one test is success call processing, three tests
are call failure processing.
The successful call processing analysis:
HUAWEI Confidential 1
As the figure shows, RNC receives the Paging message from the DPC 6092; RNC
sends the Paging response message to the DPC 6092. The call establishes success
on the DPC 6092.
The call failure processing analysis:
As the figure shows, RNC receives the Paging message from the DPC 6092; RNC
sends the Paging response message to the DPC 6096.
RNC cannot receive the RAB assignment from the DPC 6092, so the call establishes
failure. This mean the RNC randomly choose one MSC in the MSC pool to make a
call.
Then MSC pool will react to the RNC randomly as well. If the MSC that reacted is
same MSC that the RNC sent, the call will be success, else the call will fail. Why the
Original call success?
If the RNC did not configure the IUFLEX, but enabled the switch, RNC send the UE
INIT (Paging response) message to the MSC randomly. As the MSC pool in CN,
every MSC choice is OK.
As the original call, the first IU interface message is UE INIT message, RNC choose
one MSC before send this message.
As the terminal call, the first IU interface message is paging message from the MSC.
RNC response paging message by UE INIT message and choose one MSC, if this
MSC does not equal to the paging message MSC, the call establish will be failed.
This occurred because there was no mapping relation defined between the RNC and
the CN. We observed the RNC did not configure the UNRIGLBCNIDMAP.
4. Handling Process
The problem was rectified by defining the relationship between Network Resource
Identity (NRI) and global CN node ID's.
MML: ADD UNRIGLBCNIDMAP: CnOpIndex=X, CNId=XX, NRI=X;
Post Operation: All test calls were successful. SMS test were successful as well.
5. Suggestions and Summary
When the Iu-Flex feature is enabled and Core is in pool configuration, one should
always add the the mapping relationship between Network Resource Identity (NRI)
and global CN node ID.
1. Before executing this command, ensure that the CN node is configured through
the commands ADD UCNDOMAIN and ADD UCNODE.
2. The CN nodes connected to the same RNC in the same domain cannot use the
same NRI.
3. When the CS or PS domain doesn't support the function of IUFLEX or MOCN,
there is no mapping relationship between the NRI of the corresponding domain
and the global CN node.
Title M3UA and SCCP link fluctuation For PS Services
Keywords M3UA and SCCP link, PS service
Case code RNC-002 Case type Transport Link & Clock

Case is Update
from Time
Product
Family
Case2 M3UA and SCCP link fluctuation For PS Services
M3UA and SCCP link fluctuation for PS services;

IUPS over IP using optical port of GOUa board;
RNC version: V900R014C00SPC535.
The following alarms were observed.

Serial No. Name Severity
124833 M3UA Destination Entity Route Unavailable Critical
124832 M3UA Destination Entity Inaccessible Critical
124830 SCCP Subsystem Prohibited Critical
124829 M3UA Link Fault Major
3. Cause Analysis
We can perform the following steps to handle the alarm:

1) From the alarm log, it shows there is M3UA Link Fault/SCTP Link Fault/Path to
SGSN Faulty.
2) From the path ping result, it shows there is packets drop. The serious time, mean
lost has reached 40%.
3) From SCTP LINK detect, it shows there is retransmission of SCTP.
4) SCTP service time.
5) M3UA LINK unavailable time as below:
From the above analysis we came to know that there is some fault at the
transmission end.
4. Handling Process
Now, as we have already analyzed that transmission was having some issue, so we
took following steps:
1) We asked SGSN person to check the alarm at their end and found same that at
SGSN end as well these alarms are occurring and showing path towards RNC is
faulty. So we became sure that there is some problem in the path from RNC to
SGSN.
2) We checked the architecture of the PS connectivity from RNC to SGSN.
3) We found that between RNC and SGSN there are two LAN switches that come
into the picture.
4) Then we asked the datacom engineer to check those switches which come into
the picture, when he analyzed alarm logs and ping test results he came to know
that the ports of both the switches are not able to forward the packets correctly.
5) After analyzing this he changed the ports that were coming into the picture.
6) The ping test was successful after this change and no PS signaling fluctuation
occurred after this and the problem was handled successfully.
Whenever we encounter signaling fluctuations we should analyze the alarm logs and
ping logs at both the end, i.e. at RNC end as well as SGSN end and make sure that
there was no operation done at both the nodes related to the signaling. And then we
should check thoroughly the transmission nodes that are coming in between.
Title CPU overloads issue in RNC
Keywords CPU overload, RNC
Case code RNC-003 Case type Equipment Specification

Case is Update
from Time
Product
Family
Case3 IP CPU overloads issue in RNC
Customer reported issue that CPU overload alarm reported in all the RNCs.
CPU overload alarm: ID 1301 is reported in the RNC
3. Cause Analysis
From the alarm logs we have found that there were many CPU overload alarm
appeared in the RNC during the whole day.
From the configuration logs analysis we have found that the NodeB count in each
RNC as below.
4. Handling Process
1) As the RNC has congestion, UE may be have more wait time to get the service.
So need to change the below parameter.
SET STATETIMER: RRCCONNREJWAITTMR=4; change to RRCCONNREJWAITTMR=8;
But after changing the parameter we have not observed any considerable
changes. So based on above RNC load we recommend to add another SPUa
board to share the service. Because the CPU mean value is more than the 60%
by service in busy time.
2) As from the logs we confirm that there is only pair of SPUa board in RNC. And the
Mean CPU load is more than 60% as below.
3) So we check the second level data. At 12:59, CPU max value has the same
behavior with RRC sum. So it can be concluded CPU max fluctuation is caused
by traffic change in short time.
4) So recommend to add another SPU board to resolve the issue.
One SPUa board support maximum 100 NodeBs, one sub system support Max
25 NodeBs. As per details shared by you, all SPUa boards reached to its
maximum capacity. The permanent solution for this issue is that, we need to add
one more SPUa board & distribute NodeB uniformly.
Title Test RNC unblocked lead to SCCP successful rate low
Keywords SCCP low successful rate

Case is Update
from Time
Product
Family
Case4 Test RNC unblocked lead to SCCP successful rate low
In F country, a vendor core network will swap in V network.

After cutover, many users complain PS service is not stable.
Low SCCP successful rate alarm
3. Cause Analysis
There are many possible reasons may lead to low SCCP successful rate alarm:
1. RNC CPU overload;
2. Parameters are not matched between RAN and Core network;
3. Transmission is not stable;
4. Other possible reasons;
4. Handling Process
1. We try to do the ping test from commercial RNC to A SGSN and not packet was
lost.
2. After checking the CPU usage in RNC, it is still normal.
3. Confirmed negotiation parameters between SGSN and RNC.
4. After trace analysis for SCCP, we found there is less CC message from A core
work. The message should be CR->CC->RLSD. But there is only CR message
sent from RNC, less response from CN. There is no CC message, and there is no
CREF message neither.
5. After check the trace from SGSN side, we found SGSN also communicate with
our test bed RNC.
6. After A block the link between SGSN and Test Bed RNC, the SCCP service
recovered.
During swap, it is better for both sides to blocked test links before swap commence.
Title New integrated RNC Video call failure analysis
Keywords Video call failure
Case code RNC-005 Case type Data configuration

Case is Update
from Time
Product
Family
Case5 New integrated RNC Video call failure analysis
After commissioning the New RNC and NodeB in customers test bed, we found that
the dial test of voice call is normal, but the dial test of video call is failure, UE terminal
feedback one message about the service is not supported
RNC version: V900R014C00SPH522
NodeB version: V200R014C00SPC350
Null
3. Cause Analysis
Due to the Voice call is normal, but Video call is failure, so firstly we suspect that
maybe the UE terminal cannot support Video call.
Then we changed to use another 3G phone which Video call test successfully in live
network, but meet the same problem which the terminal indicate that the service is
not supported.
Because of the signaling procedure is the same flow between Voice call and Video
call, but just only Video call have this issue, so we conclude that when UE waiting for
the specifically resource for user plane ,but network didnt assign the correct resource
to UE.
Analysis procedure:
1. Query the CE resource and Code resource for NodeB whether system have
enough resource to support Video call business, through check the CE and Code
resource in NodeB side, we clarify that the resource of system can support 64K
Video call business.
2. Query the bandwidth of IPPATH for IUCS and IUB interface, through check no
issue about bandwidth.
3. Then we retest Video call, From the UE Trace of BSC6900 LMT we see that Core
network sent the RANAP_RAB_ASSIGNMENT_REQ message to RNC, when
RNC receive the assignment resource of wireless, RNC feedback the
RANAP_RAB_ASSIGNMENT_RESP message to RNC, but we found in this
message including the failure information about requested information not
available.
So it can be concluded that there are some issue in RAN part. Then we compare
the configured script between this new RNC and another live network RNC, in the
configuration script of this new RNC we found the type of IPPATH for IUCS
interface is different from the type of TRMMAP (transport resource mapping).
The type of IPPATH for IUCS interface is configured as EF, but in transport
resource mapping for IUCS interface, the R99 CS conversational primary path
and the R99 CS streaming primary path are configured as AF43.
As below indicate:
Then we can conclude that causes the type of IPPATH for IUCS interface is
different from the type of TRMMAP (transport resource mapping), lead to Video
call failure.
4. Handling Process
1. According to the TRMMAP Configuration Rules for IUCS interface, after we
modify the type of IPPATH from EF to AF43 (the same as TRMMAP R99 CS
conversational primary path and R99 CS streaming primary path), then retest
Video successfully.
2. Normal UE TRACE for Video call as below indicate:
When deploy the new RNC for WCDMA project, there are many reasons lead to test
failure. According to the trouble of Symptom, we need to query the current alarm, the
TRACE LOG and compare the commissioning of script with normal site, and then
found the difference for locating the issue. We need have a clear picture about how to
configure the parameter according to the configuration rules.
Title RAB establishment failure due to CN expansion
Keywords Transport layer failure, RAB failure, CN expansion

Case is Update
from Time
Product
Family
Case6 RAB establishment failure due to CN expansion
On one RNC of B operator, the RAB assignment failures are observed for some cells
which cause the RAB establishment success rate is only 30-40% on these cells.
Null
3. Cause Analysis
1. Checking the KPI reports, the problem cells are randomly and the main reason of
RAB establishment is transport layer and the counter VS.RAB.FailEstabPS.TNL
is pegged.
2. In the Hedex document, the counter VS.RAB.FailEstabPS.TNL is mainly caused
by IU interface issue. But why it only occurs on some randomly cells?
4. Handling Process
1. Check the KPI reports, and then find one cell with the transport layer failures at
17:00 while it was not there at 16:00 and 18:00. The cell id is 40357.
2. Check the RNC PCHR log from 16:00 to 18:00, then finds the top cells list of RAB
establishment failures. The cell id 40357 is there.
3. The PCHR log shows the cell id 40357 has 230 RAB assignment failures and 228
of them are caused by AL_L3_TRM_PEERIP_ANI_MATCHFAIL what matches
the KPI reports.
4. Check the related logs of failure reason AL_L3_TRM_PEERIP_ANI_MATCHFAIL,
and find the RAB failure message (RANAP_RAB_ASSIGNMENT_RESP) sent by
RNC what shows the reason is "Cause= Iu Transport Connection Failed to
Establish".
5. Check the UE type, and find 100% of these failures are caused by one UE. This is
why such issue only occurs on some randomly cells.
6. Make the IU message trace for 10 minutes, and filters out the RAB assignment
failures caused by IU transport Connection Failed to Establish. 13 cases are
found and 10 of them point to the DPC113594.
7. Checks the fail call flow and on the message RAB_ASSIGNMENT_REQ, one
wrong IP (96.1.138.44) is found what is not configured on the RNC script.
8. Checks all the 10 failures of CN node 113424, all the IPs of CN side are
96.1.138.44.
9. As confirmed by customer CN team, this IP was configured few days ago due to
CN expansion. And after add the IP on the RNC, the problem is resolved.
This issue is caused by the miscommunication of customer CN team and RAN team.
The modification flow should involve all the related teams on both CN and RAN side.
Title Low SCCP success rate
Keywords SCCP, LAC, SAC

Case is Update
from Time
Product
Family
Case7 Low SCCP success rate
Customer reported that are so many low SCCP alarms in RNC on off-peak period
between 12am to 8am. From the alarm information the alarm is on different SPUs but
pointing another operator DPC.
From the alarm information the alarm is on different SPUs. Customer reported that
are so many low SCCP alarms in RNC on off-peak period between 12am to 8am.
The customer is concerned that the problem might be due to:

Transport but initial feedback from transport that there was no activities and
alarms seen on their equipment;
Defective GOU board and want to reseat the GOU boards when the problems
reoccur.
Alarm ID: 21522 Low SCCP Setup Success Rate
3. Cause Analysis
1. Alarm, event and operation logs were initially analyze but did not find any
substantial information to identify the cause of the problem.
2. KPIs were check and found out that SCCP degradation only occurs at off-peak
periods.
To isolate transport, KPIs related to transport was check but found all KPIs to
be normal and no degradations were found;
IU trace was then conducted to validate the problem and later found out the
common failure occurs on the specific SAC and for specific users as shown
on the handling process.
4. Handling Process
1. After IU trace was conducted to validate the problem and capture the problem
real time
Signal flow shows the connection refused (MSG 3)
With detailed message for CREF:
Filtering all CREF message have the same refusal cause code as shown below:
Filtering by USER ID shows only RANAP Initial UE message which means that
this UE have continuously attempted but was not able to continue through.
2. From the IU trace with SAC information, it was later identified to specific f850
carrier addition for an existing site:
ADD UCELLSETUP: CELLID=37844, CELLNAME="NEW_37844-0850-1-1",
LOCELL=137844511, SAC=H'92EA;
LOCELL=137845512, SAC=H'92EB;
LOCELL=137846513, SAC=H'92EC;
3. The cause of the problem is because there is a new LAC/ RAC/SAC defined by
the operator in their MSS pool the week before the f850 carrier additions on the
affected site. But this new LAC information was not defined on the MSS pool of
the other operator in a MOCN network.
4. The affected site was later modified to the previous LAC/RAC/ SAC information
through MOD UCELLACINFO after the change, KPI improved and is stable:
1. Familiarization of IU interface specifically for SCCP 3GPP TS 25.410;
2. It is important to understand the alarm information for common information such
as SSNs, GOUs, DPC;
3. IU trace with SCCP is recommended if issue is on-going to determine
immediately the cause of the problem;
4. For a MOCN network it is risk if one of the operator does not have the same
LAC/RAC/SAC information on their CN definition;
5. For low SCCP success rate issue it is not transport or a RNC hardware issue
unless there are other correlated alarms.
NodeB Troubleshooting Cases
Title Analysis for IP Address Conflict Effected PS Service Problems
Keywords IP address conflict ARP detection PS service
Case code NodeB-001 Case type OM

Case is Update
from Time
Product
NodeB Product NodeB
Family
Case1 Analysis for IP Address Conflict Effected PS Service
Problems
After added a 2G site, the PS traffic throughput of 3G side decreased sharply.
21346---IP Connectivity Check Failure

25885---IP Address Conflict
3. Cause Analysis
1) All the sites connect to slot 18 of Subrack 0; the next hop address is
10.128.16.73.
2) 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;
3) 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.
4) RNC sent ARP request to Cisco 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.
5) At the problem time, BSC1 shielded the rout IP (10.128.16.73), and then the sent
and received traffic had a sharply decrease during the ARP check failure of IUB
interface.
6) Also the PS throughput decreased because of the IUB traffic decrease.
4. Handling Process
Distribute 2G side with another IP address which has no conflict with other network
element.
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.
Title WMPT board fault cause the NodeB External Clock Reference alarm
Keywords IPCLK, WMPT faulty, frequency discrimination
Case code NodeB-002 Case type Clock

Case is Update
from Time
Product
NodeB Product NodeB
Family
Case2 WMPT board fault cause the NodeB External Clock
Reference alarm
The external clock reference alarm was observed on one NodeB while the other
hundreds of sites were working fine. Only one IPCLK link is configured alone with one
IPCLK server for each NodeB.
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.
Alarm ID =26262
Alarm name = External Clock Reference Problem
Location info = Specific Problem=Excessive Frequency Difference Between
Clock Reference and Local Crystal Oscillator
3. Cause Analysis
The possible causes of this alarm are:
1. The IPCLK source quality is not good. But all the 200 NodeBs are using the
same clock source and the alarm is only observed on one site, so this is not
IPCLK source quality problem.
2. The IPCLK server capacity problem. Checking the IPCLK server capacity and
the usage, there are more than 300 budget.
3. The transmission quality is not good.
Ping test is done on the problem NodeB and it shows the very good transmission
quality. The IPCLK server is accessible and no delay.
The PTP test is also showing the good quality of transmission. NodeB receives
IPCLK source message per 2 seconds.
4. The IPCK related configuration problem. Comparing with the normal sites, the IP
clock related configurations are same. And the current DA value configuration is
31207.
4. Handling Process
1. Check the problem NodeB clock state, and it is showing Frequency Deviation
and PLL state is free running.
And the clock link state is normal.
2. Try to remove the current IPCLK source and IPCLK link and then reconfigure
them. The alarm is clear but appears again soon.
3. Made the IPCLK test by running the command: STR CLKTST: SN=7; But on the
second day, nothing was found on the test report. We kept the clock test running
for 3 days and got the test result on the 5th day.
This clock test report shows the IP clock reference is not stable and the
frequency discrimination is too large. Clock rectifying formula is: Correct DA=
current setting DA (65525 /40) *discrimination. But in this case, the frequency
discrimination is 40HZ around, the formula calculation is out of the DA range, this
is not able to be rectified by DA value optimization.
4. According to all of above analysis and testing, all the IPCLK resource issue and
configuration issue are excluded. So this is hardware issue.
5. As soon as the WMPT board replacement is done, the alarm is cleared.
Title Non-transmitting RRU in a given sector cannot report RTWP
Keywords RTWP of non Tx RRU
Case code NodeB-003 Case type Data Configuration

Case is Update
from Time
Product
NodeB Product NodeB
Family
Case3 Non-transmitting RRU in a given sector cannot report
RTWP
The customer describe that a non-transmitting RRU reported no Board RTWP and he
emphasized that the problem had been since installation.
It was only received and non-transmitting RRU.

No alarms were seen on the RRU and NodeB.
3. Cause Analysis
1. Checking the configuration of this site, we saw that there were 2 RRU's in one
sector: The configuration showed us that RRU 89 was Non Tx RRU.
2. RRU86 of the same sector is reporting RTWP.
3. The DSP BRDMRINFO reveals they are of the same RRU type.
4. The reason for "Board RTWP" to be reported is because it has a relationship with
if the Uplink cell is established or not on this RRU.
5. Hence checking the RRU89 logs we found out that "no uplink frequency" was
configured on RRU89. So we concentrated on the configuration in the
main-board logs.
6. The information which was tried to be obtained from NodeB main-board log was:
Such as how many RRUs on this sector;
How many antennas on this sector;
The uplink demodulation capability in this sector;
7. Analysis of Configuration log
a) There are two RRUs on this cell RRU86 and RRU89, and configure 4 antennas
on this sector, just shown as below:
b) The configuration of the uplink demodulation has shown as below: The
DEMMODE means the uplink demodulation way, and the 4 is enumerate, means
2-Channels Demodulation Mode.
c) The customer reported that the downlink frequency is configured on the RRU86
of this sector but not on the RRU89.
d) Due to the configuration arithmetic of NodeB, if the demodulation way
(2-Channels Demodulation Mode) less than the sector antennas ( ANTM=4) ,
NodeB will choose the downlink and uplink frequency on the same RRU i.e.
RRU86.
e) This was verified from the log on the RRU86, our conclusion was confirmed.
4. Handling Process
1. Checking the configuration of the NodeB.
2. The manufacturing information of the boards.
3. Mechanism to be understood how the "Board RTWP" is reported from a RRU.
4. Confirming the issue that has been reported by customer is existing or not.
5. After understanding the working of the RRU reporting RTWP, checking the UL
frequency assignment is on which RRU.
6. The ANTM and uplink demodulation play a part on how the RTWP is reported.
7. Checking the above parameters proved our understanding of "Board RTWP"
mechanism correct.
8. It had to be changed to conform to the NodeB configuration arithmetic.
9. Applying the change to demodulation mode resolved the issue for customer.
This sector has configured 4 Antennas(2 of 89 and 2 of 86) for the uplink
Receiver. But uplink demodulation mode is configured two ways. So, maybe the
site chooses the two Uplink antennas from the RRU86 but not the RRU89
automatically.
1. List the configuration of sectors
2. List the summarized information of the local cells
3. List the resource structure of a specified uplink BB resource group
4. Script for change
RMV LOCELL;
RMV ULGROUP: ULGROUPN=1;
ADD ULGROUP: ULGROUPN=1, DEMMODE=DEM_4_CHAN, SNE1=3;
ADD LOCELL;
Title Call Drop due to low availability of resources at NodeB
Keywords Call Drop, CE Utilization
Case code NodeB-004 Case type Service

Case is Update
from Time
Product
NodeB Product NodeB
Family
Case4 Call Drop due to low availability of resources at NodeB
Uplink CE Congestions due to resource properly not allocated in K country due to
Impact services in live network resulting revenue loss for customer.
As per DSD we configured CEs and assigned WBBP card as per BoQ requirement
and network requirement.
As alarm appeared at NodeB site of CS/PS RAB Success rate decreased impact call
drop in network.
3. Cause Analysis
1. We got the Uplink CE Congestion due to hardware expansion on a DBS 3900
NodeB during supporting, we found CE congestion in one site and we check the
report of non busy hour and evening busy hour, we found during pic our
utilization was high.
2. CS/PS RAB Success rate was observed to be as low as 20% at busy for a
certain NodeB; further analysis with Nastar software revealed failures due to UL
CE congestions; Hardware upgrade was carried out as recommended but the
issue was not resolved.
3. NodeB can support up to 3 WBBP boards, all three boards can be configured for
one UL BB Resource group and handling a maximum of six Cells. As
recommended, second WBBP board was installed in Slot 2 Subrack 0 but
another UL resource group (1) was wrongly created; the newly installed WBBP
board was configured for this group.
4. Thus, UL Resource group (1) was redundant because XXXX8, XXXX9 and
XXXX0 were initially allocated to UL Resource group (0) (Note that one Cell may
be allocated just one UL Resource group). UL Resource group (1) was removed
and the WBBP board in Slot 2 Subrack 0 was added to UL Resource group (0)
by creating another UL Process Unit as shown below:
4. Handling Process
1. LST ULGROUP: check using this command of board configuration.
2. RMV ULGROUP: To delete a mention uplink BB resource group.
3. MOD ULGROUP: ULGROUPN=X, RGOPTYPE=ADDULPUNIT, SNE=X; Run
this command to modify the resource structure of a specified uplink BB resource
group and add a board to the group.
4. LST LOCELL: MODE=ALLLOCALCELL: Run this command to display cell
configurations/allocation of UL/DL resource groups.
5. DSP BBPTC: (applicable to DBS3900 solution only): Run this command to
display the base band process unit traffic capability.
6. UL CE congestions was resolved completely; CS/PS RAB success rate improved
to approximately 99% at busy hour.
Resource allocation sometime needs to be very carefully administered in line with the
network planning; the base band process unit traffic capability of each WBBP board
should be confirmed prior to NodeB license configuration/distribution.
IPPATH Became unavailable after re-homing from one RNC to
Title
another RNC due to IP path check flag Enable
Keywords IP path check flag
Case code NodeB-005 Case type Transport Link & Clock

Case is Update
from Time
Product
NodeB Product NodeB
Family
Case5 IPPATH Became unavailable after re-homing from one
RNC to another RNC due to IP path check flag Enable
During the re-homing of NodeB from one RNC to another RNC, the IPATH became
unavailable due to IP path check flag enable.
Source RNC software version: V900R014ENGC00SPC535
Target RNC software version: V900R014ENGC00SPC535
NodeB type: BTS3900L
NodeB software: V200R013C00SPC521
Null
3. Cause Analysis
1. During the re-homing from one RNC to another RNC the IPPATH was
unavailable with the description as fault cause is ping test failure.
2. And the local cell status was also null at NodeB end.
3. After that we performed the PING test from both end (RNC & NodeB) and in both
cases we were able to ping the IP with zero packet loss.
4. Handling Process
1. We run the following command at RNC end and found that the IP path check flag
is enabled as it is recommended in R14 that it should be disabled: LST
IPPATH:ANI=2123;
2. So we disabled the IP path check flag by following commands.
MOD IPPATH:ANI=2123,PATHID=4,ITFT=IUB,PATHCHK=DISABLED;
3. After that all IPPATH were available and the status of local cell was also
changed.
Title HSDPA users reached MAX and DL power congestion on busy sites
Keywords HSDPA users reached MAX
Case code NodeB-006 Case type Service

Case is Update
from Time
Product
NodeB Product NodeB
Family
Case6 HSDPA users reached MAX and DL power congestion
on busy sites
The number of HSDPA users was reaching to maximum capacity on the cells.
The busy sites were also having high DL power congestion.
No alarms were reported during this issue period on the NodeB or RNC.
3. Cause Analysis
1. RRC success rate is fine when seen with history on this RNC.
2. RAB is definitely a cause of concern (AMR and PS below respectively).
3. Checking for the top cells that have been impacted on the RNCTOP CELLS
identified are 3361, 3201 and 3132 in descending order. Investigating one of the
cells as the other cells have same scenario PS RAB Succ rate on cell: It can be
confirmed that the Succ rate has maintained, but due to larger Att which were
beyond the capacity of the cell the PS RAB Succ Rate was impacted.
PS Congestion
HSDPA User Congestion
DL Power Congestion
4. Reason for above counters being triggered is due to CALL ADMISSION failure
on RNC due to resource limitation.
5. HSDPA users on cell almost full capacity (32) when comparing to RNC license.
6. Result:
The HSDPA user number is very high.
When the HSDPA has maxed out they will be put on R99, but due to many
users it causes congestion on UL and DL.
Hence the power congestion is noticed.
7. Suggestion:
Expand the site which will ease HSDPA to R99 improve resource usage.
Load balancing the traffic to GSM cell when high event is around.
Increase HSDPA user number per cell (for future).
4. Handling Process
1. Validate the RNC counters related to RRC, if an entire impact on the RNC can be
seen.
2. Since the performance KPIs for RRC were normal we looked at the AMR and PS
RAB which definitely showed not a good trend on the RNC.
3. Check the RNC top cells to find the reason for this trend on RNC.
4. From a group of cells which were showing similar drops, a single one was used
for analysis.
5. PS RAB Succ rate congestion was checked on the site.
6. It came to light that the HSDPA users were reaching maximum capacity on the
cells which led to CALL ADMISSION FAILURE on RNC.
7. The number of HSDPA users was maximum value when their numbers were
compared to the RNC license.
8. Hence the large HSDPA users were shifted to R99, but due to the large numbers
the UL and DL was affected on this site i.e. power congestion, the LAB first to
check any conflicts. In this case, the relocation success rate is now stable after
modifying to the right DSCP values to the TRMMAP.
1. Capacity planning and performance is the key to growing network.
2. Analyzing the cells which show worst trends should be taken as models to be
fixed.
3. Load balancing of the traffic to keep the UMTS network on a lesser load when
possible should also be seen.
Incorrect NodeB GPS configuration cause no e911 services for
Title
users located over 300 Km from the RNC configured with GPS
Keywords e911 GPS AGPS Location Services
Case code NodeB-007 Case type Data Configuration

Case is Update
from Time
Product
RAN Product RAN
Family
Case7 Incorrect NodeB GPS configuration cause no e911
services for users located over 300 Km from the RNC
configured with GPS
For NodeB using software version WCDMA NodeB V200R014C00SPC350, it was
noted that e911 services were not available on some NodeBs in the network.
Due to strict North American government regulation one of our customer have been
constantly conducting drive testing on the network for e911 location services and
have noted that in some scenario, e911 location doesn't work and also resulted in
a very inaccurate result. From the drive testing result, errors of over 25Km were
frequently obtained from a number of NodeBs that are located just 50km away from
another NodeB configured with GPS.
No alarm was noted on the network for this fault
3. Cause Analysis
1. Obtained the statistic information from the customer of the error rate of the
location services of GPS.
We obtained drive test result from the customer and noted the statistics for users
that have a high percentage of error. This confirm the customer report that e911
calls originate on NodeBs that are located over 300km from an RNC equipped
with a GPS device does not report an accurate GPS location. This helps us to
understand the magnitude of the issue and to determine which NodeBs are
impacted by this problem.
2. We confirm there were no licenses required on the NodeB to facilitate location
services for 911 call on the NodeB.
3. Confirm the testing device used by the customer support GPS location services
for e911.
From the UE trace, we confirmed the UE was GPS capable and we also
confirmed with the customer there is no know issues with the device GPS
chipset.
4. Network driving testing with the customer. A number of drive testing was done
with the customer from different site location.
Drive Test Scenario is outlined below:
The customer have a number of vehicles equipped with GPS and along with a
test device that utilize a script to automatically dialed a simulated e911
emergency call to an internal server. Once the vehicle is on, then the script will
automatically execute and called this simulated emergency number once every 3
minutes.
From the drive test result, there are two GPS measurements, one reported by
the RNC which is stored on the internal server and the other by an onboard GPS
device that measure the ground truth measurement.
5. Conducted Iub trace to determine if the NodeB is broadcasting the GPS
information from other NodeBs.
After conducting a number of Iub trace on the impacted NodeBs, we found that
the NodeB is broadcasting GPS information to the RNC in the NBAP Info Report
message as seen from the Iub trace below.
The information exchange between the NodeB and RNC is according to the
following call flow:
Customer Network Setup:
Network Trace on the Iub interface:
After we confirmed the NodeB is broadcasting the GPS information to the RNC,
then we try to determine why the RNC is not sending this information to the UE
when location service for e911 is triggered.
6. Conduct a trace on the test UE
From the call flow chart of the tracing that was done on the test UE, we can see
that an emergency call was triggered by the UE in line 14 of the RRC UL Direct
Transfer message from the UE to the CN.
After the emergency call was initiated by the UE, the CN send a RANAP location
reporting to the RNC informing the RNC of this emergency call. At this point the
RNC should send the GPS information to the UE in a measurement report
message. However when we examined this RRC measurement control message
from the RNC to the UE, there were no GPS information included.
No measurement control message was sent from the RNC to the UE for the
trace obtained with large error.
7. Verify the configuration of the RNC and NodeB
In verifying the configuration, we checked if there were any parameter
modification on the network and confirmed with the customer when this problem
was first noted.
In addition we checked and verify the existing configuration of both the NodeB
and RNC to determine why the RNC is not sending the GPS information to the
UE when an emergency call was triggered. From the network trace and analysis
that were conducted, it was clear that this problem is most likely due to a
configuration error.
However, since this network has been in service for over 5 years, it was also
necessary to consult R&D to determine if there were any software changes that
would impact the GPS.
4. Handling Process
The configuration of A-GPS on the RNCs shows that the parameter for DGPS is
enabled as shown below on all RNCs on the network:
SET USMLC: UEASSAGPSASSDATASWITCH=REFERENCE_TIME_FOR_GPS-1&
REFERENCE_LOCATION_FOR_GPS-1&DGPS_CORRECT-1
This means that differential GPS is configured on the RNC. However after checking
the configuration of the GPS for the NodeBs we realized that the configuration was
inconsistent with DGPS as configured for RNCs. We have checked the configuration
for all NodeBs which contained a GPS card installed and have noted that they are
only configured for GPS and not DGPS.

RNC1XXX:
ACT GPS: AGPSRECEIVERID=1XXX, ACTTYPE=BOTH; // RNC1XXX GPS Configuration
ACT GPS: AGPSRECEIVERID=3XXX, ACTTYPE=GPS; // Incorrect GPS Configuration for
NodeB 3XXX
ACT GPS: AGPSRECEIVERID=4XXX, ACTTYPE=GPS; // Incorrect GPS Configuration for
NodeB 4XXX
MML Command to correct this configuration on this RNC for the impacted
NodeB:
ACT GPS: AGPSRECEIVERID=3XXX, ACTTYPE=BOTH;
After the above changes have been effected on the RNCs, then the RNC will use the
NodeB GPS information during a e911 call for NodeBs that are configured with GPS.
After determined that there were incorrect configuration on the network since it was
launched. We provided the correct configuration to the customer and the change was
done and the network re-tested. After the parameter change took effect, the customer
confirmed the accuracy improved to an acceptable level.
The parameter changes are shown below:
MML Command to correct this configuration on this RNC for the impacted NodeB.
This parameter change effectively configured the NodeB GPS for DGPS to match
what was configured for the RNC GPS.
To prevent this problem from re-occurring on the network, we encouraged the
customer to:
Ensure this testing is done on any RNC or NodeBs that will be commissioned on
the network in the future.
Performed regular drive testing and update us with the result to follow up on the
accuracy of GPS reporting.
Audit the network for any NodeBs that contain a GPS card installed and correct
the configuration on the network.
RAN Optimization Cases
Title HSDPA call drop increased after upgrading to RAN13
Keywords HSDPA call drop increase, upgrading to RAN13
Case code RNO-001 Case type KPI

Case is Update
from Time
Product
Family
Case1 HSDPA call drop increased after upgrading to RAN13
After upgrading to RAN13, HSDPA call drop rate increasing about 0.3%. Blue line is
the call drop rate in May.14th (Before upgrading), and the red line is the call drop rate
in May.28th (After upgrading).
NULL
3. Cause Analysis
After upgrading to RAN13, there were some parameter modifications made in RNC.
1. The H2F optimization switch was opened.
2. The timer for state transition from HS-DSCH to FACH and E-DCH to FACH were
set to 5 seconds, and the timers were set to 1 second before upgrading.
These parameter modifications would decrease the number of H2F and E2F state
transition. As a result, the number of HSPA user would increase. Furthermore, the
radio interface would deteriorate because of the increasing HSPA users and the
handover became hard to perform because of the limited resources. As a result, the
risk for call drops which were due to bad coverage increased.
4. Handling Process
Comparing the performance logs of May.14th (before upgrading, blue line) and
May.28th (after upgrading, red line):
The PS call drops that caused by SRB reset decreased, but the number of SRB reset
was small before upgrading.
Turn of the H2F optimization switch and set the H2F and E2F timers back to 1s.
SET UCORRMPARA: PerfEnhanceSwitch=PERFENH_H2F_OPT_SWITCH-0;
SET UUESTATETRANSTIMER: BeH2FStateTransTimer=1, BeE2FStateTransTimer=1;
PS Background service RAB success rate decreased due to miss
Title
configuration
Keywords RAB success rate decreased, PS background, miss configuration
Case code RNO-002 Case type Data Configuration

Case is Update
from Time
Product
RAN Product RAN
Family
Case2 PS Background service RAB success rate decreased
due to miss configuration
Customer complains that the PS Background service RAB success rate decreased
around 5% after upgrade RNC from V900R012SPH510 to V900R014SPH538.
Null
3. Cause Analysis
1. From the performance, almost all the PS RAB failed caused by TNL reason.
2. From the PCHR log, obviously shows that the PS Background service RAB failed
with the cause of AL_L3_TRM_PEERIP_ANI_MATCHFAIL.
3. There are a lot of related errors printed in debug logs. The SIG error code shows
that TRM allocate transmission resource failed, and the cause is PEERIP
MATCH FAIL. It means the RNC doesnt find the PATH and IPRT.
4. From statistic of the Debug log regarding the missing IP, there is one IP
(201.23.189.108) that has been allocated by CN, which miss IPPATH and IPRT
in RNC side.
Checking the operation logs, there is no related operation to delete the IP PATH
around 10~11/09/2013.
4. Handling Process
The root cause is that one IP is missing related to IPPATH and IPRT in RNC side
when CN send RAB ASSIGNMENT REQUEST with that IP address to RNC. RNC
cant match the PATH and IPRT, and then it failed.
To solve the problem, it is necessary run the MML commands as follow:
ADD IPPATH: ANI=1880, PATHID=100, ITFT=IUPS, PATHT=QoS, IPADDR="10.134.239.172",
PEERIPADDR="201.23.189.108", TXBW=1000000, RXBW=1000000, VLANFLAG=DISABLE,
PATHCHK=DISABLED;
PATHCHK=DISABLED;
PATHCHK=DISABLED;
Rollback Command:
RMV IPPATH: ANI=1880, PATHID=100;
The problem was caused at the same time when the RNC was upgrading. It is very
important to tell the customer to freeze the complete network during this kind of
procedure.
Title Relocation radio link setup failure between Huawei and NSN RNC
Keywords Relocation handover, NSN
Case code RNO-003 Case type Service

Case is Update
from Time
Product
RAN Product RAN
Family
Case3 Relocation radio link setup failure between Huawei and
NSN RNC
RNC version: BSC6910 V200R015C00SPH518
In operator A, live network configure Huawei RNC as below:
1. UNRNC configuration in Huawei RNC for NSN RNC
2. UEXT3GCELL configuration in Huawei RNC for NSN RNC
With the above configuration, Huawei RNC cannot perform soft handover and
relocation to NSN cell for both HSDPA and HSUPA service. The radio link between
RNC cannot setup, RNSAP_RL_SETUP_FAIL is seen during the trace.
Null
3. Handling Process
As seen from the tracing we know that the NRNC and UEXT3GCELL capability
container on Huawei RNC is not configured correctly.
1. Isolate which service is causing the handover failure

DEA UCELLHSUPA: DL channel setup on HS-DSCH and handover is
performed successfully.
DEA UCELLHSDPA: UL channel setup on E-DCH and we get
RNSAP_RL_SETUP_FAIL in the trace.
Conclusion: Radio link fail to setup due to capabilities relating to the
E-DCH channel of the neighbouring cell.
2. First discussion with NSN we learn that:
NSN RNC does not support 2ms TTI during handover but is supported
within their RNC.
NSN RNC supports maximum 2SF2 within RNC.
Modify UEXT3GCELL capability to turn off 2ms TTI and set maximum
E-DCH support 2SF4.
Results: Radio link setup successful and relocation can be performed.

Before handover, RB is reconfigured to 10ms TTI 2SF4 on Huawei side,
however after handover on NSN side E-DCH channel remains using 2SF4
10ms TTI and does not go up to 2SF2 2ms TTI.
Other test: Set UEXT3GCELL capability support max 2SF2 and 2ms TTI
turned off.
Result: RNSAP_RL_SETUP_FAIL is seen in tracing and neighboring cell
cannot be added to active set for soft handover.
3. After further discussion, NSN mentioned that NSN RNC does not support
HSUPA over IUR.
MOD UNRNC to turn off HSUPA over IUR capability.
MOD UEXT3GCELL and set maximum E-DCH support 2SF2.
Result: Radio link setup successful and soft handover and relocation
successfully happens. Before handover, RB is reconfigured to 10ms TTI
2SF4 on Huawei side and on NSN side UL rate returns to 2ms TTI and 2SF2
after relocation complete.
Other test: Tested setting UEXT3GCELL max E-DCH 2SF2+2SF4 and
same results is obtained.
Certain neighbouring RNC and neighbouring cell capabilities should be configured
according to handover capabilities and not just cell capabilities. I.e. The cell supports
2ms within cell but does not support 2ms TTI handover. As such UEXT3GCELL
should be configured with 2ms capability OFF. 2SF2 is the maximum capability of the
cell and although 2ms TTI is not supported during handover, the cell still has a
maximum E-DCH capability of 2SF2 and should be configured as such.
Title Reduce UL CE Congestion without traffic decrease
Keywords CE Congestion, HSUPA, UL R99

Case is Update
from Time
Product
RAN Product RAN
Family
Case4 Reduce UL CE Congestion without traffic decrease
We have high UL CE Congestion.
RNC version: RAN13
Customer wanted a solution to reduce the congestion, without upgrade and not
reducing traffic.
Null
3. Cause Analysis
Information from the customer shows that they have new marketing campaign to
increase the UL throughput of the user. They change the profile in PS core network
(PCC/PCRF & HLR). Previously it was set UL maximum bit rate as 256kbps then
changed become 1Mbps.
This causing the UL traffic significantly increased. And as the UL traffic increase, the
UL CE congestion increased.
As in the table above, UL 128 kbps in R99 consumes 10 Credits, while in HSUPA
consumes 4 or 8 Credits (depends on the SF). Also for other rate, HSUPA consumes
less Credits / CE compare to UL R99.
4. Handling Process
Knowing the fact that lower UL CE consumption in HSUPA compare to UL R99 for the
same bit rate, we tried to shift the UL traffic from R99 to HSUPA, hoping that HSUPA
less CE consumption and CE congestion reduces.
In order to do this, this is the parameter used:
Before: ULBETRAFTHSONHSUPA = D608; After: ULBETRAFTHSONHSUPA = D64.
After the parameter implementation, as expected, the traffic from UL R99 shifted to
HSUPA.
As we can see from the chart above, the traffic only sifted. the decrease of R99 traffic
is equal to increased of the HSUPA traffic.
After the traffic shifted to HSUPA, the UL CE congestion reduced. See figure below:
Point 1 in above figure shows that the UL CE congestion reduce (blue line) after
the implementation, and UL power congestion increase.
Point 2 shows that the UL power congestion decreases after increasing UL CAC
parameter. (UCELLCAC: ULTOTALEQUSERNUM).
This power congestion increased due to UL equivalent user number for HSUPA is
bigger than UL R99 as in the following table:
For UL CE congestion cases, if the upgrade plan is still not yet considered as solution,
then we can shift the traffic from UL R99 to HSUPA. This method will not reduce the
traffic and can relief the UL CE congestion problem. Before using this method, make
sure that still have enough room to optimize the CAC parameter
(ULTOTALEQUSERNUM), because it will increase the UL equivalent user number.
Analysis Report for bad IFHO SR in one RNC after 2nd carrier
Title
Implementation
Keywords WCDMA IFHO SR

Case is Update
from Time
Product
RAN Product RAN
Family
Case5 Analysis Report for bad IFHO SR in one RNC after 2nd
carrier Implementation
In country I, operator H project, customer and core performance team informed the
issue of Drop Call Rate increasing.
RNC version: V900R013ENGC00SPH532
Work Mode: UO
Null
3. Cause Analysis
F1 IFHO SR in RNC XYZ after 2nd carrier implementation was Zero.
4. Handling Process
1. RNC Level: We done RNC Level audit and make sure below parameter must be
TRUE
SET UCORRMALGOSWITCH: HoSwitch=HO_INTER_FREQ_HARD_HO_SWITCH-1;
2. Cell Level:
HHO Counter check: We check HHO attempt for F1 & F2 and found there was
no Attempt for F1, either for F2 the attempt and success was ok.
VS.HHO.SuccInterFreqOut
VS.HHO.AttInterFreqOut
3. LDR Audit: We done Cell Level audit and found below setting for F1& F2
Non 2nd carrier:
DL = Code Adj BE Rate Red CS IRAT PS IRAT
UL = BE Rate Red CS IRAT PS IRAT
2nd carrier:
DL = Code Adj Inter Freq BE Rate Red CS IRAT PS IRAT
UL = BE Rate Red Inter Freq CS IRAT PS IRAT
We modify F1 LDR setting same like F2: Make sure the DL/UL Second Action
must be InterFreqLDHO.
Script:
MOD UCELLLDR: CELLID=xyz, DLLDRFIRSTACTION=CodeAdj,
DLLDRSECONDACTION=InterFreqLDHO, DLLDRTHIRDACTION=BERateRed,
DLLDRFOURTHACTION=CSInterRatShouldNotLDHO,
DLLDRFIFTHACTION=PSInterRatShouldNotLDHO, ULLDRFIRSTACTION=BERateRed,
ULLDRSECONDACTION=InterFreqLDHO,
ULLDRTHIRDACTION=CSInterRatShouldNotLDHO,
ULLDRFOURTHACTION=PSInterRatShouldNotLDHO;
After LDR modifcation: IFHO SR back to Normal.
At RNC Level the HHO Switch must be ON and at cell level the LDR Setting for F1 &
F2 must be same.
Title PS RAB access issue after implement second carrier in one NodeB
Keywords UuNoReply PS RAB DRD BLINDHOFLAG second carrier
Case code RNO-006 Case type Access/Algorithm

Case is Update
from Time
Product
RAN Product RAN
Family
Case6 PS RAB access issue after implement second carrier in
one NodeB
The PS RAB access rate decrease after implement second carrier.
DBS3900 WCDMA version: V200R014C00SPC372
Null
3. Cause Analysis
Possible causes:
1. Configuration issue
2. Hardware issue
4. Handling Process
1. Checked the performance log, the PS RAB successful rate is low, especially for
the new carries.
2. Checked the failure reason, almost all were UuNoReply:
And according to the PCHR log, almost all the failure were RB setup timeout,
from the trace message we can see after RNC sent RB SETUP, but no response
after 5 s, it failed.
3. Doubt it related to DRD, checked the DRD performance, found the abnormal:
4. According to the DRD performance, doubt that the coverage of F1 and F2 are
different. Checked the configuration, and did not find the cause, so talked again
with local team, they confirmed that the two carries in one sector use different
antennas, it caused the different coverage.
5. Suggest modifying the parameter BLINDHOFLAG to FALSE to disable the DRD.
After the modification, the problem resolved.

2013Q4 WCDMA Product Trainning Technical Cases (2013-11)

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2013Q4 WCDMA Product Trainning Technical Cases (2013-11)

Enviado por

Direitos autorais:

Formatos disponíveis

WCDMA Product Training Technical Cases

WCDMA Product Training

RNC Troubleshooting Cases ........................................................................................................... 1

NodeB Troubleshooting Cases ..................................................................................................... 29

RAN Optimization Cases ............................................................................................................... 59

RNC Troubleshooting Cases

Title CS Terminate Call Establish Failure

Keywords CS Terminate Call, Failure

Case code RNC-001 Case type Service

Case1 CS Terminate Call Establish Failure

5. Suggestions and Summary

Title M3UA and SCCP link fluctuation For PS Services

Keywords M3UA and SCCP link, PS service

Case code RNC-002 Case type Transport Link & Clock

Case2 M3UA and SCCP link fluctuation For PS Services

M3UA and SCCP link fluctuation for PS services;

The following alarms were observed.

We can perform the following steps to handle the alarm:

3) From SCTP LINK detect, it shows there is retransmission of SCTP.

4) SCTP service time.

5) M3UA LINK unavailable time as below:

5. Suggestions and Summary

Title CPU overloads issue in RNC

Keywords CPU overload, RNC

Case code RNC-003 Case type Equipment Specification

Case3 IP CPU overloads issue in RNC

CPU overload alarm: ID 1301 is reported in the RNC

4) So recommend to add another SPU board to resolve the issue.

Title Test RNC unblocked lead to SCCP successful rate low

Keywords SCCP low successful rate

Case code RNC-004 Case type Service

Case4 Test RNC unblocked lead to SCCP successful rate low

In F country, a vendor core network will swap in V network.

Low SCCP successful rate alarm

5. Suggestions and Summary

Title New integrated RNC Video call failure analysis

Keywords Video call failure

Case code RNC-005 Case type Data configuration

Case5 New integrated RNC Video call failure analysis

Video call business.

issue about bandwidth.

network sent the RANAP_RAB_ASSIGNMENT_REQ message to RNC, when

RNC receive the assignment resource of wireless, RNC feedback the

RANAP_RAB_ASSIGNMENT_RESP message to RNC, but we found in this

message including the failure information about requested information not

interface is different from the type of TRMMAP (transport resource mapping).

and the R99 CS streaming primary path are configured as AF43.

1. According to the TRMMAP Configuration Rules for IUCS interface, after we

2. Normal UE TRACE for Video call as below indicate:

5. Suggestions and Summary

Title RAB establishment failure due to CN expansion

Keywords Transport layer failure, RAB failure, CN expansion

Case code RNC-006 Case type Service

Case6 RAB establishment failure due to CN expansion

RAB establishment is transport layer and the counter VS.RAB.FailEstabPS.TNL

2. In the Hedex document, the counter VS.RAB.FailEstabPS.TNL is mainly caused

by IU interface issue. But why it only occurs on some randomly cells?

establishment failures. The cell id 40357 is there.

of them are caused by AL_L3_TRM_PEERIP_ANI_MATCHFAIL what matches

the KPI reports.

4. Check the related logs of failure reason AL_L3_TRM_PEERIP_ANI_MATCHFAIL,

and find the RAB failure message (RANAP_RAB_ASSIGNMENT_RESP) sent by