Change timer T305 and T308 in E///

[Optimustron]

Dear, could you please share GSM Spec. DOc that contains this information?

Please find the GSM SPECIFICATIONS one is from ETSI and de last one is from 3GPP from 2003 this is the last one. Regards, 0408-7l0.zip gsmts_0408v050300p.rar

[parsarka]

Hi...my system is NSN and tried the above but didnt observe and improvement...can u please let me knw how the same can be done in NSN??

[Optimustron]

I'm working in E******* and Huawei systems, but the condition is the same you need to check that T305 + 2*T308 < (N200+1)*T200, this is the start point, for E******* default values you have:

N200 (SDCCH) = 23 times	N200 (SACCH) = 5 times
N200 (FACCH / F) = 34 times	N200 (FACCH / H) = 29 times

T200 (SDCCH) = 51 frames	T200 (SACCH) = 312-416 frames
T200 (FACCH / F) = 30 frames	T200 (FACCH / H) = 34 frames

And each frame is 4.616 ms and so in each case the product (N200 +1) * T200 gives, you can make the maths:

SACCH = 8.64 - 11.52 sec	FACCH = 5.65 sec
SDCCH / F = 4.85 sec	FACCH / H = 4.71 sec

From the above we arrive at the values T305 = 2 sec and T308 = 1 sec these values gives us 4 in the equation and the smallest of the above at right hand of equation is 4.71 seconds, the default is the same for both timers T305 = T308 = 30 seconds in our E******* system I didn't see the Huawei default values and I need to check that if the values apply, then you need to see that values in NSN in order to see if that values apply or need to be changed or they are optimized. I'm searching for counters in the MSC side in order to keep on track of the DISCONNECTIONS in order to don't get lost of areas of bad coverage.

[prayoga]

Hi, those settings above for T200 is setable right?

[Optimustron]

It depends, because for E******* some of this are hard coded, specially the timers I mentioned previously, however you can change the same timers but for Abis that are not the same, however in Huawei systems you can change that values for that timers in a cell basis, the command is SET GCELLCCTMR in order to change that and LST for viewing. Best regards,

[Naruto28]

hi, how to view T305 & T398 actual values in MSC A interface (Printout command)?thks

[Naruto28]

hi, how to view T305 & T308 actual values in E*******MSC A interface (Printout command)?thks

[rosan]

Guys,

Have you tested these timers in 3G network? i.e. How this changes impact the 3G DCR if MSC is shared between 3G and 2G networks?

Thanks

[Piparebo]

Ladies and Gentlemen,
I would like you to consider the differences between "drop rate counters" and "real drop rate". An improved KPI does not necessarily mean an improved network service. Not if we have manipulated the way we count without improving the traffic handling itself.

Also please consider that "drop" is not a clearly defined concept. Do we mean abnormally terminated radio session, do we mean dropped call during speech phase or something else? Well, it depends who you ask. From core perspective it could be most relevant to consider "failing use cases" but from RAN perspective it is more relevant to consider “all radio failures”.

Through the years it has become more and more focus on drop-rate KPI. Too much focus maybe, because for many people it seems to be more important to get low drop-rate figures than to actually improve something. The debate about the T305 and T308 is an example of this.

In general, hiding specific identified failing scenarios may lead to that we later on fail to identify new root causes producing the same scenarios. For example it could be that some new terminals or new bug in the system produce the same scenario and if not observable in the system we may miss this.

Way forward:
Regarding the timers:
Don’t destroy the observability in our systems by hiding important information. Keep timers T305 and T308 high, let RAN take care of the timing and accept higher number of drop counts.

Regarding “CM Service Reject”:
When a mobile deserts a channel abnormally (without handshaking with system) and establishes a new connection instead, it is important that core can handle this without rejecting the service just because the old connection has not been cleared yet.

Immediate clearing of deserted channel to free up resources:
When above happens core could ask RAN to free the old channel immediately. As RAN does not know for sure if the mobile is still there or completely gone, it has to wait a very long time before reusing the old channel to ensure that there will be no clashing between new call and old call on the channel. A new cause code from core to RAN would be required.