- This topic has 26 replies, 1 voice, and was last updated 13 years, 2 months ago by
.
-
Posts
-
T_IA indicates the maximum time a CS IMMEDIATE ASSIGNMENT message remains in the AGCH queue. T_IA must be less than T3101 as Pix indicated.
What are the disadvantages of increasing the T3101 to high value, for example T3101 = 24?
Rajiv Gujral,
As I understand from the definition of T3101, assignning a big value of such a timer will not increase the call setup time as you have said !
If T3101= 3sec that means if the mobile will not access the provided sddch traffic before 3 sec, the assigment message will end. This 3 sec is the maximun period to start call setup; it is not the real period;
In other words, if a mobile accessed the sdcch given via the AGCH in 1 sec, the timer will not stop him ! Anybody tell me if i am wrongBR
Akefa,
a timer too long will penalize sdcch availability when ghost rach are occuring.
a ghost rach requires a SDCCH, so the system allocates a SDCCH for T3101. Since the ghost rach is just a ghost, it doesn’t need the sdcch, but the BSC has allocated it for this period already… and wait until the end of the timer.regards,
yes pix i am agree with you I know that high T3101 will give a big chance to the phantom RACH to make sdcch busy. That is right but what i am not agree with is that the high t3101 will delay the honest RACH 🙂
If there is no phantom rach, there is no problem with with the timer even if t3101=10000000000 seconds 🙂
Ho OK, sorry. so we all agree 🙂
no, there is no problem for an honest RACH. But ghosts are always around ! boo.
Hello,
Would like some advise:
customer complaints on hard to setup a call:
– low immediate assignment success rate
– relatively high SDCCH successful seizure
– Low SDCCH & TCH congestion.Initially thought there might be insufficient AGCH assigned.
After checking parameters:
AG reserved = 2 blocks
T3101 = 3s
CCCH = non-combinedRight now haven’t received alarm history logs & drive test results
What else could be the cause? Any suggestions?
Thank you
hello,
are the complaints about one cell or many cells ?
are the cells using ABIS over satellite ?
I don’t think the immediate assignment is the problem (this is a very rare problem), but you can check the qos statistics in order to determine more precisely the nature of the problem. Can you give me the following values at busy hour, for the worst cells encountering this problem ?
SDCCH assignement unsuccess rate = ?
– due to radio ?
– due to congestion ?
– due to bss problem ?SDCCH drop rate = ?
– due to radio ?
– during handover ?
– due to bss problem ?TCH assignment unsuccess rate = ?
– due to radio ?
– due to congestion ?
– due to bss problem ?TCH drop rate = ?
– due to radio ?
– during a handover ?
– due to bss problem ?what is the average duration of a SDCCH seizure and of a TCH seizure ?
Regards,
Hi Pix,
Thank you for your prompt reply.It happened to majority of the cells in a region, a few cells have particularly bad KPIs.
The operator just performed a MSC migration, although we suspect the MSC para might be wrong. To be safe, we checked on the rf part before going that far.
Worst case:
SDCCH assignement unsuccess rate = 0%
– due to radio = 0 (avg 0.1)
– due to congestion = 0 (avg 0.1)
– due to bss problem = 0 (avg 0.1)SDCCH drop rate = 1.1
– due to radio = 1.1
– during handover less than 0.1
– due to bss problem less than 0.1TCH assignment unsuccess rate = avg 0.1
– due to radio avg 0.1
– due to congestion avg 0.1
– due to bss problem avg 0.1TCH drop rate = 1
– due to radio = 1
– during a handover avg 0.1
– due to bss problem avg 0.1Thank you
hi,
are you using alcatel system ? if yes, it would explain why you could match my request so quickly… if you were using another system, you wouldn’t be able to mach the indicators names in such a short time 🙂 but i’m suprised to see the sdcch assgnt fail is so low… normally it should be around 5% to 10%…
i’ve never seen an average of 0% on a network 🙂 And i’ve never seen 0.1% TCH assignment unsuccess either.. your values are very very low… almost “abnormally” low.so if there is a call setup failure, it might be before the sdcch assignment phase, meaning it should be between the RACH / PCH and the AGCH. Have you checked the counters associated to these messages ?
Yet, the RACH/AGCH messages are not involving the MSC, so the new MSC in your network will certainly not be the cause of the problem.
The drive tests should give you a clear indication on the problem you’re having, it’s a good idea to wait for it. Check the layer 3 messages, to find out at what point exactly the call setup is failing.
Regards,
Dear All
Do you have other enhanced algorithm:
Immediate assignment on SDCCH
– If signaling => remains on SDCCH
– If speech/data => assignment to TCH
• Immediate assignment on TCH
– If SMS => transferred by the SACCH part
– If signaling (LU, supplementary services etc.) => transferred by the
FACCH part
– If speech/data => change of channel mode at assignmentHi Pix,
I think T_SDCCH_PC is not a nokia parameter. Can you please tell me the parameter or counter in Nokia which is related to SDCCH power control
yogesh,
i don’t have nokia parameters documents… sorry.
