wran troubleshooting cases- rno&rnp

The Cases About WCDMA RNP&RNO 档级：

2009-1-23 华为机密，未经许可不得扩散第 1页, 共 18页

Title Analysis of E220 downloading throughput problem

Product Family WCDMA-RAN Product WCDMA-RNC

Phenomenon

Description

H country V operator E2E engineers tested the Huawei E220 modems with a new firmware

release (11.117.09.04.00.B268 ), which made the modems work as R6 UE

with max.bitrate 7.2 Mbps. The test was successfuly completed by the middle of January, so

the throughput was measured between 4 - 6 Mbps depending on the radio and other condit

ions. But since last week we were informed that they could not reproduce this throughput a

nd the bitrate was always

under 3.6 Mbps. They also found that the R7 UEs (Huawei E270, “Z” company USB stick wi

th HSUPA) worked properly, max bitrate was able to reach the 4-6 Mbps, while E220 could

not.

Alarm

Information Null

Cause

Analysis

Based on the description provided by customer, we thought the following reasons may resul

t in the problem.

1. test condition--whether the problem only occured in some specific place?

2. UE firmware version, whether the firmware version resulted in the problem? or some func

tionality affceted the speed?

3. some operations had been done in system? e.g. RNC upgrading or some parameters mo

dification?

4. some unknown reason.

Handling

Process

1. since this problem occured in customer's building(which belongs to RNCM), so we sugge

sted them change to another place(Which belongs to RNCN) to do the test. the max speed

could be up to 6.17mbps; so the firmware version did not affect the problem.

2. Tested with Huawei E270 and “Z” company R7 terminal, both the max speed can be mor

e the 6mbps.

3. Analysised the upgrading impact(which was also the biggest suspicion by customer) .bec

ause the problem happened just when we upgraded the RNC from V29065SP01 to V29065

SP02. We did the test in testbed(the RNC version was V29065SP01). The result proved tha

t the upgrading did not affect the problem.

4. The difference between E220 with E270 and “Z” company R7 terminal is that E220 can n

ot support HSUPA. We got the trace of Huawei E220, and checked the transminitoin

of downloading and uploading, and found that there were only 153 PDUs re-transmited, and

the total PDU number was 290606. The re-transmiting was very low. It was about 153/2906

06 = 0.000526. So the downloading quality was good. Also, when testing the E270 and “Z”

company HSUPA, the average upload

thoughput was about 0.1mbps. But the E220 upload thoughput was about 0.07mbps.

5. Also E270, the uplink throughput was about 0.1Mbps. And E220, the uplink throughput w

as about average 0.05Mbps. Maybe the Uplink speed is not enough for downlink? So it was

necessary to check the uplink transmission between HSUPA and uplink DCH. From the log



of E220, we found that, there were always many times ACK message send from E220 at

the same time. And from the User Plane of E220 downloading, we found that, the delay of u

plink was not good, and it was always about 500ms, sometimes it reached 600ms.

So, when using the DCH for uplink, the delay was much longer, and the throughput was mu

ch lower. To prove it was not UE problem, we used E270 to download in the cell with HSUP

A

had been deactivated. And found that, the throughput was much worse than the HSUPA ha

d been enabled. Also, as mentioned above, the E220 throughput was much higher in RNC

N

than that in RNCM. So, what was the difference between RNCM and RNCN? comparing R

NCM configuration with RNCN, finally, we found that, there were some Uplink DCCC param

eters difference(Which you can see in the attachment).

These modification was made 5 days ago to solve the CE congestion problem in RNCM.

When the CE congestion problem solved, we changed back the DCCC parametes, the thro

ughput problem solved.

The MML commands(Which you can see in the attachment) to solve the problem.

Suggestions

and Summary

1. when we meet such problem, try to reproduce the phenomenon in different condition and

find out what's the difference between the conditions;

2. pay attention to the operation in the system and be aware of the impact of each operation



Title

Inconsistency of LAC and RAC in Huawei RNC and Another Manufacturer's

Core-Network [HLR] Network Element causes failure of 3G - 3G Incoming Voice &

Vedio Calls at NodeB Cell Site


Phenomenon

Description

During integration of Huawei RNC Version BSC6800V100R008 with another manufacturer's C

ore-Network [CN] MSC-HLR equipment, for 2 different regions in a country,

the subscribers in the 2 diffrent regions experienced failure with Incoming [3G - 3G] Voice and

Vedio calls and cannot receive any vocie and vedio calls on their UE in 3G, at any of the Node

B cell Sites.

Alarm

Information Null

Cause

Analysis

Inconsistent configuration of LAC and RAC on another manufacturer's Core-Network MSC-HL

R equipment causes failure of incoming 3G - 3G voice and vedio calls at all the NodeB radio c

ell sites.

Handling

Process

1. Create an Iu Signaling Tracing Task for the incoming call.

When the called UE is in Idle mode or Cell PCH mode, it was observed that

there was NO RANAP_PAGING from another manufacturer's CN [Core-Network] equ

ipment.

2. Create an Iu Signaling Tracing Task for the incoming call when the called UE is in Ce

ll_DCH OR Cell_FACH State,

it was observed also that there was NO RANAP_PAGING from the other manufactur

er's CN [Core-Network] equipment.

3. Check the congiigration between Huawei and Other

Vender, Inconsistent configuration of the LAC and RAC in the other manufacture's C

ore-Network HLR database was

found, whose data negotiation was inconsistent with the RNC & NodeB Radio Networ

k Layer.

4. After the LAC and RAC on the other's Manufacturer Core-Network Equipment MSC_

HLR Network Element are modifed according to the parameter of Huawei,

the incoming 3G-3G Voice and Vedio calls were tested and confirmed to be successf

ul in both regions. Now the incoming call issue has been solved successfully!

and we can now receive RANAP_PAGING from the other Manufactuerer's Core-Net

work CN.

Suggestions

and Summary

Incoming Calls and Outgoing Calls Signaling test should also be performed for the UE fo

r the following call scenario to ensure there are no outgoing and incoming call-issues:

(1.) 2G - 3G

(2.) 3G - 2G

(3.) 3G - 3G

(4.) 2G - 2G

The outgoing and incoming call scenario was tested and successful for all the above inco



ming and outgoing call scenario.



Title Call drop due to faulty uplink PA in repeater site

Product Family WCDMA-RAN Product WCDMA-NodeB

Phenomenon

Description

23480 is an indoor site for providing 3G coverage to the platform & tunnel of MTR station. C

all drops always happened near the tunnel portal of MTR station.

Alarm

Information N/A

Cause

Analysis

According to the drive test data, the downlink signal quality is good (RSCP:-72.09dBm & Ec

/Io: -3.51dBm) when call drop happened. However, the uplink power of UE reached maxim

um 24dBm. This indicated that the uplink path is much more poor than the downlink path.

Handling

Process

After discussion with Customer’s engineer, the MTR tunnel is covered by using AIU. We sug

gest Customer to coordinate with MTR side to check the uplink PA of AIU.

After checking, it was found that the uplink PA was faulty and then replaced. After that, we h

ad arranged another drive test and no call drop were found near the tunnel portal of MTR St

ation.

Suggestions

and Summary

When you observe the uplink & downlink power do not have same converge when call drop

happened.

You should check whether the area is covered by a repeater sites and then check if the call

drop is due to Amplifier’s problem.



Title Cell 12674-CELL HSDPA、、、、HSUPA Setup Failed with reason code is Local Cell

hsdpa Non Capable


Phenomenon

Description

We tried to configure and activate the cell HSDPA for 2 cells (cell id 12674 and 12675) for a

NB 702930A.

The cell 12675 HSDPA cell status is normal but cell 12674 were failed in the HSDPA. The re

ason code is "Local Cell hsdap Non Capable".

The NB version is V18, and we suspected that the failure is due to below setting:

DL BB Resource Allocation Mode = UNLIMITIED

Alarm

Information None

Cause

Analysis

After checking the command manual online help and the discussion with the HQ TSD, it is c

onfirmed that the cell setup failed is

due to there are non-H board (NBBI) in the NodeB and the setting of "DL BB Resource Alloc

ation Mode = UNLIMITIED".

For the board in the NodeB for downlink resources, the NBBI and NDLP can only supported

R99 service. To support HSDPA service,

HBBI or HDLP are required.

But if a NodeB with both type of boards, (e.g. NBBI + HDLP), then it is needed to use this p

arameter "DL BB Resource Allocation Mode" to control.

It is a new parameter in V18/V19 NodeB. When it is set to UNLIMITED, then locell will be as

signed to any downlink resources board,

and if the cell is set to NBBI/NDLP, then the cell cannot support HSDPA service. To ensure t

he locell always assign to a HSDPA board,

it is needed to set the parameter to "INHBOARD".

In Version V18,V19 ，

If the Locell will use the HSDPA function. The paramter DL BB Resource Allocation Mode =I

NHBOARD must be

choosed when add LOCELL.

When Upgrade from V17 to V18 or V19, if the Locell's HSDPA function is enable, the upgra

de rule will setting DL BB Resource Allocation

Mode to INHBOARD automatically.

Finally, this setting only affects the downlink resources, for the uplink resources, there is onl

y one uplink resource group in the NodeB,

and the RM will assign the uplink resources according to the service type automatically.

Handling

Process

Modify the setting of the local cell from "DLRESMODE=UNLIMITED" to "DLRESMODE=IN

HBOARD", then the problem can be solved.

Pls. note that this change required the cell not in active state.

Suggestions

and Summary None



Title function of Hysterisis for 1A event report


Phenomenon

Description

In the following formula of the definition of 1A event report, since (R-H/2) can be regarded a

s a Rnew, why we still need to set separately R and H parameter? What is the function of th

e H parameter?

figure is in the attachment.

Alarm

Information NA.

Cause

Analysis

1. Let's see the mechanics of UE measurement report of 1A, take Ec/No as the measureme

nt quantity:

UE will maintain a table of TRIGGERED_1A_EVENT after getting measurement control me

ssage of 1A, there are 2 variables "cells recently

triggered" and "cells

triggered", if a neighbor cell (cell A) satisfy the following formula:

in the attachment (1)

If the cell (cell A) is not in the "cells triggered", then the cell will be put into "cells recently trig

gered", and UE then will report 1A for the cell (cell A), and then

transfer the

cell(cell A)into "cells triggered" and set the reported number to be one; If the cell is already i

n the "cells triggered" UE will not trigger 1A report.

If periodical report mode is set for the UE, then every Reporting interval UE will report a 1A r

eport, and increase the reported number with one, if the

reported number

is equal to amount of reporting, UE stop report 1A.

But if the cells in the "cells recently triggered" or "cells triggered" satisfy the following criteria

:

in the attachment(2)

Then the cells will be removed from the two sets and UE stops periodical reports until next

moment when the cell satisfy criteria (1).

We can draw the following conclusion, if the cell is in "cells recently triggered", it is in a state

which satisfy criteria (1) but yet no report for the cell . If the cell

is in "cells

triggered", it is in a state which the UE has at least report 1A once for the cell, but the cell d

oesn't satisfy criteria (2).

Handling

Process

An example:

refer to attachment

In the figure, if we do not consider Time to Trigger.

At T1 UE report 1A, because of the H, UE will not report 1A between T1 ～

T2 even the quality of the cell satisfy (1) for 2 times, periodical report is possible (only if ena

bled), since the cell is already in the "cells triggered". After T2,

the cell is

remove from the 2 sets and at T3 new report will be triggered.



According to the analysis, H is used to prevent 1A ping pang reports. Obviously if H is set to

be zero in the example, there will be several times of 1A

between T1～T2.

Suggestions

and Summary

The main purpose of this H is to prevent ping pang 1A to decrease any unnecessary reporti

ng messages from the UE. Besides this, we can have time to

trigger to have the same function.



Title HSPA Iur Handover failure


Phenomenon

Description

During BSC6810 acceptance tests, we tried to perform HSDPA handover through Iur, but de

spite the UE sent measurement reports (1A) for radio link addition,

the RNC never added the new link to the active set.

Alarm

Information

On the traces we couldn't see any failure, the call drop was due to bad radio conditions bec

ause the better link wasn't added.

Cause

Analysis

As through the signalling everything was ok, we tried to analyse the user plane side. We us

ed two RT AAL2PATHs for Iur data.

After we check the Transport Resource Mapping configured on the RNC (ADD TRMMAP) w

e found out that the HSDPA/HSUPA interactive primary path was

set to ATMHDNRT, because we used the same TRMMAP as for Iub (for Iub we use 1 PATH

for CS, 1 for HSPA and another one to R99 PS).

But as for Iur we haven't HSDPA NRT PATHs the user plane couldn't be right mapped.

Handling

Process

After we changed the HSDPA/HSUPA interactive primary path to ATMRT, the Handover wa

s successfully performed.

Suggestions

and Summary None



Title Hsupa service cannot exeed 384Kbps


Phenomenon

Description

the Hsupa cell is setup normal but when using UE type E270 we cannot exeed 384 Kbps at

FTP upload we have cheked the CDT the UE sends the Hsupa capability but

the service is not setup on E-dch channel

Alarm

Information None.

Cause

Analysis

After analyzing the CDT trace we know that the UE can support HSUPA "found in the RRC

CONNECTION REQ message" & the HSUPACell is setup properly and

using the script, we found TYPRAB31 has not actived, this RAB is 1536K speed for uplink.

we can reffer to the following file: HSUPA Basic Signaling Flows,

we can find this information in the MMLCFG file uploded from RNC :

ACT TYPRAB:RABINDEX=30;

ACT TYPRAB:RABINDEX=32;

we can see that TYPRAB31 is not activated

so the cause was that the TYPRAB (1.5 Mbps) bearing this service wasn't activated

Handling

Process

after executing the MML in RNC LMT "ACT TYPRAB: RabIndex=31;"

then the corresponding TYPRAB31 activated , the HSUPA service can be used , and the sp

eed is 1.3Mbps and reaches a peack of 1.4Mbps.

Suggestions

and Summary

the Hsupa cell is setup normal but when using UE type E270 we cannot exeed 384 Kbps at

FTP upload we have cheked the CDT the UE sends the Hsupa capability but

the service is not setup on E-dch channel

After analyzing the CDT trace we know that the UE can support HSUPA & the HSUPACell i

s setup properly and using the script, we found TYPRAB31 was not actived,

this RAB is 1536K speed for uplink.

we can check this document for more detailed information about the UE capabilies and HS

UPA cell signaling.



Title Inter-RAT CS Handover Failure from WCDMA(3G) to GSM(2G) caused by AMR

Activation Codec Issue of Ericsson 2G MSC Server


Phenomenon

Description

After the Successful Iu_CS integration of Huawei RNC V1.8 (BSC6800V100R008C01B082)

to E-vender Core-Network for a particular telecomms operator, there was a failure in the Int

er-RAT CS handover test from 3G(WCDMA) to 2G(GSM). The UTRAN was Huawei, the 3G

MGW & MSC Server was E-Vender, the 2G MSC was E-Vender, while the 2G BSC was Hu

awei.

Alarm

Information None

Cause

Analysis

During the CDT signaling trace, "relocation-failure-in-target-CN-RNC-or-target-system" caus

es RANAP_RELOCATION_PREPARATION_FAILURE.

Handling

Process

(1.) Start the CDT Signaling trace.

(2.) RNC sends a RANAP_RELOCATION_REQUIRED signaling message to CN. Here Sou

rce ID and Target ID are correct.

(3.) CN replied with a RANAP_RELOCATION_PREPARATION_FAILURE.

(4.) Checked this RANAP_RELOCATION_PREPARATION_FAILURE

signaling message from CN, the cause for the failure was found to be a "relocation-failure-in

-target-CN-RNC-or-target-system".

(5.) Mobilized for resources to trace the 4 NE signaling message exchange and analyze the

trace in the Source and target system.

(6.) Signaling traced on E-Vender

2G MSC showed that it Seems at HO to 2G, the 2G network does not know the service clas

s of the Multi RAT mobile as such it wants to maintain the current 3G speech version (AMR)

which it does not have as such it responded back with no radio resource.

i.e: "no radio resource message"

(7.) The License on the GBSC (Huawei 2G BSC) was displayed and can support 3G Capaili

ties as follows: So the license is ok.

SUPPORT INTER-RAT HandOver: Yes

CONFIGURED INTER-RAT HandOver: Yes

(8.) The GSM cell parameters on the 2G BSC was checked and found to be consistent with

that on the 2G MSC, 3G MSC and RNC.

(9.) But when we checked on the 2G msc the definition of AMR to the BSC ... it was not defi

ned for that BSC.

(10.) When we activated AMR on the 2G MSC, the BSC HO is working...it means the BSC i

s already active for AMR.

Suggestions

and Summary

AMR activation should be enabled in the target system during Inter-RAT CS Handove

r Test between Huawei 2G BSC and E-Vender 2G MSC.



Title Mobile phone displays normal signal but subscriber can't make a call


Phenomenon

Description

We got a lot of complains from customer that their subscribers when go out of the city (on th

e road to another city) can receive normal signal on the mobiles but can't make at all.

Alarm

Information None

Cause

Analysis

We first though that it's some type of mobile problem but found that all mobiles from differen

t vendors.

Handling

Process

We went that place where all subscribers complained and really met the problem. As our R

NP engineer tested by his equipment signal strength and

quality was OK. Service of all sites was OK because recent drive test and performance resu

lts. So we thought that that maybe because of cell radius.

We found that it was 4000 meters. Before we configured such small coverage because insi

de the city customer had a lot NodeBs closely located to each

other. So we modified cells radius witch directed toward suburbs and roads that are located

outside of city. After that we could normally use 3G service.

Suggestions

and Summary

Corporation with RNP/RNO engineer is very important for RAN engineers for solving networ

k problems.



Title Motorola V6Rzr problem when using Notebook to connect to Internet


Phenomenon

Description

We received customer complain: Phone model is Motorola V6Rzr

(HSDPA support). When customer using GPRS or PS on the phone there is no problem.

When he connects phone to notebook and want use GPRS in 2G mode then it's OK,

but using PS/HSDPA in 3G mode is unsuccesfull.

So, from phone I can use PS on 3G, but using my computer I cannot. In attachment you ca

n find trace and error message during trying using PS using 3G mode.

In trace on line 132 we can see "QOS not accepted".

Alarm

Information None

Cause

Analysis

Because computer reporting error(see attachment) related to PS part then I asked PS engin

eer to make trace.

Handling

Process

PS product expert reviewed our problem and found the reason. As he described that SDU p

arameter for subscriber in HLR is set to 150 octets,

but mobile ones is 1500 octets. So when UE tries to establish connection and requests QO

S with size bigger than set in HLR so network rejects such connection.

When CN engineer changed in HLR QOS parameter from 150 to 1500 octets then user coul

d successfully connect to Internet through mobile phone using notebook.

Suggestions

and Summary

Need change QOS in HLR for all subscribers to let them to use such type of mobiles.

For this coorporate with CN engineer.



Title No call attemps on a cell


Phenomenon

Description

After a second carrier reconfiguration, where we changed some RNP parameters like CellAl

gosSwitch, cellHoComm, cellSelResel and intrfreqHoCov.

We found that the new cell with usually a lot of traffic, presented no call attempts at all.

Alarm

Information

We had no alarms, only through the Performance Measurement counters we detected NO

RRC Connection Request to the new cell.

Cause

Analysis

As the cell was setup and operationally everything seems to be working well we focus on th

e network planning parameters. Because the mobiles in Idle

Mode never entered in the cell even with a acceptable radio conditions.

The parameter QRXLEVMIN on CellSelResel parameter defines the minimum required RX l

evel corresponding to CPICH RSCP. The UE can camp on the

cell only when the measured CPICH RSCP is greater than the value of this parameter.

We detected that accidently this parameter was set to -18 [2dbm]. A mobile to reach the ant

enna with this signal level need to be very near the antenna, because this is a very high val

ue.

Handling

Process After we changed it back to -58 (default value) the cell becames normal.

Suggestions

and Summary

In case we don't use the default values for RNP parameters we need to be carefully with th

e optimized values otherwise it's a quite risk to use

diferent values (from the default ones).

Title RRC establishment on FACH channel causes abnormal behavior of some mobiles


Phenomenon

Description

In UTRAN Swap Project the RAN S-vender was swapped with Huawei RAN 5.1 .

The SW version of RNC is (BSC6800 V100R007C01B081).

The RNC is connected to MSC , MGW and SGSN of E Vendor

After the Swap in one region of project many users complained with customer about the fail

ure of incoming call from PSTN.

The users have the same mobile (Samsung ZGH Z220) ever since this kind of mobile are pr

ovided from a local company to their employees.

Alarm

Information None

Cause

Analysis

1. Some call handling test was carried out: call mobile to mobile, call PSTN to mobile (under

2G and 3G Coverage), call test with different type of Mobile.

Only when the Samsung mobile is under 3G Huawei coverage and receive the call from PS

TN the problem appear (every time the mobile receives the paging related to

incoming call from PSTN it reset by itself).

2. Since the problem appears only for these mobiles and no alarm on NodeB and RNC is re

lated to this mobile behaviour, we started to analyze the UE Signaling using

the Trace Task of LMT.



3. Analyzing the trace (incoming call from PSTN) we can see that CN sends the message

RANAP_PAGING to UE but after that the mobile reset. In PAGING message the

"paging Cause" is "Terminating Cause Unknown".

4. After the RNC receiving an RRC Connection Request from the UE the RNC determines

whether to accept or reject the RRC Connection Request; if it accepts the request,

the RNC determines whether to set up the RRC connection on DCH or on CCH in accordin

g to Field "Cause" contained in RRC Connection Request Message and relative

settings on RNC.

Handling

Process

1.Checking the setting about the channel type for RRC connection establishment we can se

e that is in using the default setting; it means that for Detach, Originating Low

Priority Signalling,Terminating Low Priority Signalling and Terminating cause unknown the s

et of RRC Connection is on common channel.

2. We carried out other tests in order to verify the behavior of Mobile when the set up of RR

C Connection is on CCH and the result was the same; we supposed that the

problem of this kind of mobile was the establishment of RRC Connection on CCH.

3. Changing the default settings for RRC Connection Establishment by MML SET RRCEST

CAUSE and putting the DCH instead of FACH we can noticed that the normal

behavior of mobile is restored also for incoming call from PSTN.

Suggestions

and Summary

The default settings for RRC Establishment Cause should consider that some mobiles

(propably built with some particular chipset) don’t support the

establishment of RRC Connection on Common Channel.



Title The Unstability of the HSDPA Downloading Speed


Phenomenon

Description

In a 3G project in Cambodia, HSDPA downloading speed was not stable. It kept on fluctuati

ng. Sometimes, there was no data transmission even there was only one user in the NodeB

.

RNC version: BSC6800V100R006C01B082

NodeB version: DBS6800V100R008C01B063

The conditions of the HSDPA test:

1. HSDPA USB modem model: E270 (7.2M)

2. SIM card: 10M/3M (DL/UL)

3. Number of E1s connected to the NodeB = 5

Alarm

Information Null

Cause

Analysis

1. The uplink and downlink BLER, PCPICH Ec/No, RSCP, UE Tx Power, UL SIR, RTWP, do

wnlink throughput and bandwidth were check:

UL BLER = DL BLER = 0

PCPICH Ec/No = from -2 to -8 dB

RSCP = -55dBm

UE TX Power = - 30 dBm

UL SIR = 2 to 4

RTWP = - 106 dBm

Downlink bandwidth = 7.2 Mbps

Downlink throughput = not stable and cannot achieve high data rate.

All the condition above showed that the wireless environment was so good but the downlink

throughput was not stable.

2. The configured AAL2PATH was checked.

Number of AAL2PATH configured = 4 (one R99 RTVBR, one R99 NRTVBR, one HSDPAPA

TH RTVBR and one HSDPAPATH NRTVBR-UBR)

PCR (kbps) = 9600, SCR=RCR (kbps) = 9600, CDVT(0.1us) = 10240

This showed that the configured AAL2PATH was enough and correct.

3. There was no problem at the RNC side. Therefore, the PS part was checked.

It was found that the problem existed at the PS domain. The SGSN, GGSN and Firewall we

re connected to a LAN switch physically.

At GGSN, the Ethernet cable to the LAN switch was configured as 100M full-duplex. At the

LAN switch, there was a bug in which the configuration there was 100M half duplex by defa

ult, but in fact, it should be configured as 100M full duplex by default.

Therefore, the LAN switch was configured using the serial port and the hyper terminal of the

computer so that the Ethernet cable was configured as 100M full duplex.

After that, the data rate of HSDPA was very stable, and the average data rate for 3 E1s and

5E1s were 4.5 Mbps and 6.5 Mbps respectively.



For the 5E1 case, the average data rate that could be obtained was 6.5 Mbps since the HS

DPA terminal (E270) that was used supported a maximum data rate of 7.2 Mbps only.

This was a common case because the maximum speed usually could not be reached. The

efficiency of this E270 in this test was 6.5/7.2 = 0.93 (or 93%).

Handling

Process

1. Configure the port at the LAN switch (which is connected to the GGSN) using the serial p

ort and the hyper terminal of the computer,

so that the Ethernet cable was configured as 100M full duplex.

2. We have to make sure a full duplex transmission in between the SGSN and LAN switch, t

he GGSN and LAN switch, and the Firewall and LAN switch.

This full duplex configuration at both side (PS equipment and LAN switch) is vital to make s

ure a high efficiency of data transmission from SGSN to GGSN and subsequently to the Fir

ewall,

so that the packets can be sent from the RNC to the internet smoothly.

The connection of the equipment is as following:

RAN ---- SGSN --- GGSN --- Firewall ---- Internet

Logically the SGSN, GGSN and Firewall are connected as shown above. But in fact, three o

f them are connected to a LAN switch physically.

3. Sometimes, this unstability and low speed of the HSDPA service are caused by the follo

wing reasons:

a) HSDPA maxbitrate is limited by AAL2PATH parameter RECEIVE CELL RATE (RCR).

Thus, it has to be configured according to the availability of the E1s.

b) High pilot channel power (more than 33dBm) should be configured to ensure a high SI

R (Signal Interference Ratio).

c) SGSN has two engines (UHPU engine A and UHPU engine B) and RNC has two WHP

UIP. Hence routes to all SGSN engines has to be configured in WHPU board subsystem.

d) Availability of CE (Channel Element) in the NodeB.

e) Status of the CELLHSDPA (actived or not actived)

f) At least three AAL2 paths have to be established on the Iub interface. Among these thre

e AAL2 paths, one is R99 path and the other two are HSDPA paths

which carry HSDPA RT services and HSDPA non-RT services respectively.

Suggestions

and Summary Null



Title why need configure The range of PlmnValTag


Phenomenon

Description

When we configure the LAC、

RAC, we can find that we should configure the PlmnValTag value, it says this kind of vlaue

should be defined by the operator according to the LMT help information,

but what's the use of this value?

Alarm

Information Null

Cause

Analysis

According to the protocol, UE will monitor the value tag to update system information. The P

lmnValTag is this value tag configured in RNC,

if RNC send the new system information and ask UE to update, the RNC will circularly chan

ge the value tag in configured range.

It should be different for value tag range in different LAC and RAC to guarantee the UE can

correctly update the system information when cross the boarder.

Handling

Process

Negiotiate the value with the customer, normally we set the value each 10, for example, AD

D RAC: CnOpIndex=0, LAC=H'2506, RAC=H'00, PlmnValTagMin=1,

PlmnValTagMax=10;

Suggestions

and Summary

We should understand the meaning of the parameters when we commisioning the equipme

nt.

wran troubleshooting cases- rno&rnp

Documents