Changes to the paging subsystem

[Holger Freyther]

On 04/19/2010 09:40 PM, David A. Burgess wrote:
> Even if two MS collide with the same random number at the same time, and
> one RACH burst overpowers the other enough to be detected and decoded,
> the L2 contention resolution procedure will usually prevent a complete
> failure, at lease for one of the MS.


>>> The other problem is with the 20 paging requests every two seconds I'm
>>> creating a RACH DoS for my BTS to a point that I think (didn't bother to
>>> do the easy math, and I don't have the spec here right now) we have two
>>> MS picking the same random number. At least the symptom is that even if
>>> we assign a channel, it gets closed down with a RF Failure.
>>
>> I wonder how frequently it happens with 20 MS that a RACH is sent on the
>> same frame and with the same random number. There are at least 16
>> possible


Hi David, Dieter,

you are both right and this was wishful thinking on my side. I'm able to
reproduce the problem locally and the root cause seems to be among the
lines Harald has pointed out in a previous mail.

My test setup is to always have 200 pending paging requests (so we will
mostly constantly page) and then try to place a call from a MS.

What happens is that the IMMEDIATE ASSIGNMENT does not make it to the
phone fast enough and the same MS is sending another RA and we assign
another channel.


The root causes consist of various issues:
	- Our delay in src/input/ipaccess.c does not help, removing it
          is breaking the rugby sized BTS though..
	- Our paging layer sends the paging command in bursts... we
          should have an even distribution of them.
	- We have some NM attributes to play with.

I am going to poke this some more.