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

handover failure due to protocol error

Viewing 15 posts - 1 through 15 (of 39 total)
  • Author
    Posts
  • #61733
    hary
    Guest

    in a network for we face inter msc ho failure between vendor a core to vendor b core . we suspect the ciphering mode may be the issue … can any one help me to solve it

    #61734
    AliAsgher
    Guest

    Can you verify the ciphering algo used in both External Cells? You can also confirm this via DT. (In case of ciphering issue, handover from one side to other should be happening. i.e. the side using higher ciphering algo will be able to transfer the call to cell with lower ciphering algo)

    #61735
    xyz
    Guest

    plz check ur msc version.

    #61736
    saydur Rahman
    Guest

    I am getting Protocol Error, Unspecified (Disconnect cause code 6f / 111) when I am sending Voip traffic from VPS switch to Quintum call relay. Could you please advice how could I solve this problem?

    #61737
    Akki
    Guest

    Hi i m getting “protocol error” msg as failure while inter cell handover in GSM. Could anyone please suggest a way around for this issue.

    #61738
    pix
    Guest

    hi,

    i would check the ciphering mode in both cells.
    if both sides are using the same ciphering mode (like A5/1), then it’s something else…
    To analyse it, double-check the content of the HO COMMAND received by the MS. Something in this message is irritating the MS.
    Frequency ? Ciphering ? Packet capabilities (is this a DTM call ?)

    Post the content of the HO CMD here if you want, we can check it together.

    Regards
    pix

    #61739
    Akki
    Guest

    Hi Pix,

    I think Ciphering mode (like A5/1) is defined at BSC level, not at cell level.
    Its A5/1 as priority 1 mode defined in BSC.

    Anyways i will get back with HO CMD…

    Thnx
    Akki

    #61740
    pix
    Guest

    hi akki,

    i thought it was a problem between two cells of different BSC. If both cells belong to same BSC, then …??? I’ve no idea… I would lean to a BTS hardware problem, or a BSC database definition.
    If the HO CD is correct, then you could delete and re-create the relationship in the OMCR, or even delete & re-create both cells (and BTS) to clean up the database.

    Does it happen with all the MS’s, all the time ?

    Regards
    pix

    #61741
    Rex
    Guest

    Hi Akki,
    if your equipment is ALU then try to change SUM card in the BTS (if Pix’s suggestions don’t solve your problem).
    Regards,
    Rex

    #61742
    AliAsgher
    Guest

    Alcatel is really strange. Never thought that I will have to delete/recreate HO relations to improve HSR between them ๐Ÿ™‚ Oh I am already missing Ericsson so much. (Even Huawei was not bad)

    Regards,

    Ali Asgher

    #61743
    pix
    Guest

    Rex : you’re right about the SUM card, it’s what I was thinking about when i said “bts hardware” problem. But I don’t think the message would be “protocol error”?

    Ali: you can’t say things like this on a forum… We have to respect telecom companies, whatever we subjectively feel about them. Now, fair comparisons are always welcomed, but I’ve never met any field engineer that have any major complaint about ALU, compared to other vendors. Each vendor has its own strong points.

    But anyway, if you never faced database discrepancies in E/// or Huawei, it doesn’t mean they don’t exist ๐Ÿ™‚ Databases will always show some bugs, once in a while. Note that in 6 yrs of field work, I -never- faced this “failed HO” due to database problem. I heard about it, and it was only once ๐Ÿ˜‰

    Cheers
    Pix

    #61744
    AliAsgher
    Guest

    Dear Pix,

    I always suspected that you may belong to Alcatel RF Research center or something. ๐Ÿ™‚ ๐Ÿ™‚ You always sound so patriotic about ALU.

    Anyways, in my current job I am looking after a network with ALU + Motorola equipment. And within 1 month have seen more than 10 cases where relation create/delete cell create/delete was done for KPI improvement. Never seen anything like this in Ericsson. Never even heard of any such thing.

    Regards,

    #61745
    Akki
    Guest

    Hello Ali/Pix/Rex,

    Thanks for all your suggestions. But we are loosing the track of the issue on this forum.

    Coming back to the issue, i have checked and found no issue with HO definations in database. HO failures are too irregular in nature. This issue is observed in intra cells HO as well.

    Getting this error msg in DT log.

    ////
    *** Layer 3 Message type: Handover Failure

    Protocol discriminator : (6) Radio resources management messages

    Value : (111) Protocol error, unspecified
    ////

    Any guy ever come across such error?????

    As of now i am check the clock sync status and whether it is calibrated or not for problematic BTS’s.

    Rex…if i found clk sync OK then i will try to change SUM board of one the BTS and check.

    #61746
    Pix
    Guest

    Ali-A,

    I sound patriotic ? I didn’t mean to… It’s just that I only know about 3GPP and ALU, and nothing about other vendors. I know ALU is not perfect, but it has some advantages too… ๐Ÿ™‚

    I’m not R&D ๐Ÿ™‚

    #61747
    Akki
    Guest

    Hello All,

    I have checked the ocillator clk value of sme of the problematic BTS’s….its 173, 3988, 1289 in some of the BTS. I think it shuold be 2048 (Nokia BTS DAC value). What is the default value of ALU BTS? Is it same??

    Thnx

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