- This topic has 38 replies, 1 voice, and was last updated 12 years, 11 months ago by
.
-
Posts
-
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
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)
plz check ur msc version.
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?
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.
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
pixHi 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
Akkihi 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
pixHi 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,
RexAlcatel 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
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
PixDear 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,
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 FailureProtocol 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.
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 🙂
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
- The forum ‘Telecom Design’ is closed to new topics and replies.
