yes, i meant the fast initial gprs access.
I’ve never tuned this parameter. It seems safe to put it back to the defaut value ! Default is 10,000 bytes, and current setting = 100 bytes ?! It will strongly reduce throughput for short transmissions, especially the UL TCP ACK, which will in turn reduce the DL throughput at the application (tcp) level.
Anyway, you understand what you need to do : degrade qos of users in order to decrease congestion. Altogether, I doubt that the end user experience will be different. The subscribers will perceive your network as very “poor”, whether their tbf is dropped because of CPU congestion, or their tbf is stuck on only one PDCH, or stuck on MCS5, or it is rejected because there is not enough pdch in the cell. The end result is similar for the subscriber.
Actually, if the CPU is congested, it will only affect end user during the busy hours (let’s say during 8hours/day). The rest of the time, users will enjoy good QoS.
If you start tuning your network with “hard” parameters, they will affect users 24hrs/day. That’s something that you get to keep in mind. The “transition” parameter you mentionned is interesting because it will only come into play when there is a failure. And failure will happen only during the busy hours. So that’s definitely a parameter that’s worth trying. Please let us know about the effect ! 😉
Regards,
pix