GPRS Typical Cases Analysis

GPRS Typical Cases Analysis

ZTE university

Purposes

After learning the course, you will: Be familiar with GPRS trouble-shooting methods Command GPRS CQT&DT OMC analysis methods Command GPRS signaling tracking analysis methods

Contents

ATTACH FailurePDP Activation FailureWAP FailureFTP FailureOther Failures

Overview ATTACH Failure

Attach Failure FeaturesAttach Failure Features Attach success rate is low and delay is longAttach success rate is low and delay is long

Reasons for Attach Failure

Subscriber’s Failure MS doesn’t support GPRS or has no GPRS MS isn’t compatible with network’s

equipment MS accessing authority is restricted Too frequent cell reselection

causes instable attach

or untimely

Network Failure

Network has no GPRS

Network hasn’t been allocated

GPRS resources or GPRS resource

isn’t enough

Signaling data transfer failed

Weak coverage Cell has co-channel interference, adjacent interference or

external interference Cell congestion causes untimely response to attach request Busy system or slow response impacts logon efficiency

Radio Environment

Failure

Overview ATTACH Failure

Solutions for Attach Failure turn off SGSN authority;

use one-step accessing mode;

check coverage;

prevent frequent cell reselection;

trouble shoot to improve C/I； check RACH or AGCH configuration;

check GPRS ENABLED setting;

check Gb links load and adjust NSEI configuration;

GPRS core network modification.

MS cannot logon GPRS ATTACH Failure

Failure Description: In one network, subscriber fails in

MS GPRS Attach. MS sends Attach request, then

SGSN sends back attach accept

message, but BSC sends LLC

unknown information signaling.

Failure Description: In one network, subscriber fails in

MS GPRS Attach. MS sends Attach request, then

SGSN sends back attach accept

message, but BSC sends LLC

unknown information signaling.

Solution:

Turn status of P-TMSI from

disable to enable and then the failure

is solved.

Failure Analysis: According to signaling flow, BSS is in

charge of TBF flow establishment, and

then MS exchanges signaling with SGSN;

in normal flow, MS sends Attach complete

to SGSN. Related BSC data have no problem. From global test we can see that the

same failure occurs in sites controlled by

all BSC that connect with SGSN, so we

initially estimate it is SGSN problem. After checking we see modification that

is status of P-TMSI is changed from initial

enable to disable that causes P-TMSI

can’t allocate and subscriber can’t use

GPRS

ATTACH Failure

Problem: frequent cell reselection (60021→60332→60021) causes too

long ATTACH delay (14.55s).

Solution: raise 60021CRH from 8dB to 10dB, adjust

60332RXLEVACCESSMIN from 10dB to 12dB.

ATTACH Failure

ATTACH Failure

Problem: network sends Packet Access Reject message to MS as the response to

Packet Resource Request message, which includes “Wait_Indication” whose value is

T3172; MS starts up T3172 when receiving Packet Access Reject message, during T

3172 operation, network doesn’t allow MS to reattempt packet access in one cell. This

problem is caused by tight radio resource.

Solution : expand statistic PS channel.

ATTACH Failure

Contents

ATTACH FailurePDP Activation FailureWAP FailureFTP FailureOther Failure

Overview PDP Activation Failure

PDP Activation

Failure Features

PDP Activation

Failure FeaturesLow success rate of PDP activation, PDP

activation failure, long PDP activation time

Low success rate of PDP activation, PDP

activation failure, long PDP activation time

Reasons for PDP Activation Failure

MS Failure:

APN set incorrectly; OoS mistake; PDP address mistake; MS isn’t compatibly

with network

Radio Network Failure: Weak radio

network signal; Interference; Unavailable radio resource or

congestion.

Core Network Failure:

DNS translation failure;

GTP failure between SGSN and

GGSN

Frequent Route Update:The area is located on

edge of LAC, route

update causes

unsuccessful PDP

activation or too long

delay

Overview

Solutions for PDP Activation Failure check coverage;

prevent frequent cell reselection;

trouble shoot to improve C/I;

check RACH or AGCH configuration;

check Gb links load and adjust NSEI configuration;

set T3168 timer reasonably;

check GPRS parameter setting, set BSC parameter DRX_TIMER_MAX r

easonably;

turn on SGSN cache to shorten DNS translation time;

check GGSN processing function, improper DHCP or RADIUS server con

figuration or powerless GGSN processing ability may cause slow PDP activ

ation or even PDP activation failure.

PDP Activation Failure


Problem: PDP activation failure is caused by less 20281AGCH after reselect from

20022 to 20281.

Solution: control 20281 coverage extension and increase number of 20281AGCH.



Problem: due to continuous twice cell reselection (CELLID: 10071 Channel:2—

CELLID: 111 Channel:90—CELLID: 114 Channel:512), PDP failure is caused by n

o available timeslot during a long period of time.

Solution: raise 60021CRH from 6dB to 10dB.



Problem: PDP activation failure is caused by no PS channel.

Solution: increase 8540 site’s statistic PS channel and adjust MFR from 5 to 2.



Problem: PDP activation delay is occasionally too long in CQT. 7 abnormal dela

ys occur in 100 times PDP activations in 10 nodes, which is shown in the followin

g tables.


PDP Activation Failure PDP Activation Failure


Failure

analysis:


From the test result we can see that time is mainly consumed below Gb interface as well as betwe

en Radius and WAP gateway. The sixth time consumption between GGSN and Radius is relativel

y long, because the first Accounting Request message sent by GGSN isn’t received by WAP gate

way due to the lost of Accounting Request message in transfer or Radius abnormal processing.

The other six failures are due to too long time consumption below Gb interface as well as betwee

n Radius and WAP gateway. GGSN sends Accounting Request message to Radius, waits for resp

onse from Radius and starts up corresponding wait timer; corresponding WAP gateway doesn’t r

esponse after receiving Accounting Request message. Then wait timer is overtime because GGS

N doesn’t receive response, the Accounting Request message, and then GGSN resends Accountin

g Request message; this time corresponding WAP gateway gives response and GGSN receives A

ccounting Response message transmitted by Radius, and GGSN begins to response to MS PDP a

ctivation request.

TBF resource is released due to overtime timer caused by too long time consumption on Gi interf

ace, therefore MS reestablishes TBF while receiving PDP activation accept message, which furth

er increase time delay on radio interface.

Therefore we can see that the fundamental reason for too long time delay in PDP activation is too

slow WAP gateway response.

Contents


Overview WAP Failure

WAP Failure Features:

low success display rate of WAP front page;

long display time of WAP front page;

low success refresh rate of WAP pages;

long refresh time of WAP front page.

WAP Failure Reasons:

Radio coverage problem, interference, cell res

election failure;

Data configuration mistake on two ports of G

b interface;

Too long WAP gateways connection;

WAP parameter setting mistake.

Solutions for WAP Failure:

Optimize WAP gateway;

Optimize GPRS core network;

Check coverage;

Prevent frequent cell reselection;

Carry out trouble-shooting to improve C/I;

Check Gb links load and adjust NSEI configuration.

Slow Download Rate of WAP Picture & Ringtone

Problem: through analysis we see RLC data retransfer ratio is high, Gb link l

oad reaches as high as 64% in test period from OMC statistic data that causes

low download rate.

Solution: readjust NSEI to decrease Gb link load and improve GPRS CQT d

ownload rate.

WAP Failure

WAP Logon Failure

Problem: WAP logon test in ** hotel, after tracking Gb interface we figure out th

at on uplink MS sends Get (URL=http://wap.monternet.com) and network replies a

PDU with the contents of “Your request for a service could not be fulfilled, please t

ry again or contact your operator if the Failure persists”. This problem is caused b

y failures in moternet server.

Solution: require cooperation from core network engineer through negotiation.

WAP Failure

Too Long WAP Logon and Refresh Delay

WAP Failure

Too Long WAP Logon and Refresh Delay

M

I

S

C

Accounting Res.

Accounting Req

Access Accept

Access Request

Active PDP

context accept

Active PDP

context request

Attach accept

Attach request

Ack

Reply

get

Ack

Connect reply

GPRS

核心网

Wap

网关

Connect

SP

get

Reply

P

C

U

R

A

D

I

U

S

WA

P test signaling flow

Problem: through signalling analysis

we figure out gateway response time

prolongs between CONNECT to CONNE

CT REPLY and between GET to REPLY;

GET request needs to retransmitted and

there is even no response; long signaling

delay occurs especially between GET an

d REPLY and sometimes even reaches t

ens of seconds that largely impacts MS a

ccessing rate to WAP;

Solution: core network engineer

optimize WAP gateway.

WAP Failure

Problem: after MS gets required webpage, WAP gateway replies “URL NOT

EXIST” message, which is the response of WAP gateway after it receives “servi

ce temporarily interrupted” message from SP server.

Solution: this test will be deleted in CDS by processing software and isn’t rega

rded as an attempt test.

Feint Event WAP Failure

Contents


Overview FTP Failure

FTP Download Failure Features: High RLC retransfer ratio

TBF drop and longtime transfer interruption

Slow FTP download rate


Reasons for FTP Download Failure

Network resource

utilization status

Lack of PDCH and

unreasonable logic

channel setting

Impact of cell reselection

rate to GPRS data transfer

Impact of coding mode

Impact of

RLC/MAC block

retransfer ratio

Weak server cell signal

and severe interference

Impact of C/ I to data

transfer

Impact of TBF and

its parameter setting

T3168 and T3192 are set

unreasonably; T3198

and BS_CV_MAX are set

unreasonably.


Solutions for FTP Download Failure Optimize FTP server;

Adjust CS proportion dynamically;

Optimize coverage;

Prevent frequent cell reselection;

Carry out trouble-shooting and improve C/I;

Set T3192 timer reasonably;

Check Gb links load and adjust NSEI configuration;

Turn on CS3 and CS4.

FTP Download Failure

Problem: after MS reselects Cell41921, DL TBF hasn’t been established that

causes long-time unavailable downlink data transfer and finally PDP drop. We

check cell’s GPRS KPI during the test period and figure out downlink timeslot

congestion rate is relatively high that is the reason for no DL TBF establishment.

Solution: increase the number of the cell’s statistic PS channel.

FTP Failure


Problem: it is Inter-PCU Cell Reselection when MS reselects from CI1892 to

CI481 that causes long-time interruption of data transfer and finally PDP drop.

After checking we figure out NSEI value in CI1892 doesn’t comply with that of

surrounding sites.

Solution: adjust NSEI value in CI1892.

FTP Failure

FTP Download Rate Low

Problem: frequent cell reselection during FTP download process that causes

long-time suspend of TBF. Cell’s busy TCH makes it’s hard for MS to apply PS

channel and average download rate is only 8.11kbit/s。

Solution: expand 30553 and 30152 statistic PS channel, adjust

30553RXLEVACCESSMIN from 10 to 14.

FTP Failure


Problem: level decrease to -94dBm when MS

reselects from 43372 to 42093 and then from

42093 back to 1531 and then frequently

reselects 1531; after a while PDP drops.

Solution: control coverage of 42093 and 1531.

FTP Failure


Problem: MS frequently reselects cell 1483→18621→741 after it carries out

inter-LAC reselection from 83 to 1483 that causes long-time suspend of TBF and

finally PDP drop. We can see from the map there are elevated roads and no

master control cell beneath.

Solution: adjust 1483 CRH from 6 to 10, confirm master control cell in the area.

FTP Failure


Problem: PDCH that MS obtained isn’t stable and PS is in great demand that c

auses slow DL FTP rate.

Solution: increase the number of CI2631 statistic PS channel.

FTP Failure

BS_CV_MAX Set Unreasonably

FTP Failure

Problem description:

Data transfer rate in one cell in one GPRS network is relatively low; the cell is in

suburb and has low traffic.

Failure analysis

GPRS radio parameter BS_CV_MAX is set as 15; the area has low traffic and no

channel congestion. BS_CV_MAX is GPRS cell option parameter that helps system

to know in advance when MS ends uplink transfer and improve uplink resource utiliz

ation ratio. If value of BS_CV_MAX is set too low, MS may retransmit RLC block dat

a before network sends back confirmation message and radio resource occupation r

atio may be too high; if it is set too high, then sliding window program efficiency will

be too low and data transfer rate will get slower.

Solution:

Decrease set value of BS_CV_MAX to improve retransfer ratio. After adjust the v

alue of BS_CV_MAX to 6, transfer rate is improved obviously.

FTP Download Rate Low FTP Failure


Problem: in repetition test we figure out that in one same place, on 52484, C

1=25, C2＝ 21; the status from 15:40:33.764 to 15:53:586 lasts 20s and then t

he value of C2 raises to 53. The venue of repetition test is an intersection wher

e large car flow exists and the roads are congested, so PET＝ 20s that we pre

viously set is far more lesser than the time that we stick in the traffic jam.

Solution: set the cell’s PET as 200s and then the possibility of cell reselection

decreases greatly.

FTP Failure


FTP transfer drop goes with RAU Failure every time pass through RAC

area. After detailed analysis, we figure out data error on SGSN is the reason

for this route update failure.

These three parameters are related to GPRS route update:

(1) home location of each MSC on SGSN

(2) home location of each BSC in MSC

(3) RAC area that each cell belongs to

Normal GPRS MS route update can only be insured when the above 3

parameters comply with hardware in the existing network.

FTP Failure

FTP Download Rate Instable

Problem: In one area subscriber complains that FTP download rate varies greatly, with

the difference of more than tens of Kilobits within a very short period of time; The area is covered completely by Cell A, and this complaint isn’t appeared in

other cells, so we mainly check the difference between Cell A and other cells; We figure out Cell A’s T3168 is set as 4000ms but that of other cells is set as

1000ms. Solution:

The value of T3168 is set so high that data transfer rate is relatively high in

normal transfer; MS sends Require Packet Resource message as the response when it

receives Packet Uplink Assignment message; T3168 is started up when the

response is sent; MS doesn’t respond Packet Downlink Assignment message

when T3168 is running, therefore no downlink data are transmitted during the

time that is equal to the value of T3168, which makes low transfer rate. Modify T3168 from 4000ms to 1000ms and then FTP download rate is

stabilized and the problem is solved.

FTP Failure

Problem: vehicle drives from

North to South and passes

through the red circle covered by

Cell A; when it keeps on going to

South, level of Cell A decreases

gradually and cell reselection still

doesn’t occur when the level is

lower than -94dBm; this situation l

asts a long period and causes we

ak coverage. After checking, the c

ell reselection parameter settings

of Cell A and its adjacent cells at t

hat time is shown in the table on t

he next page.

Weak Coverage FTP Failure

Cell Name Rexlev (dBm) RXLEVACCESSMIN CRH CRO TO C2

A -103 -100 8 26 0 23

B -80 -100 8 8 0 28

C -84 -100 8 10 0 26

Solution: control the coverage of Cell High Education Scientific Research 4 (B

CCH: 560), modify CRO of Cell High Education Scientific Research 4 from 26 to

20.

Weak Coverage FTP Failure


After sniffing and analyzing packet on Gi interface

we figure out that FTP server stops sending data be

cause it receives [RESET] message after being logg

ed on. The process of FTP download test on MS doe

sn’t stop but FTP server stops transfer, therefore test

software judges failure due to overtime.

It is server logon failure due to location update, TC

P process fails due to packet lost while logging on F

TP server; the test software shows successful logon

but failed data download.

Feint Event


Through sniffing packet by test equipment we can see that FTP-DATA packet has been received successfully but hasn’t been turned to effect data that finally causes overflow in receiving window and the end of data transfer. But the process of FTP download test doesn’t stop either, and finally test software judges failure due to overtime. it is also the server logon failure due to location update, although the process of TCP and data transfer are normal while logging on FTP server, FTP-DATA still fails.

Feint Event


Conclusion: The two kinds of FTP download failures mentioned previously are all caus

ed by FTP failure that appears on TCP/IP transport layer and application la

yer instead of caused by GPRS network layer failure.

From the test software we can see that data on application layer can’t be r

eceived in the two situations while logging on FTP server, and finally FTP do

wnload fail is displayed due to overtime and it is counted as FTP download f

ailure once.

Feint Event

Contents


PING Failure 1

Problem: in Ping test, interval is set

from 4s to 12s, and the results vary

greatly. Through recording signalling in

core network we figure out the reason for

unstable Ping time delay are some

rubbish data packets appear in the test

which are caused by the automatic

update of antivirus software and other

application softwares.

Solution: reinstall operation system,

avoid from installing softwares

irrespective of test; turn off all programs

related to network communication in tray,

turn off Windows automatic update.

Other Failures

Problem: low cell’s C/I causes high BLER (cell BCCH C/I＝ 5.9). After chec

king planning data we figure out beehive 8800, 7660 and 8750 use the same BCCH. Solution: control the coverage of 8800, 7660 and 8750, adjust frequencies of 8800, 7660 and 8750.

PING Failure 2 Other Failures

MMS Transfer Failure

Problem:

The transfer success rate of MMS that larger than 15Kbits sent by Panasonic G

D88 mobile phone is relatively low; and the rate is almost 0 when the MMS is larger

than 30Kbits. But if using mobile phone of other brands, such as NOKIA 6100, the l

arge MMS can be sent both normally and fast.

Solution:

After recording signaling on GB interface we figure out Panasonic EB-GD88 mo

bile phone doesn’t completely support GSM04.60 criterion (GPRS RLC/MAC layer

criterion); it can’t support completely the site parameter settings that BS_CV_MAX=

13, 14 or 15, which is allowed in GSM04.60 criterion, and it only supports BS_CV_

MAX=1, …, 12. We suggest modifying the default value of BS_CV_MAX in the who

le network from 15 to 6.

Other Failures

MMS Receiving Failure

Problem: MS sends Get request on uplink for MMS to MMSC, but Cause val

ue in the network Reply message is 404: Not Found; it may be because MS do

esn’t pick MMS in time and MMSC deletes it after waiting for a while, then net

work replies Not Found when MS requires MMS.

Other Failures

MMS Transfer Failure

Problem: through recording signalling by signalling analyser we figure out

that MS sends PDP activation request initially, APN is CMWAP, but then MS

doesn’t send any signalling later. This situation is caused by dead MS software

process.

Solution: reinstall MS operation system.

Other Failures

Æô¶¯ Internet Explorer ä¯ÀÀÆ÷.lnk

MMS Receiving Failure

Problem: through recording signalling by signalling analyser on Gi interface

we figure out that Get request is sent time after time within around 10ms after

MS has sent Get request (Get request retransmitting timer is set as 10s) , that

makes WAP gateway have no enough time to deal with MS’s Session; from

checking retransfer interval we can see this situation isn’t caused because MS

receives MMS continuously. This situation is caused by MS software failure.

Solution: reinstall MS operation system.

Other Failures

GPRS Network Accessing Failure

Other Failures

Problem description: Some subscribers reflect the network accessing rate is slow by u

sing GPRS network card.

Failure analysis: The subscriber’s SIM card classification is high and confirmation

mechanism is used on LLC layer, so network accessing rate is slow

ed.

Solution: Check the subscriber’s PS QoS, reliability; 3 represents unconfir

med, 1 represents confirmed. GPRS network accessing rate accele

rates after mode has been modified as unconfirmed.

BVC Reset and Block Failure Other Failures

Problem description: BSC Gb interface connects successfully with SGSN on NS layer, but c

onfigured PS channel’s status is “BVC reset and block”.

Failure analysis: After checking signaling, RAC is reported mistaken. Check parameter

settings of BSC and SGSN then find out the previous two parameters a

mong the four parameters of RAC in SGSN configuration are DEC, whic

h should be HEX in SGSN configuration.

Solution: Modify the parameter to HEX and then signaling go back to normal. W

e shall pay special attention that no DEC parameters but HEX paramete

rs shall be used in SGSN configuration.

GPRS Typical Cases Analysis

Documents

pdp failure

failure analysis

ms gprs

sgsn problem

slow pdp activation

agch configuration check

gprs trouble

gprs parameter