19 Apr
2010
19 Apr
'10
10:14 a.m.
Hello Holger,
On Mon, 19 Apr 2010 12:37:12 +0800, "Holger Freyther" <zecke(a)selfish.org>
wrote:
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
random numbers for the "Answere to Paging" Channel Request and there are
27 frames in the MF to chooses from (in the "Combined Configuration").
Do you use the same phones for testing and does the RF Failure happen
frequently (this probably would mean a bad random number generator in
this phone firmware) ? Also I would expect that two RACH burst will
disturb each other, at least in a testing environment where all the
MS have the same distance to the BTS and send with the same power.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
19 Apr
19 Apr
3:40 p.m.
New subject: Changes to the paging subsystem
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.
On Apr 18, 2010, at 11:14 PM, Dieter Spaar wrote:
Hello Holger,
On Mon, 19 Apr 2010 12:37:12 +0800, "Holger Freyther"
<zecke(a)selfish.org> wrote:
David A. Burgess
Kestrel Signal Processing, Inc.
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
random numbers for the "Answere to Paging" Channel Request and
there are
27 frames in the MF to chooses from (in the "Combined Configuration").
Do you use the same phones for testing and does the RF Failure happen
frequently (this probably would mean a bad random number generator in
this phone firmware) ? Also I would expect that two RACH burst will
disturb each other, at least in a testing environment where all the
MS have the same distance to the BTS and send with the same power.
Best regards,
Dieter
--
Dieter Spaar, Germany
spaar(a)mirider.augusta.de 
20 Apr
20 Apr
4:42 a.m.
New subject: Changes to the paging subsystem
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.
26 Apr
26 Apr
10:16 a.m.
New subject: Changes to the paging subsystem
On 04/20/2010 10:42 AM, Holger Freyther wrote:
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.
Hi,
I have the following changes in my branch:
1.) instead of sending n paging requests in a big bulk, send one every
couple of milliseconds. Even if the CCCH Overload warning should be
fine, in my experiments the nanoBTS didn't really like it. The delay in
milliseconds was tested like this. I was having 200 pending paging
requests and I was making the delay big enough to not run into messages
from the nanoBTS about dropped paging requests. I think that change is
okay to land and should not interfere with anything.
2.) the other one is to not send a paging request when there are no free
channels for that given type. This is configurable and off by default. I
think this is meeting LaF0rge's requirements about such a change.
5138
days inactive
5145
days old
3 comments
3 participants
participants (3)
-
David A. Burgess -
Dieter Spaar -
Holger Freyther