- This topic has 21 replies, 1 voice, and was last updated 13 years, 10 months ago by pix.
-
AuthorPosts
-
3rd January 2008 at 16:18 #50251GmGuest
Hi all. We have an issue in our network where we get random huge spikes for a couple of hours of SDCCH assignment attempts, and they end up in failures (T3101 expiration). This happens mostly on rural sites.
For example we might have 6000 SDCCH attempts a day, of which 5800 is successful. One other day though we might get 10000 attempts of which again 5800 are successful and this is due to the fact that for a couple of hours we had a spike of SDCCH attempts where all of those extra attempts failed due to T3101 timer expiration.
This effect does not seem to affect customer experience, I’m just wondering why it might happen.
Any ideas?
Thanks
3rd January 2008 at 16:49 #50252pixGuestwhat hour is the peak of “dummy” SDCCH assignments ?
what is the cause of failure ?
CONGESTION :
you might experience massive Location Updates due to a site from another operator that becomes unavailable. All subscribers reselect your site for a while, creating a massive SDCCH congestionRADIO :
1/ some external equipments (army radar, jammers, etc.) generate fake “RACH” Channel Request, that are “failed”, because the BTS sends an immediate assignment command, but there is no answer from this external equipment (that’s normal)2/ BTS failure : the BTS generates electromagnetic noise that’s decoded as a channel requests…
That might give you some idea of investigation : check the type of sdcch assignment (for LU, for call, for reestab, for SMS ???)
check the cause of failure (radio, hardware, congestion ???)
check other counters (RACH counts, channel activation, channel activation ack, immediate assignment, etc.)
Regards,
Pix3rd January 2008 at 17:03 #50253GmGuestThe cells don’t get congested and the failures appear like they are phantom RACH but the question is why are there spikes of SDCCH attempts. If it was due to phantom RACCH there wouldn’t be a spike would it?
4th January 2008 at 08:01 #50254pixGuestghost RACH can be caused to external devices. If an army plane or an army boat is around at that time, you’ll measure high ghost rach.
Check what kind of events is occurring in the area of the cell.
Regards,
Pix4th January 2008 at 13:53 #50255GmGuestThe failures are happening on channel requests due to cause000, which is due to either location updates (0000) or other reasons (0001). The problem is that the counters on both vendor’s equipment our network utilises do not distinguish between the two..That means it could be as pix said due to failed BTSs from other operators and reselection to our network for location updates or for any other reason (ghost rach)…
4th January 2008 at 16:53 #50256PixGuestGhost RACH are random, so for each ghost RACH, the field “CAUSE” contains a random value. Can be 1111, 0011, 0101.. etc. If it was ghost RACH, you would see an equal distribution of each type of RACH cause.
therefore, it looks like it is LU from roaming MS’s. But why are they failed ? I have to re-read the 3GPP, but I thought a roaming MS is allowed perform a LU in a cell : SDCCH assignment, SDCCH allocated. And during the SDCCH phase (DTAP messages MS-MSC about authentication, etc.) if the MS cannot camp on this network, the LU will be rejected.
What I mean is that the rejection is not performed at the RACH reception (but thi is as far as I think !! this needs to be confirmed… anyone ??)Regards,
Pix26th January 2008 at 17:36 #50257BassamGuestHi to all
please ,any body can tell me what is the meaning of “phantom RACH phenomina” ?Regards
26th January 2008 at 20:23 #50258pixGuestelectromagnetic noise that is decoded as a channel request.
26th February 2009 at 04:57 #50259maliraGuestI have found this problem in my network (Alcatel)also. Yes, the successful is almost same as the normal situation but huge attempts and failures.
The type of assignment that increases during that time is IMSI detached.
Do you have any idea about this?Thank you for your answer. 🙂
BRs,
5th March 2009 at 06:49 #50260PhantomGuestIn Alcatel , How can we know that SD Failure ‘s caused from Ghost RACH ? . I means what’s BSS counter name MC74.. or any?
5th March 2009 at 07:30 #50261PixGuestMalira,
a lot of IMSI detach ? and most of them are failed ? (= sdcch assign fail radio ?)
that is strange… can’t help sorry.
if you want you can send me a RNO report by mail. pix _ erlang at yahoo dot fr.
5th March 2009 at 07:31 #50262PixGuestPhantom,
No, it doesn’t work like this 🙂 The SDCCH Assign Fail due to Radio can be caused by ghost rach, but not only. There is no dedicated counter for ghost rach.
regards,
pix5th March 2009 at 07:58 #50263PhantomGuestWhat time is there Pix , I think you r sleeping
Thank you for answer Pix, so , Can we distinguish the cause of LU from Couter ? because I knew that LU
will be done while MS is in Idle mode ( Periodic,Difference LAC,Power ON)Because as I observed , often SD failure came from LU , I found that it appeared everyday around 1am to 6 am. and disapeared after that
5th March 2009 at 09:26 #50264christianGuesthi pix any solution of RBS2206 all site encounter a fault of RX diversity lost and RX path A or B imbalance. Cn you help me with regard this fault. Can you send it to my email?
thank you
christian philippines
5th March 2009 at 14:57 #50265pixGuestChristian: Sorry, I work with alcatel only, not … RBS (Ericsson??)
Phantom,
You can see the split of SDCCH allocation types here (below)
but those are succesful SDCCH allocation .. a sdcch allocation failure is not succesful (duh !!), so you cant know whether the original rach was asking for LU or MO or MT, etc.
FYI, a ghost rach = 1 SDCCH_assign_fail_radio ( SDNAFLRN )
(in RNO > Indicators)
—–
Family : Traffic model
Subfamily : main
—–
SDCCH_traffic_moc_rate ( TMMOCER )
SDCCH_traffic_Call_reestab_rate ( TMMOCRR )
SDCCH_traffic_imsi_detach_rate ( TMMOLUDR )
SDCCH_traffic_lu_for_rate ( TMMOLUFR )
SDCCH_traffic_lu_rate ( TMMOLUR )
SDCCH_traffic_sms_mo_rate ( TMMOSMSR )
SDCCH_traffic_ss_mo_rate ( TMMOSSR )
SDCCH_traffic_other_mo_rate ( -
AuthorPosts
- The forum ‘Telecom Design’ is closed to new topics and replies.