- This topic has 8 replies, 1 voice, and was last updated 11 years, 3 months ago by
.
-
Posts
-
Hi all,
What could be the reason for low SDCCH SUCCESS RATE in a cell when the SDCCH DROP & SDCCH BLOCKING are normal.
The cell is of ericsson and the immediate neighbour is Nokia cell.
Inter MSC/BSC handover are checked and are defined.
Where to check?
Regards
MKT
ERICSSON CELL STATS
CellName
TRW001A
TRW001B
TRW001CTRX
6
6
6TCH Availability Rate
100
82.39
99.95TCH Traffic (Erlang)
17.79
12.05
4.22TCH Drop (%)
10.85
31.26
22.68TCH Blocking (%)
0
0.45
0No. of SDCCHs
47
55
39SDCCH Call Success Rate
58.87
72.31
72.02SDCCH Drop (%)
9.92
8.99
3.82SDCCH Blocking
0
0.07
0Outgoing HO Success Rate
89.35
95.42
92.02Incoming HO Success Rate
93.27
94.86
93.24Call Success Rate
98.65
99.55
99.48HR Traffic
0.78
2.91
0.01The problem started to appear one month back when the Ericsson carried out an activity to redefine the LACs in their network.
SDCCH DRop is around 9% !! That’s not what I’d call normal 🙂
What I see is:
High TCH drop
High SDCCH dropThen, Call success % is excellent and HO success are good too. That proves that the way Ericsson are computing their indicators is very obscure ! (for me, at least)
Could you please state also the average duration of the SDCCH and TCH in the cells ? If it is very short, then that confirms my suspicion…
With such bad QoS I must suspect a hardware failure, or most probably a wrong configuration of the equipments or interfaces. I would investigate if the drops happen on some TRX only, or even on some TS only. I would check also what is the cause of the drops (with indicators, or with drivetest)
If there is a random pattern, then the failure is probably located further up in the core network (Ater ? TC ? A interface ? MSC ???). My instinct is leaning towards A and Ater misconfiguration, or a board failure somewhere.
MKT,
Can you please provide values for the following counters ccalls,cmsestab,ccongs,tassall,tcassall,cndrop,thndrop,tfndrop.
im not convinced with the kpi figures belowIts the RACH sent from the mobile, two cells with the same BCCH anser the request. Awaitng response from handset which completes access on closer cell not responding to the futher cell (normally higher ground height). This does not affect KPI’s so can be ignored. Otherwise find the clashing BCCH and perform retune.
THE L3 MESSAGE DETAIL FOR CALL END
MS1
ReleaseTime: 13:54:06.39
MsgCtrlOperation :
Transaction identifier : 0
Protocol discriminator : (3) Call control; call related SS messages
Message type : 45Message dump (Hex):
03 2DMS1
Time: 13:54:06.39Call End
NW initiated release
Call duration: 109094 msMODE REPORT
MS1
Time: 13:54:06.39Call End
NW initiated release
Call duration: 109094 mshow to make a statistic of times number seize SDCCH channel by nemo analyze, expect people to help
