PDA

View Full Version : --Intensive Location updates--



rimoucha
2010-08-09, 11:36 PM
Hello,

My Huawei GSM network is experiencing random intensive location updates (not related to one BSC,not related to one cell) which causes the CSSR to drop.Any ideas?

Many thanks

tpkj
2010-08-10, 02:17 AM
Hello,

My Huawei GSM network is experiencing random intensive local updates (not related to one BSC,not related to one cell) which causes the CSSR to drop.Any ideas?

Many thanks

Do you mean location uptates?:confused:
Is it across whole network?
Have you checked HPLMN timer?;)

rimoucha
2010-08-10, 06:21 AM
Hello,

Thanks for your reply! this problem affects cells randomly across the whole network(too many location updates for no clear reason) and at different times of the day.Please find attached an example.
I didn't checked the HPLMN Timer,Could you please explain how this parameter impacts location update procedure? what are the recommended values?

Many thanks:)

moslyi0891
2010-08-10, 07:16 AM
Hello,

Thanks for your reply! this problem affects cells randomly across the whole network(too many location updates for no clear reason) and at different times of the day.Please find attached an example.
I didn't checked the HPLMN Timer,Could you please explain how this parameter impacts location update procedure? what are the recommended values?

Many thanks:)


Mostly check those cells if they are LA boarder

Check if those cells are on BSC boarder as well

If No

Tell the core about your problem.. I mean you can specify that your BSC was ok then it becomes having too much LA updates:confused:

wolverine
2010-08-10, 08:01 AM
Very interesting. We have the same problem in our network using E*******! They term them LAC storms, and they are telling us they are caused by some faulty handset which however cannot be identified as neither the IMEI or the IMSI are sent in the channel request message.. Have you raised this with your vendor?

rimoucha
2010-08-10, 08:10 AM
Thanks for your Reply.
Mosly =>The impacted cells are neither on LA border nor on BSC border.
Wolverine =>We have already raised the problem to our vendor but until now the issue is under investigation.If there is any updates I will let you know.

moslyi0891
2010-08-10, 03:34 PM
Hello,

Thanks for your reply! this problem affects cells randomly across the whole network(too many location updates for no clear reason) and at different times of the day.Please find attached an example.
I didn't checked the HPLMN Timer,Could you please explain how this parameter impacts location update procedure? what are the recommended values?

Many thanks:)


Thanks for your Reply.
Mosly =>The impacted cells are neither on LA border nor on BSC border.
Wolverine =>We have already raised the problem to our vendor but until now the issue is under investigation.If there is any updates I will let you know.

Then it is core problem ask the core to solve and how long this problem is coming like this ??
which vendor you are treating with ??

rimoucha
2010-08-10, 09:48 PM
Hello,

The problem appeared from the beginning but now as the network grows it's becoming more and more frequent.Vendors: BSS part=Huawei,Core part=E*******.
Do you know what kind of core problem could it be?

Best Regards,

moslyi0891
2010-08-10, 11:03 PM
Hello,

The problem appeared from the beginning but now as the network grows it's becoming more and more frequent.Vendors: BSS part=Huawei,Core part=Ericsso n.
Do you know what kind of core problem could it be?

Best Regard s,

I used to raise Trouble Ticket to core network and there was one guy taking care of many things like IP planning and he used to solve the problem ,,, the problem was solved many times

In your case as the BSS is Huawei : I suggest to raise trouble ticket to Huawei so they can trace the BSC or the RNC and gove you back the logs so you can analyize more and more ..usually Huawei porblems are software problems so they update the software
then if not solved you can raise Trouble Ticket to E******* core network:o which is probaply they have problem so they solve this problem

oswe
2010-08-11, 06:16 AM
Hello,

The problem appeared from the beginning but now as the network grows it's becoming more and more frequent.Vendors: BSS part=Huawei,Core part=E*******.
Do you know what kind of core problem could it be?

Best Regards,

We had the same...
and we discovered that the LU reject cause was changed. Then, the mobile phone kept on doing LU !!!

I went to simulate on the old TEMS900 those LU reject causes and it is true... I dont quite recall now but if you have PLMN invalid as reject cause the phone KEEPS on doing LU attempts. So after a huge fuzz core people never explained why happened but they fixed it with a patch very fast....

Im not saying is your problem, just to let you know that the phone behaves differently in regards the LU_reject cause

hugs!

wolverine
2010-08-12, 04:49 AM
Please clarify, the problem is not that you are getting too many location update requests towards the core network, but you are getting very big random spikes of channel request messages with cause code LAU. These never carry on any further (i.e. the core network never receives these). However because the BSC has to assign an SDCCH every time a channel request is received you are getting SDCCH congestion.

Is this correct?

moslyi0891
2010-08-12, 05:27 AM
Please clarify, the problem is not that you are getting too many location update requests towards the core network, but you are getting very big random spikes of channel request messages with cause code LAU. These never carry on any further (i.e. the core network never receives these). However because the BSC has to assign an SDCCH every time a channel request is received you are getting SDCCH congestion.

Is this correct?

Your answr is seintifically very good but he did not mention that there is SDCCH Blocking over the BSC ..anyways let s see his answer

rimoucha
2010-08-14, 08:51 PM
Hi Guys,

Thanks for your answers.
Wolverine you have absolutely reason! I meant random storms of channel request location updating (A300F huawei Counter) which results inevitably in SDCCH congestion (RR370 huawei counter) and this impacts CSSR & SD blocking rate.At first we thought that this issue might be related to other operators' customers trying to access our network when theirs are down but this is not a relevant explanation as the issue is recurrent..

Best Regards,

alg_optim
2010-08-14, 09:08 PM
Did you perform a trace to which give you more details about these IMSI .



Hi Guys,

Thanks for your answers.
Wolverine you have absolutely reason! I meant random storms of channel request location updating (A300F huawei Counter) which results inevitably in SDCCH congestion (RR370 huawei counter) and this impacts CSSR & SD blocking rate.At first we thought that this issue might be related to other operators' customers trying to access our network when theirs are down but this is not a relevant explanation as the issue is recurrent..

Best Regards,

rimoucha
2010-08-18, 12:40 AM
Hello,

We made the trace but we couldn't find the IMSI as there is no "EST IND" Message!! In fact,the BSC never receives the Establishment indicator message "EST IND" from the BTS (which contains the IMSI).
Any ideas?

BR

wolverine
2010-08-18, 02:04 AM
Very interesting.. this is exactly the same problem we are having but on an E******* BSS. E******* have told us that it is due to some "rogue" handset/s. Of course as you say there is no way of identifying these handsets as the IMEI/IMSI is not included in the channel request message.

What I don't understand though is how come only the two of us have experience d this problem and not everybody else..

coach
2010-08-21, 06:24 AM
Hi all,

In our network we have experienced this problem as well (we have both E******* and Huawei's Access Network, and E******* Core Network). We've heard from Huawei the same explanation: some rogue MS performing massive Location Update.

However, in my case I haven't observed SDCCH congestion because of this, but an abnormal increase on counter CA304 (Call Setup Indications Timed Out). This counter increases when, after the BSS sends the Immediate Assignment message to the MS, it doesn't answer back with the "Established Indication" message after a time given by timer T3101.

BR

rimoucha
2010-12-16, 01:59 AM
Hi Guys,

Any updates on this issue?

BR

ullazusman
2011-01-08, 01:33 AM
Hello Guys,

Any other person with same issue and have a solution for it.

Any info will be useful in troubleshooting.

BR.

kyokuman
2011-07-06, 01:25 AM
Any update about this topic ?

I have same problem here. High LA updates, even not at LAC borders.
No SD congestion noticed but heavy Call setup indication Timedout, as mentioned already.

Thanks

gstack15
2011-12-19, 06:41 PM
Just wondering if anyone ever came up with a solution for this , I am working on a Huawei network and we have cells with huge increase on SD Fails due due to Timeouts A3040 ;
Any info appreciated .

EngSoft
2011-12-19, 07:03 PM
its it random and just a spike as you show , its mostly from one user . ( UE defected ) as i understand you are using Huawei , i guess there is a tool that can list the fault and mapped them to a specific IMSI . In huawei 3G its called insight shape. for me i found a IMSI that casing a 400 RRC failure and when we check the mobile was defected.

so you can try this approach.

gstack15
2011-12-19, 09:10 PM
Yeah its not random as in its on certain cells but consistently on those cells .
It probably is an issue with certain MSs but we cant trace as the MS is failing on assignment we will be unable to read the IMSI ;
On the ABIS traces of the cells I have analysed the sig strength is ok the Access delay is very small typically 1 or 2 yet the MS does not respond and we get timeouts .

asifhaider919
2012-01-13, 11:27 PM
You people are not alone in facing this problem :)

We have this on Nokia aswell. And the explanation from R&D is the same "Faulty mobiles", we are expecting to have it resolved in the next BSC software release MP11.

The explanation of Rogue/Faulty mobiles though looks a bit weird but seems justifiable.

Just try to see: if you are having SD LU storm on any cell, check the neghboring cell ... in 90% cases the problem is present on neighboring cell as well at the same hour.


@Gstack15 Can you please share the ABIS trace. I was not able to get the traces as we didnt have the trace available. I would appreciate your gesture.

beniy
2012-01-14, 01:53 AM
Dears,
In our country we have same issue.
Both E******* and Huawei BSS and core is Huawei.

E******* said that's stormy rach req and they gave one patch after that problem solved.
But We esclated to Huawei there is not any update till now.

stream19
2012-01-14, 05:26 AM
same issue in our network (huawei, E///, and siemens) nothing for Nokia and still not solved

gstack15
2012-01-19, 09:30 PM
Sorry Man I no longer have the trace apologies :(

kadry
2012-01-20, 06:20 AM
in Huawei,we faced this problem many times in our network ,some of them solved by
restart level 4

gogotchiya83
2012-05-29, 10:09 PM
any update PLZ (we have the same problem in our Huawei network)?

dst313
2012-06-01, 11:28 PM
Hi all,
After reading all of this thread I can say that I've experienced the SAME issue in Nortel BTS GSM.
I've observed a thounsands of RACH Failure due to Channel Request for Location Updates.

The BTS involved on that problems were near across country border.

I've spent more than 6 months debugging that problem.
I'm not 100% sure but I would say that this problem was caused by a faulty mobile or some other strange device that was trying to perform some deny of service on the network just sending Channel Request using RACH frames.

After trying several steps to debug this issue, we had an action plan to track down the faulty mobile:

- Since the only data from MS that we had available was the TMSI in Paging Response Message then:
- Try to correlate IMSI with TMSI in MSC/VLR/PrePaid Platform

Altough this was performed, it was no possible to locate the faulty mobile using that method.
The Nortel GSM network was uninstalled and we lost the possibility to track this issue.

hope this helps.

Mdaf
2012-06-21, 04:42 AM
Have you checked flow control? Being from sites/BSC/core side, in case of overload this will activate barring and when the barring is over the mobile will perform LUs

parsarka
2012-06-22, 12:48 AM
Hello,

Thanks for your reply! this problem affects cells randomly across the whole network(too many location updates for no clear reason) and at different times of the day.Please find attached an example.
I didn't checked the HPLMN Timer,Could you please explain how this parameter impacts location update procedure? what are the recommended values?


Many thanks:)


For Huawei, Please check at the BSS End what is the value of CRH kept.If this is due to some particular cell pls increase the value of this parameter to 10 or 12 & observe the post KPIs

gogotchiya83
2012-06-22, 12:50 AM
can you give more details?
What's you mean by the "CRH kept"?

gogotchiya83
2012-06-22, 01:10 AM
Bellow some traces made on the Abis interface.

28111

khurrambilal01
2012-07-31, 08:06 PM
So, Did anybody find any further observations/results? Why the specific mobile has so odd behavior & why this behavior is short in nature, Why doesn't it keep on doing the same and stops after some hours/days?

Syed Fahad
2012-08-01, 08:10 AM
Dears,

We also faced the same issue in all Huawei BSC's in our Network. We enabled the traces at Um Interface, and from these traces filtered the LU Requests and IMSI's requesting the LU's. When these IMSI's were shared with NSN Core, they were all found out to be International Roaming IMSI's, with LU Reject Messages mostly as " Roaming Not allowed in the LAC" and " PLMN not allowed". From here we initially got the idea that this problem is only faced and created by Roamers, and no LU Reject Message is returned from Our Subscriber IMSI. Even the Drive Test Results during this degradation Time on the effected cells showed no abnormality.
Having said that one trial was done during the degradation time on the degraded cells, and that was to restrict the 2G-3G IRAT Reselection Criteria, and problem was vanished.!!!!!!
If the issue is being faced in 2G-3G Co located cells, or 3G Cells in the area, try to restrict the 2G -3G IRAT Reselection Criteria by setting the FDD Repquant = RSCP, RSCPMinThreshold = 15 / -84dBm and FDD Q Offset = 8.

@Khurram The Reason why this problem resolves at its own might be the fact that after sending the continuous Channel Requests for LU, the MS battery dries off.

mbouchamekh
2012-08-01, 12:26 PM
for me it looks like UL interference (Probably External) apearing in some location where the affected cells are....anyway to understand more..u should make a frequency Scan on the affected cells during the problem time ....

khurrambilal01
2012-08-01, 03:08 PM
We already did UL/DL frequency scanning using Huawei timeslot scanner and also from Statistics there was no jammer in those specific hours/days.

khurrambilal01
2012-08-01, 03:18 PM
As per my understanding there are now two things, Firstly @Syed Fahad, your case is somehow different because in your case you are getting response form the Core side with some LU reject cause but the case we are talking about is that the MS does never reply with Establish indication message when SDCCH was being assigned in response to channel request for LU on RACH which means still no request for LU was sent to Core side!

So the major issue we are currently facing is MS doesn't reply back with Establish indication message and continues to ask for LU again and again!

Second question is if it's due to some specific Chinese or other Mobile then how come it stop at some instance? That subscriber is still there but doesn't remain a problem for us, Why?

Syed Fahad
2012-08-01, 06:35 PM
Yeah, In my case, there is no Immediate Assignment, therefore no Call Setup Indication and automatically, Immediate Assignment Success Rate Degrades due to low Call Setup Indications and high Channel Requests for LU.

usama0795
2012-08-01, 09:17 PM
i have got alot of Location update experts on this thread....help me out....issue is under the carpet but just want to know the technical explanation for the below issue.......

http://www.finetopix.com/showthread.php?29342-Actix-Location-Update-Fail&p=179870&highlight=#post179870

Fado
2012-09-10, 11:16 PM
did you guys checked any MTP signallink link failures?if there is a signalling issue all ms's will try to reconnect and will do LU at same time which will increase LU numbers...especially if this is a network wide (or some area under same mgw) issue..and if it is happening in short while...