Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

handover failure due to protocol error

Viewing 15 posts - 16 through 30 (of 39 total)
  • Author
    Posts
  • #61748
    pix
    Guest

    akki,

    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, …?

    Regards
    pix

    #61749
    Akki
    Guest

    Hello Pix,

    I have checked and found some of the BTS are on free run mode. Problem resolved after making it PCM synh.

    Thnx

    #61750
    Akki
    Guest

    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????

    #61751
    pix
    Guest

    akki,

    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?

    Cheers
    pix

    #61752
    Akki
    Guest

    Hello Pix,

    Its SUM board OCXO adjustment “Voltage control basis” in ALU BTS.

    #61753
    Akki
    Guest

    Hello guys,

    Does anybody know about this????

    #61754
    Smart
    Guest

    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?

    #61755
    ALU
    Guest

    Dear All,
    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?

    #61756
    pix
    Guest

    hi alu,

    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.

    Cheers
    pix

    #61757
    ALU
    Guest

    Dear Pix,
    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 :)?

    #61758
    pix
    Guest

    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 ?

    cheers
    pix

    #61759
    ALU
    Guest

    Dear Pix,
    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 4755

    #61760
    pix
    Guest

    hi alu,

    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.

    Regards
    pix

    #61761
    ALU
    Guest

    Dear Pix,
    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?

    #61762
    pix
    Guest

    hi alu,

    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 ๐Ÿ™‚

    cheers
    pix

Viewing 15 posts - 16 through 30 (of 39 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.