Document type Test Case

Creator: COO
Date: Jan 7th, 2010

Sleeping GPRS Cell Problem

Change History
Issue Date Handled by Comments
 Sleeping GPRS cell probelm

Reason for Sleeping Cell

1. Problems with a Sleeping GPRS/EDGE cell are usually caused by Abis
synchronization problems
2. High PCU utilization may cause the cells to totally prevented from the traffic.
3. Any EDAP related Activity BCSU switchover is mandatory
4. Transmission Problem

1. Problems with a Sleeping GPRS/EDGE cell are usually

caused by Abis synchronization problems
Symptom
Most of the cases 7725 Alarm trigger but are minor enough not to trigger the
7725 alarm.
that affect GPRS/EDGE traffic but are minor enough not to trigger the 7725
alarm. In all suspected sleeping cell cases, try to find out why the cell is
sleeping by considering how the problem was noticed. It could also be useful
to try to verify the sleeping cell case by doing a data transfer test in the
affected cells.

A sleeping cell can also trigger the alarm 7789 NO (E)GPRS

TRANSACTIONS IN BTS, but only if alarm monitoring is properly configured.
Check whether this alarm is active when investigating a sleeping cell.
If the reason for a sleeping cell cannot be traced to any other problem,
continue by taking the logs as instructed below. Note that the logs are quite
general and help to pinpoint the possible cause of the problem,
Continuons resynchronisation
Symptom
In continuous resynchronisation, an active GPRS channel repeatedly
loses block synchronisation, and then acquires it immediately back
again. As a result, data transfer is disturbed.
Even though continuous resynchronisation may block almost all traffic
from the cell, it is quite difficult to detect. No synchronisation-related
alarms are necessarily raised, but the failed TBF allocation counters
072079 NO RADIO RES AVA UL TBF and 072080 NO RADIO RES AVA
DL TBF may show increased values and point to this problem.
In addition, alarm 7789 NO (E)GPRS TRANSACTIONS IN BTS

Possible causes
There are several possible causes:

• The EGPRS dynamic Abis pool (EDAP) may have been

configured incorrectly.
• The EDAP and the TRXs tied to it may not be using a single PCM
cables. If they use separate PCM cables, transmission timing
between the cables is most likely to differ. This causes a timing
difference between the EDAP and the TRXs with the result that
synchronisation is not successful.

© 2009 NSN Siemens Networks. All rights reserved.

Page 2 of 14
 Sleeping GPRS cell probelm

• An ET card is out of order.

• The PCU receives illegal frames from the BTS or the PCU DSP,
or the frames are missing.
• There are internal and external faults in the Abis interface.
• The BTS starts resynchronisation for some BTS-internal reason.

Unsuccessful initial synchronisation or resynchronisation

Symptoms
The PCU has an internal timer of 45 seconds for synchronisation. If this
timer expires before the packet data channel (PDCH) acquires Abis
synchronisation,
.
Possible causes
There are several possible causes:

• The EGPRS dynamic Abis pool (EDAP) may have been

configured incorrectly.
• The EDAP and the TRXs tied to it may not be using a single PCM
cable. If they use separate PCM cables, transmission timing
between the cables is most likely to differ. This causes a timing
difference between the EDAP and the TRXs with the result that
synchronisation is not successful.
• An ET card is out of order.
• The PCU receives illegal frames from the BTS or the PCU DSP,
or the frames are missing.
• There are internal or external faults in the Abis interface.

No PCU synchronisation frames received from the BTS

Symptoms
Synchronisation does not start because the BTS does not send uplink
PCU synchronisation frames to the PCU. If this state lasts for 45
seconds, the PCU-internal synchronisation timer expires,
Possible causes
There are several possible causes:

• An ET card is out of order.

• The PCU receives illegal frames from the BTS or the PCU DSP,
or the frames are missing.
• There are internal or external faults in the Abis interface.
• The BTS does not send uplink data frames.

© 2009 NSN Siemens Networks. All rights reserved.

Page 3 of 14
 Sleeping GPRS cell probelm

Solution :
Correction for 7725 Alarm is available in S13 CD8.
7789 NO (E)GPRS TRANSACTIONS IN BTS

To monitor the sleeping Cell 7789 Alarm activated. Following Changes has
been done in all the BSC

MML Default

ZEQV: EAW = (E)GPRS inactivity alarm weekdays (0)

EAS = (E)GPRS inactivity alarm start time (08-00)
EAE = (E)GPRS inactivity alarm end time (18-00)
ZEEJ: EGIC = (E)GPRS inactivity criteria (0)
IEPH = Number of TBF allocation attempts required per hour (10)
SPL = Supervision period length (120 min)

Modification in our Network

ZEQV: EAW = (E)GPRS inactivity alarm All Days (ALL)

EAS = (E)GPRS inactivity alarm start time (00-00)
EAE = (E)GPRS inactivity alarm end time (24-00)
ZEEJ: EGIC = (E)GPRS inactivity criteria (2)
IEPH = Number of TBF allocation attempts required per hour (0)
SPL = Supervision period length (120 min)

Parameter Description

EAW=Parameter determines the day of week when the EGPRS inactivity alarm
is enabled.

EAS =Parameter determines the time of day when the EGPRS inactivity alarm
is enabled.

EAE=Parameter determines the time of day when the EGPRS inactivity alarm
is disabled.
EGIC= Parameter you define the criteria used to the EGPRS Inactivity.

IEPH= Parameter you define the number of TBF allocation attempts required
per hour for EGPRS Inactivity Alarm

SPL= Parameter determines the length of the supervision period for EGPRS
inactivity alarm in minutes.

Note: With Above modification we will get the 7789 Alarm for those cells
where there is no Data subscriber.

Action : We have to perform the Data call on the Cells where 7789 Alarms
continuously reported and based if problem found verify the Sync related
issue

© 2009 NSN Siemens Networks. All rights reserved.

Page 4 of 14
 Sleeping GPRS cell probelm

2. High PCU utilization may cause the cells to

totally prevent from the traffic.

GPRS/EDGE territory failures

Symptoms
Alarm 3273 (E)GPRS TERRITORY FAILURE is active. This alarm may imply
sleeping, missing, or bouncing GPRS/EDGE timeslots, or a reduced number of
timeslot allocations.
In addition, alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE may be active.
This alarm implies a missing or incomplete EDAP configuration.
.
Possible causes
If alarm 3068 is active, the cause can be a failed EDAP configuration.
Problems with transmission in the Abis interface
For the most part, transmission problems in the Abis interface are either related to
Abis synchronisation or Dynamic Abis configuration. Both of these problem types
may seriously impair GPRS/EDGE functionality.
Abis synchronisation
The PCU needs to adapt to the radio interface time division multiple access (TDMA)
frame timing and frame numbering. In the Abis interface, this means that one PCU
frame is sent and one is received in each packet data channel (PDCH) once within
every 20 ms period. The PCU implements the channel synchronisation, the frame
numbering, and the PCU frame management with digital signal processors (DSP).
When there are problems with Abis synchronisation, data transfer is not possible in
the affected cell. The following alarms may also be raised:

• 7725 TRAFFIC CHANNEL ACTIVATION FAILURE (cause code 2)

The problem is on a radio timeslot (RTSL) that is in GPRS data use.

• 7789 NO (E)GPRS TRANSACTIONS IN BTS

The problem may be in the synchronisation of a GPRS RTSL.

TBFs do not have enough EDAP resources

Symptoms
Counters 076006 UL TBFS WITHOUT EDAP RES, 076007 DL TBFS WITHOUT
EDAP RES or 076008 DL TBFS WITH INADEQUATE EDAP RES show higher
values than expected, for example, with a single MS. Typically, a zero value is
expected for counter 076008, but a non-zero value appears. Due to the inadequate
EGPRS dynamic Abis pool (EDAP) resources, throughput is smaller than expected.
Counters 076019 UL MCS LIMITED BY PCU or 076020 DL MCS LIMITED BY PCU
may also show high values.
In addition, GPRS/EDGE territory upgrade failures or partial GPRS/EDGE territory
upgrades may appear
Possible causes
There are two main causes:

© 2009 NSN Siemens Networks. All rights reserved.

Page 5 of 14
 Sleeping GPRS cell probelm

• Dynamic Abis dimensioning is not optimal. For example, there are too many or too
few EDAPs, or the EDAP sizes are not appropriate to the traffic.
• The PCU suffers from internal digital signal processor (DSP) limitations; for
example, DSP grouping limitation and 20 channels/DSP limitation. These
limitations impose trade-offs on the optimisation of DSP capacity between the
overall EDAP configuration and single EDAPs.

These two causes may also interact with each other. If Dynamic Abis
dimensioning is not optimal, DSP resources may limit the multislot coding
scheme (MCS) easier and more frequently than in an optimal situation. On the
other hand, ignoring the DSP limitations may lead to less optimal Dynamic
Abis dimensioning.
Instructions
1. Analyse the network and EDAP configurations.
Based on the analysis, redimension the Dynamic Abis
and/or add more DSP capacity.
2.
For more information on Dynamic Abis dimensioning, see
Abis EDGE Dimensioning.
EDAP configuration fails
Symptoms
Alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE is raised. This alarm
implies a missing or incomplete EDAP configuration.
In addition, alarm 3273 (E)GPRS TERRITORY FAILURE may be raised. This
alarm may imply sleeping, missing, or bouncing GPRS/EDGE timeslots, or a
reduced number of timeslot allocations.
Possible causes
The failed EDAP configuration has probably raised the alarm 3068. As a
result, the PCU has not been able to upgrade any GPRS/EGPRS channels,
which has then raised the alarm 3273. It is possible that incorrect EDAP
configuration commands have been given.
Instructions
Check all MML commands given before the alarms 3273
1.
and 3068 were raised.
If the EDAP configuration had been done properly, see
2. GPRS/EDGE territory failures for further information on
possible causes.
If the problem persists, collect all the information needed
for a Problem Report and contact Nokia Siemens Networks
for further investigations. For instructions, seeCollecting
3.
EDAP configuration failure logs (PCU1) or Collecting EDAP
configuration failure logs (PCU2) in BSC Problem
Reporting.
Workarounds
Perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;

© 2009 NSN Siemens Networks. All rights reserved.

Page 6 of 14
 Sleeping GPRS cell probelm

TBF establishment fails due to lack of Abis channel resources

Symptoms
Temporary block flow (TBF) establishment is terminated, and in the PCU1 log,
the following kind of log print out indicates that there are no valid BTSs with
active channels in the segment:
Counters 072079 NO RADIO RES AVA UL TBF and 072080 NO RADIO RES
AVA DL TBF are also updated.
In this situation, no Abis channel resources are allocated to the MS because
there are no timeslots available in the GPRS/EDGE territory of the segment.
However, to some extent this is quite normal. Corrective actions are needed
only if the symptoms occur repeatedly.
Possible causes
This problem may be caused by problems in synchronisation, or by some
other kinds of problems in the GPRS/EDGE territory. In general, this problem
indicates that there is something wrong in the GPRS/EDGE territory, and it
should be investigated further.
Instructions
Find out if there are any problems with synchronisation or problems with the
GPRS/EDGE territory currently on. Solving them may help to solve this
problem, too.

Solution :
Continuous monitoring of the Data traffic and based on requirement increase the
resource.

© 2009 NSN Siemens Networks. All rights reserved.

Page 7 of 14
 Sleeping GPRS cell probelm

3. Any EDAP related Activity BCSU switchover is

mandatory
There is technical for Dynamic Abis configuration after changes are made to the
EDAP configuration of PCU, it is recommended to make BCSU switchover for the
BCSU that controls the PCU. This optimizes PCUPCM channel allocation for the PCU

TS-BSC-SW-0835-I3.
0.pdf

Impact:
If we will not Switchover the BCSU and PCUPCM not optimized in that case Data
call will not work for those cells where PCUPCM is not optimized.

Workaround:
After Any EDAP related Activity BCSU Switchover is mandatory.

Permanent Solution
In S15/RG20 there will be feature for Automatic EDAP Reallocation in PCU. With this
we don’t have to give the BCSU Switchover After DAP modification.

© 2009 NSN Siemens Networks. All rights reserved.

Page 8 of 14
 Sleeping GPRS cell probelm

4. Problems with transmission in the Gb interface

• Inconsistent BVCI states between the BSC, the PCU and the SGSN
• BSSGP protocol error raised with cause code 0x20 or 0x21
• BVCI operational state remains UNBLOCKED
• Gb over IP: DX error 16246 appears
Inconsistent BVCI states between the BSC, the PCU and the SGSN
Symptoms
The BSSGP virtual connection identifier (BVCI) states are inconsistent in the
MML printouts of the BSC and the SGSN. For example, the state of a BVCI at
the BSC may be WORKING, while at the SGSN its state may be UNKNOWN.
Inconsistent BVCI states can lead to a situation where GPRS/EDGE cells do
not relay data at all. This raises the alarm 7789 NO (E)GPRS
TRANSACTIONS IN BTS.
Inconsistent BVCI states can also be the cause of alarm 3032 BSSGP
VIRTUAL CONNECTION PROTOCOL ERROR with causes 0x9 (BVCI
blocked) and 0x5 (BVCI Un-known).
Possible causes
Inconsistent BVCI states may be caused by failures in BVC-RESET,
BVC-BLOCK, or BVC-UNBLOCK procedures

Workarounds
Typically, recreating the BVCI solves the problem.
To recreate a BVCI, disable and enable GPRS in the segment.
ZEQV:BTS=<BTS_identification>:GENA:N;
ZEQV:BTS=<BTS_identification>:GENA:Y;
If disabling and enabling GPRS does not help, reset the network service entity
(NSE).
ZFXR:NSEI=<nsei_id>;
If NSE reset does not help, perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;

BSSGP protocol error raised with cause code 0x20 or 0x21

Symptoms
The base station system GPRS protocol (BSSGP) raises the alarm 3032
BSSGP VIRTUAL CONNECTION PROTOCOL ERROR with cause code 0x20
(Semantically incorrect PDU) or 0x21 (Invalid mandatory information).
Possible causes
A typical cause is an erroneous, zero-length uplink LLC PDU sent by the BSC
to the SGSN. The SGSN responds with a STATUS PDU either with cause
code 0x20 or 0x21, depending on the SGSN type and manufacturer.
If the alarm reoccurs, it means that the peer entities are not compatible. An
update to the protocol software may be required.

© 2009 NSN Siemens Networks. All rights reserved.

Page 9 of 14
 Sleeping GPRS cell probelm

BVCI operational state remains UNBLOCKED

Symptoms
The BSC MML command ZEQO shows the BSSGP virtual connection
identifier's (BVCI) operational state as UNBLOCKED. If the operational state
remains UNBLOCKED, it may lead to a situation where GPRS cells do not
relay data at all. This raises the alarm 7789 NO (E)GPRS TRANSACTIONS IN
BTS

Possible causes
The BVCI has been successfully created on the SGSN, but the GPRS territory
does not have any channels yet. Therefore, the initial FLOW-CONTROL-BVC
PDU is not completed.
Workarounds
If the GPRS territory has at least one channel, recreate the BVCI.
To recreate a BVCI, disable and enable GPRS in the segment.
ZEQV:BTS=<BTS_identification>:GENA:N;
ZEQV:BTS=<BTS_identification>:GENA:Y;
If disabling and enabling GPRS does not help, perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;

Gb over IP: DX error 16246 appears

Symptoms
When the ZFXK command (creating an NS-VC), the ZFXR command
(resetting an NSE), or the ZFXI command (outputting NS-VL data) is
executed, the following DX error message appears:
Example:
/*** DX ERROR: 16246 ***/
/*** BSC DB AND PCU CONFIGURED OK BUT NO RESPONSE RECEIVED FROM SGSN, \
STILL TRYING ***/
Possible causes
Unsuccessful ZFXK or ZFXR commands hint at problems with the SGSN
configuration/Gb over IP LAN, whereas the unsuccessful ZFXI command may
mean that the PCU has lost the IP address after a BCSU switchover.
Workarounds
There are no known workarounds for this problem situation because the
problem is most probably in the IP LAN network.

© 2009 NSN Siemens Networks. All rights reserved.

Page 10 of 14
 Sleeping GPRS cell probelm

Problems with performance

Low downlink GPRS/EDGE throughput
Symptoms
The following symptoms may indicate low downlink GPRS/EDGE throughput:

• EDGE key performance indicators (KPI) dap_7a, tbf_16, blck_33, trf_235b,

trf_236, and frl_8a. For more information, see EDGE Key Performance
Indicators.
• Counter 090005 AVERAGE MS SPECIFIC BSSGP FLOW RATE and volume-
weighted counters 090007–090012. For more information, see 90 Quality of
Service Measurement.
• Increased end-user download times.

Possible causes
Several factors may lower downlink throughput. For example, too small a
GPRS/EDGE territory, an incorrectly created EDAP, or bad conditions in
the radio interface.
In the Gb interface (both Frame Relay and Gb over IP), low downlink
throughput may result from incorrect base station system GPRS protocol
(BSSGP) flow control values.
In Gb over Frame Relay, the dimensioning of the interface may also be a
limiting factor; for example, the size of the Frame Relay bearer channel, or
network service entity (NSE) division into NS-VC(s).
In Gb over IP, a limiting factor may be user data protocol (UDP) packet
dropping caused by a duplex mode mismatch on the Gb over IP
configuration.
Instructions
To ensure that too small a GPRS/EDGE territory is not
causing the problem, check that the territory has enough
1.
channels. If not, increase the number of dedicated
channels in the territory.
To ensure that insufficient EDAP resources are not causing
the problem, check that the EDAP is dimensioned correctly.
2.
For more information, see TBFs do not have enough EDAP
resources.
To ensure that the size of the Frame Relay bearer channel
is not causing the problem, check that its performance is
high enough for fast GPRS/EDGE transfers.
The peak margin of the data volume can deviate a lot
depending on, for example, the amount of data volume,
3. different coding schemes, throughput rates, and the
services offered. The smaller the size of the Frame Relay
bearer channel, the greater its effect on a single user. For
GPRS, the Gb link should be at least 128k, whereas for
EGPRS it should be at least 256k.
For more information, see Gb EDGE Dimensioning.

© 2009 NSN Siemens Networks. All rights reserved.

Page 11 of 14
 Sleeping GPRS cell probelm

To ensure that the values of the BSSGP flow control

parameter are not causing the problem, check the values of
the parameter in the BSC.
ZWOI:49
The recommended values for BSSGP flow control in the
4.
BSC are given in Technical Note No. 819 (BSSGP Flow
Control Parameter Value Recommendation for (E)GPRS).
Note that the flow control parameters have dependencies
on each other. Therefore, the new values should be applied
simultaneously.
The duplex-speed of the PCU is fixed to autonegotiate. To
ensure that a duplex mode mismatch on the Gb over IP
configuration is not causing the problem, check that the
duplex-speed mode of the port in the other end of the
5.
Ethernet link is also set to auto-negotiate.
For more information on the recommended duplex speed
settings, see BSC LAN topology in BSC Site IP
Connectivity Guidelines.
If downlink throughput does not improve after these
corrective actions, collect all the information needed for a
Problem Report and contact Nokia Siemens Networks for
6.
further investigations. For instructions, seeReporting
problems with performance (PCU1) or Reporting problems
with performance (PCU2) in BSC Problem Reporting.

© 2009 NSN Siemens Networks. All rights reserved.

Page 12 of 14
 Sleeping GPRS cell probelm

Appendix
BSSGP Virtual Connection Identifier ( BVCI)
BSSGP virtual connections (BVC) are communication paths between peer
BSSGPs. Each BVC is supported by one network service entity (NSE) and
identified by a BVCI which has end-to-end significance on the Gb
interface. Each BVC is unique between two peer network service entities.
Within the BSS, a cell is identified uniquely by the BVCI

BVC Blocking and Unblocking

Figure 11: BVC Blocking and Unblocking

The BSC initiates the BVC blocking to remove a BVC from GPRS data
use.
The BSC blocks a BVC after:

• BVC deletion with an O&M, disabling the GPRS enabling/disabling parameter

of a cell with the cause value O&M intervention
• O&M disables a cell or a BCF with the cause value O&M intervention
• O&M disables the last GPRS supporting TRX in a cell with the cause value
O&M intervention
• block of the last NS-VC of the NSE that serves the BVC

Related BVCs are implicitly blocked. No indication is sent to the peer BSSGP.

• SGSN-initiated BVC-RESET procedure, if necessary, with the cause value

BVCI-blocked
• cell level fault, for example, in the beginning of the site, BTS, or TRX reset
with the cause value Equipment failure

The BSC marks the BVC as blocked and sends a BVC-BLOCK PDU to the
SGSN and starts the TgbBlock timer. The BVC-BLOCK PDU contains the
BVCI of the BVC to be blocked and a cause element indicating the reason
for blocking. All downlink UNITDATA PDUs are discarded and no uplink
UNITDATA PDUs are sent on the blocked BVC.

© 2009 NSN Siemens Networks. All rights reserved.

Page 13 of 14
 Sleeping GPRS cell probelm

When the SGSN receives a BVC-BLOCK PDU, it marks the indicated BVC
as blocked and stops transmitting traffic that is addressed to this BVC. The
SGSN acknowledges the blocking of the BVC by sending a BVC-BLOCK-
ACK PDU to the BSC. The BVC-BLOCK-ACK PDU contains the BVCI
received in the BVC-BLOCK PDU.
When the BSC receives the BVC-BLOCK-ACK PDU, it stops the TgbBlock
timer. Further incoming traffic on the blocked BVC is discarded and a
Status PDU is returned on the signalling BVC with the cause value BVCI-
blocked. The Status PDU indicates the BVCI of the BVC in which the error
was detected.
BVC unblocking is only used when the BSC receives an unexpected BVC-
BLOCK-ACK PDU relating to a BVC that is locally unblocked. In such a
case, the BVC is unblocked with the BVC-UNBLOCK PDU. For more
information, see Abnormal conditions.
The signalling BVC is never blocked or unblocked.
Abnormal conditions
If the BSC receives an unexpected BVC-BLOCK-ACK PDU relating to a
locally blocked BVC, it ignores it. If the BVC-BLOCK-ACK PDU is related
to a locally unblocked BVC, the BSC unblocks the BVC with the BVC-
UNBLOCK PDU.
If the BSC receives an unexpected BVC-UNBLOCK-ACK PDU relating to a
locally unblocked BVC, it is ignored. If the BVC-UNBLOCK-ACK PDU is
related to a locally blocked BVC, the BSC blocks the BVC with the BVC-
BLOCK PDU.
If the BSC does not receive a BVC-BLOCK-ACK PDU for a BVC-BLOCK
PDU within TgbBlock seconds, it repeats the BVC blocking procedure a
maximum of BVCBlockRetries times. After BVCBlockRetries unsuccessful
attempts the BVC remains blocked and the procedure is stopped.
If the BSC does not receive a BVC-UNBLOCK-ACK PDU for a BVC-
UNBLOCK PDU within TgbBlock seconds, it repeats the BVC unblocking
procedure a maximum of BVCUnblockRetries times. After
BVCUnblockRetries unsuccessful attempts the procedure is stopped.
If the BSC receives a BVC-RESET PDU for the signalling BVC while
waiting for a BVC-BLOCK-ACK, it handles the signalling BVC reset
procedure first, after which the BVC block procedure is resumed.
If the BSC receives a BVC-BLOCK-ACK PDU or a BVC-UNBLOCK-ACK
PDU for the signalling BVC, it ignores the PDU.

© 2009 NSN Siemens Networks. All rights reserved.

Page 14 of 14