- This topic has 36 replies, 1 voice, and was last updated 12 years, 6 months ago by
.
-
Posts
-
In the failure submenu we have something called ghost
What are ghosts .Please see the exact description
other (fails, ghosts) …………………../sd_1a
and how can we reduce it
Ghost.. it means that the failure occurs on a “ghost” request. It is simply a random radio signal that was received by the BTS, looking like a RACH access. The BTS process it as a “real” RACH request, starting a SDCCH assignment.
The SDCCH assignment fails because the RACH is actually a “ghost”… there is no answer from the Air interface after the BTS sent its AGCH messages.
To reduce it, you can increase the RXLEV ACCESS MIN threshold. Frankly, as long as it doesn’t induce RACH congestion, you shouldn’t worry too much. Keep the SDCCH failures due to ghost within reasonnable amount (< 10% for instance).
hi man,
as the traffic will increase on site phantom RACH pblm. will be solved,this type of problem normally comes on stand alone sites…..BR//
Yogesh_rfUsing .3,.6,1.2,1.8,2.4 metre dia minilink antennas the capacity of E1 same or various to size.. plz explain me… i am lot of confusion..
what is phantom RACH
sdcch does not fail due to phantom rach ! unless t3101 expiration is considered one of the sdcch drop reasons. there is no counter counts how many immediate assignment failed due to timer expiration?! if no, then how could an engineer keep it under 10% ?!
Hello all,
What do you think about this KPI to estimate SDCCH assignment failure due to RACH phantom ?
((Number of Channel Required) – (Number of Immediate Assignment + Number of Immediate Assignment Failures due to congestion) + (Number of UL access requests on CCCH when the MS is in packet idle mode))* ( 6 / 2 )
Tx U
Up;
I wonder how to estimate or calculate dummy RACH, any idea ?
tx
Hi
Phantom RACH’s are also caused by a site spilling and also has a direct influence on the CSSR of the particular BTS.
akefa, to answer your msg from 24 june,
a sdcch failure is not a sdcch drop 🙂 those are 2 different things.
Failure occurs during the attempt to seize the SDCCH channel.
Drop occurs during the usage of the SDCCH channel.
You can check the Timing Advance of your cell. Sometimes, when you have phantom rachs, you have very big TA which are not justified (but check that this is not a resurgence case.
Generally, the problemm can be solved by reducing the cell size (rach_ta_filter)
MS_REQ_for_location_update suddenly increase, and Immediate_assigne_fail_rate increase, hence the CSSR is affected.
this case maybe solved by reseting the cell, or changing the BSIC of the cell.
and some times, it is solved alone without any action.Hi, all.
When the MS executes a HO command, it sends an Access Burst ( transmitting with full power ) when it seizes its TS in the target cell.
The energy shape of Access Burst is identical to the Random Access Burst.
So it’s possible to be decoded as goast RACH from some cell with the same BCCH freq (as the TS freq of the target cell ) far from the HO place…BR
Dear Optimizer /PIX
I am also facing the same issue of Ghost / Phantom RACH.
But after seeing the TA stats, i couldnt find any large TA on those hours where we have Many Location Update attempts, and then Immediate assignment failures.
So now how can i make sure that is it Phantom RACH.
And also what is the solution to minimize it. is it.
1. Optimize BSIC of the cell
2. Reduce TA (But in my case no excessive TA reported)Kindly reply
Thanks
AAK
Hi, AAK.
Pix, correct me if I’m wrong.
The GSM standard say that it’s normal to have SDCCH failure up to 10% per day.
It’s based to the number of RACH subTSs per day, the probability the noise to be decoded as Channel Request ( Ghost RACH )and the probability to have a valid request reason…
It’s clear visible during the night ( when the radio interface is “not loaded”).1.The BSIC is not involved in the Channel Request. Optimize the BCCH freq.
2. I’m not a fan of the TA Filtering and I don’t know someone who uses this approach efficient.Downtilt could prevent Ghost RACH in my opinion but may be whit other consequenses…
BR
