- This topic has 38 replies, 1 voice, and was last updated 8 years, 9 months ago by Mic.
8th November 2010 at 20:10 #61748pixGuest
i’ve no idea about these numbers. The way it works is that you compare the frequency of the oscillator with a reference oscillator, and ensure the difference is below a certain threshold.
Can you check what is the synchronization mode of this BTS ? Free Running, PCM, …?
pix15th November 2010 at 12:39 #61749AkkiGuest
I have checked and found some of the BTS are on free run mode. Problem resolved after making it PCM synh.
Thnx15th November 2010 at 12:42 #61750AkkiGuest
I have one doubt….!!!
In Nokia BTS, DAC value is 2048. what should be the value of clock ref. value for ALU BTS.
I think it should be same.
Does anybody has any view on this part????15th November 2010 at 19:28 #61751pixGuest
glad i could help 🙂
i don’t remember there is a clock value in ALU BTS… What is the name of the parameter ? Where do you see it?
pix17th November 2010 at 08:34 #61752AkkiGuest
Its SUM board OCXO adjustment “Voltage control basis” in ALU BTS.8th December 2010 at 14:14 #61753AkkiGuest
Does anybody know about this????14th April 2011 at 08:04 #61754SmartGuest
hi. Im having the same problem with HO failures
*** Layer 3 Message type: Handover Failure
Protocol discriminator : (6) Radio resources management messages
Value : (111) Protocol error, unspecified
Im using huawei. were can I check the clock?19th December 2011 at 11:37 #61755ALUGuest
All of a sudden we started to have degradation in Inter BSS Handover Success Rate for 3 BSCs(ALU) of a city.Note that Intra BSC HO Success Rate is totally fine and problem is only for the bordering cells of these BSCs which are having high percentage of ROC now. Also, the Core is a pool MSC which contains 8 BSCs of this city whereas the problem is only observed in 3 BSCs. Still we escalated the issue to Core but no problem found. Similarly on doing the audit on Cell/BSC level, no discrepancy or change observed that could have led to this degradation. On doing the Drive Test, it is found that all Failures are of the b/m cause:
“Value : (111) Protocol error, unspecified”. Also, the time difference btw HO Cmd and HO Failure is very small. We get HO Cmd, followed by HO Access(sent by MS) and HO Failure and all these messages come within a second.
I have done the delete/recreate of problematic HO Relations, SUMA Reset and lastly just changed the Clock Synchronization mode from PCM Synch to Free Running(just as a trial). The effect of this last action is still under observation. Do you have any clue that what could be the reason behind this degradation?19th December 2011 at 12:51 #61756pixGuest
you forgot to mention the direction of the HO : which side is ALU ? is the problem in both direction ? which vendor is on the other side ?
the usual suspect is the core network… especially if there wasn’t any change on the BSS.
In the core network, they might have performed an upgrade of some kind, but wouldn’t consider it as a possible cause of problem 🙂
anyway, since HO CMD is sent to MS, I think all routing is well performed within your NGN. It looks like the channel request from the MS is not what the NGN expected… If I were you, I would double-check with NGN if they did anything at the hour when the problem appears
-> yes, btw, did the problem start on 3 BSC at the same hour on same day ? that could help the diagnostic 🙂
-> are you able to see the problem in the qos stats? can you verify that the problem is contained to only 3 BSC ?
-> check again the direction of the problematic ho’s.
pix20th December 2011 at 06:29 #61757ALUGuest
All BSCs are of Alcatel.There is no other vendor in this area. All the three BSCs(say A,B,C) are located in the same vicinity. I think the problem is with BSC “B”. All outgoing HO’s from (B to A) and (B to C) are having this problem(note that B only has border with these 2 BSCs). However, A and C have borders with multiple BSCs but for them,only the outgoing Handovers towards B are failing. So, thats why I think there should be something wrong with BSC “B”.
The problem is only with these 3 BSCs and its showing from the NPO Reports aswell.There is degradation in Outgoing Inter BSC Handover Success Rate for these 3 BSCs. Percentage of ROC has increased and correspondingly degradation in CDR observed aswell.
Also the problem started for all the BSCs at the same hour. Now, BSS/Core Team are still insisting that there was no activity from their side that led to this degradation. What to do now :)?21st December 2011 at 06:55 #61758pixGuest
well… restart the BSC ! 🙂
have you checked parameters modification at BSC level, in NPO ? I guess there are some obscure BSC parameters that could strongly influence HO.
Can you share with me the values of the following eight indicators, for one full day:
external incoming HO preparation success (nb and %)
external incoming HO efficiency (nb and %)
external outgoing ho prep success (nb and %)
external outgoing ho efficiency (nb and %)
in one border cell of each BSC ? (so that would be 4 cells altogether : in A next to B, in B next to A, in B next to C, in C next to B)
Since MSC team tells you there is no activity on their side, then it has to be on the BSC side…………………….
Do you have possibility to perform A interfaces traces ?
pix25th December 2011 at 08:30 #61759ALUGuest
Sorry for the late reply.Here is the data that you requested for 2 cells belonging to 2 different BSCs.Note that we have checked and there wasn’t any parameter modification at BSC level.Also traces are being done at A/Abis Interface and issue has already been escalated to RTAC.
Cell A Data Pre Post
HO_Out_MSC_2G_2G_efficiency_rate(GHOOMEFGR) (%) 99.02% 80.38%
HO_Out_MSC_2G_2G_success(GHOOMSUGN) (nb) 4241 4393
HO_Out_MSC_2G_2G_prep_success_rate(GHOOMRQGR) (%) 99.19% 98.45%
HO_Out_MSC_2G_2G_request(GHOOMRQGN) (nb) 4283 4977
HO_Inc_MSC_2G_2G_efficiency_rate(GHOIMEFGR) (%) 96.43% 85.64%
HO_Inc_MSC_2G_2G_success(GHOIMSUGN) (nb) 4725 2583
HO_Inc_MSC_2G_2G_prep_fail_rate(GHOIMPFGR) (%) 0.10% 0.13%
HO_Inc_MSC_2G_2G_request(GHOIMRQGN) (nb) 4905 3020
Cell B Data Pre Post
HO_Out_MSC_2G_2G_efficiency_rate(GHOOMEFGR) (%) 95.51% 85.06%
HO_Out_MSC_2G_2G_prep_success_rate(GHOOMRQGR) (%) 99.12% 98.56%
HO_Out_MSC_2G_2G_request(GHOOMRQGN) (nb) 4144 4391
HO_Out_MSC_2G_2G_success(GHOOMSUGN) (nb) 3958 3735
HO_Inc_MSC_2G_2G_efficiency_rate(GHOIMEFGR) (%) 98.51% 92.59%
HO_Inc_MSC_2G_2G_success(GHOIMSUGN) (nb) 4704 4401
HO_Inc_MSC_2G_2G_prep_fail_rate(GHOIMPFGR) (%) 0.00% 0.04%
HO_Inc_MSC_2G_2G_request(GHOIMRQGN) (nb) 4775 475525th December 2011 at 10:25 #61760pixGuest
no problem for the delay, it’s great that you continue sharing 😉
so both ways are impacted, and it is always in the execution phase, exactly as you experienced it during the drivetests. So there is nothing more that can be “proven” here, except that the failures are occuring in *both* directions, and not only in *one* direction as you described before.
(look at the outgoing efficiency rate in each cell, it’s around 80% to 85%).
so only 15% of calls are impacted by this failure. Which means it is not a problem that occurs all the time. Are those AMR calls ? FR ? HR ? MS which are GPRS-attached ? I don’t know.
Perhaps at has to do with few A-interface channels which are misconfigured (or AterMux ?), and as soon as a call is supposed to land on one of those channels after a HO, then there is a failure.
From A interface traces, are you able to isolate those faulty HO ?
Do you see the kind of radio channel and on which A interface those calls are being put on ? Is there anything similar among those HO ?
HO Required / HO Request / HO Response / ISUP msg / HO Command / HO Detected…
From those messages you should find all those info.. If you want to display all messages of one instance of a faulty HO here, don’t hesitate ! 🙂
The rtac will probably request such flow if they don’t already have encountered this problem before.
pix26th December 2011 at 12:22 #61761ALUGuest
The RTAC/BSS Team is already investigating the traces and we are waiting for their response. In the meanwhile, continuing our investigation over here, we know that after the HO ACCESS Bursts, we don’t see any Physical Information message from the BTS and the timer “T3124” expires resulting in HO Failures. Now, in the message flow, I see that once the MS Sends a HO Access, a msg HO Detection is sent from BTS to BSC and a corresponding msg DT1 HO Detect sent from BSC to MSC. Now, do you think that sending of Physical information from BTS is related with this DT1 HO Detect(BSC-MSC) or is it(Phy Info) sent irrespective of whether DT1 HO Detect message was successful or not?26th December 2011 at 21:54 #61762pixGuest
the bts should send the PHY INFO asap in order to stop the sending of the HO ACCESS msg.
There are a lot of good info on 3GPP TS04.18 (or 44.18). One thing you could try is decrease T3105 to the minimal possible value (0 ?):
When sending the PHYSICAL INFORMATION message, the network starts timer T3105. If this timer times out before the reception of a correctly decoded layer 2 frame in format A or B (see 3GPP TS 04.06), or a correctly decoded TCH frame from the mobile station, the network repeats the PHYSICAL INFORMATION message and restarts timer T3105. The maximum number of repetitions is Ny1.
But anyway, it looks like a BTS problem, because it seems to me that this PHY INFO should be sent by the BTS whatever the status of the HO.
BTW, this msg is sent only in case of ASYNCHRONOUS HO –> can you disable synchronous HO, in order to force all HO to be async ?
Let’s see what the real problem is, but at least it allowed us to gain good knowledge on this specific area.
And my apologies to NSS, for once they don’t seem to be involved in an external HO failure 🙂