GO - NAST3015 - E01 - 1 GPRS Typical Cases Analysis 53

GPRS Typical Cases Analysis
Objectives
 After learning the course, you will:

 Be familiar with GPRS trouble-shooting methods
 Master GPRS CQT&DT OMC analysis methods
 Master GPRS signaling tracking analysis methods
Contents
 ATTACH Failure
 PDP Activation Failure
 WAP Failure
 FTP Failure
 Other Failures
Overview
Attach Failure Features Attach

Attach Failure Features Attachsuccess
successrate
rateisislow
lowand
anddelay
delayisislong
long
Subscriber’s Failure Network Failure

 MS doesn’t support GPRS or has no GPRS  Network has no GPRS
 MS isn’t compatible with network’s equipment
 Network hasn’t been allocated GPRS
 MS accessing authority is restricted
resources or GPRS resource isn’t enough
 Too frequent cell reselection
 Signaling data transfer failed
causes instable attach
or untimely
Reasons for
Attach Failure
 Weak coverage
 Cell has co-channel interference, adjacent interference or external
Radio Environment interference
 Cell congestion causes untimely response to attach request
Failure  Busy system or slow response impacts logon efficiency
© ZTE Corporation. All rights reserved

Overview
 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
Failure Failure Analysis:
FailureDescription:
Description:
 InInone  According to signaling flow, BSS is in
onenetwork,
network,subscriber
subscriberfails
failsinin
MS charge of TBF flow establishment, and
MSGPRS
GPRSAttach.
Attach.
 MS then MS exchanges signaling with
MSsends
sendsAttach
Attachrequest,
request,then
thenSGSN
SGSN
sends SGSN; in normal flow, MS sends
sendsback
backattach
attachaccept
acceptmessage,
message,
but Attach complete to SGSN.
butBSC
BSCsends
sendsLLC
LLCunknown
unknown
information  Related BSC data have no problem.
informationsignaling.
signaling.
 From global test we can see that the
same failure occurs in sites controlled
by all BSC that connect with SGSN, so
Solution: we initially estimate it is SGSN
problem.
Turn status of P-TMSI from disable  After checking we see modification
to enable and then the failure is that is status of P-TMSI is changed
from initial enable to disable that
solved. 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
 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 T3172 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.

Contents
 ATTACH Failure
 WAP Failure
 FTP Failure
 Other Failure
Overview
PDP
PDPActivation Low
Activation Lowsuccess
successrate
rateof
ofPDP
PDPactivation,
activation,PDP
PDP
Failure
FailureFeatures
Features activation
activationfailure,
failure,long
longPDP
PDPactivation
activationtime
time
MS Failure: Radio Network Failure:

 APN set incorrectly;  Weak radio network
QOS mistake; signal;
 PDP address mistake;  Interference;
 MS isn’t compatibly  Unavailable radio
resource or congestion.
with network
Reasons for
PDP Activation Failure
Frequent Route Update:
 The area is located on edge
Core Network Failure: of LAC, route update causes
 DNS translation failure; unsuccessful PDP activation
GTP failure between SGSN and GGSN 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
reasonably;
 turn on SGSN cache to shorten DNS translation time;
 check GGSN processing function, improper DHCP or RADIUS server
configuration or powerless GGSN processing ability may cause slow PDP
activation or even 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 no 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.

 Question:
 CQT testing often activated PDP occasional long delay phenomenon. On 10 p
oints after the PDP activation of 100 of the PDP activation test and found abn
ormal delay phenomenon 7


 Failure analysis:
 From the test result we can see that time is mainly consumed below Gb interface
as well as between Radius and WAP gateway. The sixth time consumption between
GGSN and Radius is relatively long, because the first Accounting Request message
sent by GGSN isn’t received by WAP gateway 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 between Radius and WAP gateway. GGSN sends Accounting Request
message to Radius, waits for response from Radius and starts up corresponding
wait timer; corresponding WAP gateway doesn’t response after receiving
Accounting Request message. Then wait timer is overtime because GGSN doesn’t
receive response, the Accounting Request message, and then GGSN resends
Accounting Request message; this time corresponding WAP gateway gives
response and GGSN receives Accounting Response message transmitted by
Radius, and GGSN begins to response to MS PDP activation request.
 TBF resource is released due to overtime timer caused by too long time
consumption on Gi interface, therefore MS reestablishes TBF while receiving PDP
activation accept message, which further 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
 ATTACH Failure
 WAP Failure
 FTP Failure
 Other Failures
Overview
WAP Failure Features: WAP Failure Reasons:
 low success display rate of WAP front  Radio coverage problem, interference, cell
reselection failure;
page;
 Data configuration mistake on two ports of
 long display time of WAP front page; Gb interface;
 low success refresh rate of WAP pages;  Too long WAP gateways connection;
 long refresh time of WAP front page.  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 load 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 download rate.

WAP Logon Failure
 Problem: WAP logon test in ** hotel, after tracking Gb interface

we figure out that 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 try again or contact your operator if the Failure persists”.
This problem is caused by failures in moternet server.
 Solution: require cooperation from core network engineer
through negotiation.

Too Long WAP Logon and Refresh Delay

Too Long WAP Logon and Refresh Delay
Attach request  Problem: through signalling
WAP test signaling flow

Attach accept
analysis we figure out gateway
Active PDP
P
context request Access Request R response time prolongs between
GPRS A
C
U
CN Access Accept D CONNECT to CONNECT REPLY
I
Accounting Req U and between GET to REPLY; GET
S
Accounting Res. request needs to retransmitted

Active PDP
context accept
Wap and there is even no response;
GW
long signaling delay occurs
Connect
Connect reply
Ack especially between GET and

get
get REPLY and sometimes even
M
Reply
Reply
I SP reaches tens of seconds that
S
Ack C largely impacts MS accessing
rate to WAP;
 Solution: core network engineer
optimize WAP gateway.
Contents
 ATTACH Failure
 WAP Failure
 FTP Failure
 Other Failures
Overview
 FTP Download Failure Features:

 High RLC retransfer ratio
 TBF drop and longtime transfer interruption
 Slow FTP download rate

Overview
Network resource
utilization status
Lack of PDCH and

Impact of unreasonable logic
Impact of TBF and
RLC/MAC block channel setting
its parameter setting
retransfer ratio T3168 and T3192 are
set unreasonably;
Weak server cell signal
T3198 and BS_CV_MAX
and severe interference
are set unreasonably.
Reasons for FTP
Download Failure
Impact of C/ I to data
Impact of coding mode transfer
Impact of cell reselection

rate to GPRS data transfer

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

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

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

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

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

demand that causes slow DL FTP rate.
 Solution: increase the number of CI2631 statistic PS channel.

BS_CV_MAX Set Unreasonably
 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 utilization ratio. If value of BS_CV_MAX is set too low, MS may
retransmit RLC block data before network sends back confirmation message
and radio resource occupation ratio 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
value of BS_CV_MAX to 6, transfer rate is improved obviously.


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

52484, C1=25, C2 ＝ 21; the status from 15:40:33.764 to 15:53:586 lasts
20s and then the value of C2 raises to 53. The venue of repetition test is
an intersection where large car flow exists and the roads are congested,
so PET ＝ 20s that we previously 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 transfer drop goes with RAU Failure every time pass through
routing area. After detailed analysis, we figure out data error on
SGSN is the reason for this Routing 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) routing 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 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;
 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 PACKET RESOURCE REQUEST 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.

Weak Coverage
 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
lasts a long period and causes
weak coverage. After checking,
the cell reselection parameter
settings of Cell A and its adjacent
cells at that time is shown in the
table on the next page.

Weak Coverage
 Solution: control the coverage of Cell High Education Scientific

Research 4 (BCCH: 560), modify CRO of Cell High Education
Scientific Research 4 from 26 to 20.
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

Feint Event
 After sniffing and analyzing packet on Gi

interface we figure out that FTP server stops
sending data because it receives [RESET] message
after being logged on. The process of FTP
download test on MS doesn’t stop but FTP
server stops transfer, therefore test software
judges failure due to overtime.
 It is server logon failure due to location update,
TCP process fails due to packet lost while logging
on FTP 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 caused
by FTP failure that appears on TCP/IP transport layer and application layer
instead of caused by GPRS network layer failure.
 From the test software we can see that data on application layer can’t be
received in the two situations while logging on FTP server, and finally FTP
download fail is displayed due to overtime and it is counted as FTP download
failure once.

Contents
 ATTACH Failure
 WAP Failure
 FTP Failure
 Other Failures
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.
PING Failure 2
 Problem: low cell’s C/I causes high BLER (cell BCCH C/I ＝ 5.9). After checking
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.
MMS Transfer Failure
 Problem:
 The transfer success rate of MMS that larger than 15Kbits sent by Panasonic
GD88 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 large MMS can be sent both normally and fast.
 Solution:
 After recording signaling on GB interface we figure out Panasonic EB-GD88
mobile 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 whole network from 15 to 6.

MMS Receiving Failure
 Problem: MS sends Get request on uplink for MMS to MMSC, but Cause
value in the network Reply message is 404: Not Found; it may be
because MS doesn’t pick MMS in time and MMSC deletes it after
waiting for a while, then network replies Not Found when MS requires
MMS.

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.

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.

GPRS Network Accessing Failure
 Some subscribers reflect the network accessing rate is slow by using GPRS
network card.
 The subscriber’s SIM card classification is high and confirmation mechanism
is used on LLC layer, so network accessing rate is slowed.
 Solution:
 Check the subscriber’s PS QoS, reliability; 3 represents unconfirmed, 1
represents confirmed. GPRS network accessing rate accelerates after mode
has been modified as unconfirmed.

BVC Reset and Block Failure
 BSC Gb interface connects successfully with SGSN on NS layer, but configured
PS channel’s status is “BVC reset and block”.
 After checking signaling, RAC is reported mistaken. Check parameter settings
of BSC and SGSN then find out the previous two parameters among the four
parameters of RAC in SGSN configuration are DEC, which should be HEX in
SGSN configuration.
 Solution:
 Modify the parameter to HEX and then signaling go back to normal. We shall
pay special attention that no DEC parameters but HEX parameters shall be
used in SGSN configuration.

GO - NAST3015 - E01 - 1 GPRS Typical Cases Analysis 53

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GO - NAST3015 - E01 - 1 GPRS Typical Cases Analysis 53

Uploaded by

Copyright:

Available Formats

GPRS Typical Cases Analysis

 After learning the course, you will:

Attach Failure Features Attach

Subscriber’s Failure Network Failure

© ZTE Corporation. All rights reserved

 Solutions for Attach Failure

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

MS Failure: Radio Network Failure:

GTP failure between SGSN and GGSN or too long delay

© ZTE Corporation. All rights reserved

 Solutions for PDP Activation Failure

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

 Problem: due to continuous twice cell reselection (CELLID: 10071

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

Solutions for WAP Failure:

© ZTE Corporation. All rights reserved

 Problem: through analysis we see RLC data retransfer ratio is

© ZTE Corporation. All rights reserved

 Problem: WAP logon test in ** hotel, after tracking Gb interface

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

Attach request  Problem: through signalling

WAP test signaling flow

Accounting Res. request needs to retransmitted

Ack especially between GET and

 FTP Download Failure Features:

© ZTE Corporation. All rights reserved

Lack of PDCH and

Impact of cell reselection

© ZTE Corporation. All rights reserved

 Solutions for FTP Download Failure

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

 Problem: frequent cell reselection during FTP download process that

© ZTE Corporation. All rights reserved

 Problem: level decrease to -94dBm

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

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

© ZTE Corporation. All rights reserved

 Normal GPRS MS route update can only be insured when the

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

 Problem: vehicle drives from