umts product training technical cases.pdf

WCDMA Product Training Technical Cases

HUAWEI Confidential

WCDMA Product Training

Technical Cases

2013


HUAWEI Confidential i

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 1

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.



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 RNC’s 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.



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


Update

Time 20130719

Product


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) Iu some RNC configuration change cause the paging SR decreased;

2) PCH has congestion;

3) Paging message discard due to the flow control;

4) 2G and 3G has the same LAC area;

5) Wrong paging message send from the CN.

4. Handling Process

1) Paging SR was dropped at the 19 Feb, check the RNC operation log, there is no

any LAC/RAC modification.

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



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.

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

7) Discuss with MSC engineer and confirm the abnormal LAC belong to the 2G,



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

normally.


KPI decrease suddenly，check the operation of the network firstly. Exclude RNC and

Cell PCH congestion possibility of doubt, Iu trace is good way to analysis.



Title IP Overbooking activation causing abnormal CS calls and PS calls

Keywords IP Overbooking

Case code BSC6900-003 Case type Data Configuration

Case is


Update

Time 20130621

Product


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



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.



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;





















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.



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


Update

Time 20130522

Product


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.



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 didn’t 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 didn’t 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



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 didn’t 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 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


Update

Time 20130520

Product


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



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.



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.



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.




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.



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


Update

Time 20130520

Product


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




M3UA Link Fault 4/12/2013 6:35 4/12/2013 6:45




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



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



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.



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


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.



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



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.



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


Update

Time 20130815

Product


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 3–4 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).



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.



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


Update

Time 20130803

Product


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.



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

NodeB Service IP NodeB Service

Gateway to RNC

NodeB OM

Logical IP

NodeB OM Port

IP

NodeB OM

Gateway

10.237.163.230 10.237.163.229 10.237.163.235 10.237.163.234 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.



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.



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


Update

Time 20130205

Product


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.



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



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.



Title CPU Overload Leads to Abnormal NodeB Reset

Keywords CPU overload, abnormal NodeB reset

Case code NodeB-005 Case type Service

Case is


Update

Time 20130205

Product


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.



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 NodeB to version DBS3900



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



Title 3G Cells Cannot Setup

Keywords MTU Size

Case code NodeB-006 Case type Data Configuration

Case is


Update

Time 20130822

Product


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.



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.



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


Update

Time 20130802

Product


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





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



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



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



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.




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.



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


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:



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.



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


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




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



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:



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.



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


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



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.



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



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



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, that’s 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



the new scenario. When it is well known that traffic condition in an RNC will change

(As during Chrisman’s eve, Summer time, special event), it is recommended to health

check RNC to avoid service degradation due to congestion.



Title PS performance degradation under RNC 'X'

Keywords PS degradation

Case code RNO-005 Case type Service

Case is


Update

Time 20130503

Product


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.




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



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.



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.




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.



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


Update

Time 20130426

Product


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.



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.




1. Temporary Solution: Temporary modify the TRMFACTOR

2. Solution: Expand the transmission bandwidth

umts product training technical cases.pdf

Documents

nodeb troubleshooting

optimization cases

ps calls

ps traffic problem

high cpu load

packet loss rate

abnormal cell kpis

abnormal nodeb reset