2..

4% blocking of PS calls with

no resource

H.Fischer
050310 (25) blocking of PS no resource INTERNAL V1.4.ppt

Communicatio

24% blocking of PS calls no resource

Short description/impact on network:
28.5.04: In VDF live network, 2..4% of mainly PS calls are failing
with no resource available despite admission control is switched
off and the network is not loaded
In one RNC a DHT card with wrong FW was found, but this did not solve
the problem
NEC informs, that root causes for no resource available are
Lack of RNC resource such as DHT/M2C/PRLC firmware
firmware failure upon establishment of RAB
RNC receives RADIO BEARER SETUP FAILURE from UE after
sending RADIO BEAER SETUP message to UE
The restriction (rsta command) works for only second RAB
establishment(Multicall) procedure
RAB Establishment procedure is failed by Admission Control
RAB Establishment procedure is failed by RLReconfiguration (NBAP
Cause = not-enough-user-plane-processing-resources)

Action Mr.Varel to update customer documentation

Action A.Guariento to write FEKAT against customer
documentation
2

PM counters after
DHT exchange

24% blocking of PS calls no resource

Analysis/further steps:
4.6.04: Patch requested via management escalation to distinguish
the various sub-causes for no resource available CR734, Fekat
CY0770 (open).
Likely will not be implemented. Small solution would be on IMSI basis,
however does not allow on counter basis to find the root causes
Update 12.7.04: various reminders to NEC not answered
Update 19.10.04: CR734 has been rejected by NEC for UMR3.0

30.7.04
Check service info #24: CMUX and TINF STM1 cabling must be
consistent with the port setting in the DB, otherwise no resource may
be encountered
Suspect of failures of dht11206, dht11207 in VDF-D2 Berlin
No resource traced in Berlin 29.7.04 trace 3262
During pre-tests in Berlin (26.7.-29.7) no resource has been traced
during UDI calls. 2 DHT cards have been found not reacting. After off-line
diagnosis, they worked again. A supervision script based on call alarm
analysis has been written by VDF-D2 TAC2

24% blocking of PS calls no resource

9.3.05:
UMR30.11A: Statistics from VDF-Berlin show still app. 1,5% of no
resource for PS calls compared to 0,3% for CS calls
In RNC Calm logs has been found, that app. 50% of no resource for PS
calls are caused by a UE message configuration not supported, which
the RNC maps erroneously to no resource instead to failure in the RF
interface. FEKAT DB7755 opened against UMR3.5
Configuration not supported has been reproduced in MVTC labs

Statistics of alarms from DHT board

7.10.04
Siemens drive test Berlin 29.9.-1.10.04 to find issues for video
accessibility problems. 40% of access problems have been caused by
no resource of hanging DHT card
Statistical analysis from alarms generated by DHT supervision script for
14 days (20.9.-4.10.04) evidence

RNC2: 249 Alarms, 3 (of 20) DHT boards involved, 83% probability
RNC4: 38 Alarms, 20 (of 20) DHT boards involved, 13% probability
RNC5: 18 Alarms, 12 (of 20) DHT boards involved, 6% probability

Different phenomena: small number of board, high number of failures

and low number of failures but majority of boards involved
M2C FW has to be >351, current version 371. NEC states, that M2C is
causing the problem, if old FW is used, however alarms persist. VDF-D2
has in field M2C FW 371 and DHT FW 352, UMR 30.08A
VDF-D2 opened ACTIS 93226, because to many DHT are hanging up
FEKATS I85187, CV6350 open since long time. New Fekat CZ8492
opened towards NEC for hanging of the board
Currently known work-around is to block questioned DHT board and
execute manual diagnostic. This will in most case clear the hanging.

DHT alarms Berlin

DHT Alarm analysis

DHT board Work-around (1)

19.10.04
VDF-D2 a script to do routine maintenance on the DHT board and thus
reset them (written by TAC2 VDF-D2) will be deployed by 22.10.04. The
effect will then be monitored bases on performance counter no resource
available
TMD will be informed by 22.10.04
During face to face meeting with VDF-D2 (11.10.04 and a telco 14.10.) VDF
was informed about

The alarm script is working

A work-around script to reset the DHT during the night will be available by 22.10.04
An improvement of the DHT board itself may be expected for UMR4.0 (which
currently is not backed by R&D)

Improvements foreseen are:

CR609 and CR 711 for UMR 3.5 with FW improvements on M2C board
CR664 improves the alarm behavior of the DHT/MHC/PRLC/M2C in UMR4.0, but
not the hang up problem

2.11.04:
Comparison of no resource for TMD from 1.9.-30.10.04 shows, that the
DHT reset script is working, however there are 0,51,5% of remaining
calls blocked. Admission Control switched off, SW UMR30.08

CS Average 0,77% 0,17%, ca. 7500 RAB attempts

PS Average 2,3% 0,99%, ca 5700 RAB attempts

TMD 1.9.-30.10.04

DHT board Work-around (2)

18.11.04:
Verification of no resource for VDF-Greece from 1.11.-6.11-04

CS Average 0,56%, ca. 17000 RAB attempts

PS Average 0,53%, ca. 4000 RAB attempts

Verification of no resource for TMO-Poland from 1.11.-6.11-04

CS Average 0,18%, ca. 4300 RAB attempts

PS Average 0,49%, ca. 3300 RAB attempts

12.11.04:
VDF-D2 in one single RNC of Munich, suddenly all DHT boards installed
started to alarm via the DHT supervision script, despite the boards are
reset once per day under investigation, but suspect is not the DHT
board

4.1.05:

DHT reset script de-activated in VDF-D2 Berlin with no negative impact

on KPIs

PRLC board investigations

3.3.05
A PRLC reset script was introduced in VDF-Berlin RNC for one week and
had no effect on no resource. Can be excluded as problem source for
PS calls

Configuration not supported from UE

Analysis:
9.3.05:
Qualcomm UE (chipset 6200) is in idle or cell FACH with PDP context in
3G
UE moves to 2G in IDLE and performs a LAU+RAU procedure
UE moves back in 3G in IDLE (LAU+RAU+PDP modify)
A PS paging from the SGSN is triggered (termination cause unknown),
tested doing a PING from the SGSN to the UE
UE answers with Radio_Bearer_Setup_Failure (Invalid Configuration).
The problem is occurring only with the Qualcomm chipset 6200.
Everything is ok with the chipset Qualcomm 6250 and with the Motorola
chipset.
So we strongly suspect a Qualcomm issue.