Project

General

Profile

Feature #1752

Improve RACH detection / rejection

Added by laforge over 2 years ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
06/14/2016
Due date:
% Done:

100%

Estimated time:
Spec Reference:

Description

The current RACH burst detection/rejection logic in osmo-bts is quite sub-optimal.

At least for osmo-bts-sysmo and osmo-bts-lc15, we currently only have a threshold based on the fLinkQuality parameter.

However, there is no threshold based on the RSSI, and particularly none on the BER.

According to some theoretical analysis, it seems like a good choice for the BER threshold is "7/41", i.e. 7 out of the 41 bits of the RACH training sequence can be wrong, but 35bits should be correct.

To quote from Martin Kollár: METHOD FOR EVALUATION OF OUTAGE PROBABILITY ON RANDOM ACCESS CHANNEL IN MOBILE COMMUNICATION SYSTEMS

the theoretical BER limits of GMSK and BPSK based on Eb/N0 = 0 dB, the BER of
GMSK is 0.16. For the GSM where 41 represent the total number of bits in a 
RACH synchronization sequence this corresponds to ratio 7/41. So the threshold
k can be set to 7.

So we should have a configurable but default fBER limit of 7/41 = 0.17073170

It probably makes sense to pass BER, Link Quality and RSSI up into the common part via L1SAP, and
have the thersholds implemented there. This ensures uniform behavior accross hardware.

History

#1 Updated by laforge over 2 years ago

laforge wrote:

It probably makes sense to pass BER, Link Quality and RSSI up into the common part via L1SAP, and
have the thersholds implemented there. This ensures uniform behavior accross hardware.

this is true at least for osmo-bts-{sysmo,octphy,lc15} where we get both BER and RSSI. Not sure how osmo-bts-trx will fit in.

#2 Updated by laforge over 2 years ago

  • Assignee changed from msuraev to laforge

#3 Updated by laforge about 2 years ago

proposed patch in attachment, untested so far.

#4 Updated by laforge about 2 years ago

#5 Updated by laforge about 2 years ago

  • Status changed from New to In Progress

I've done quite an extensive test series and I cannot reproduce the issue.

I've used a RF pattern generator and tested with
  • a PN23 sequence of pseudo-random bits modulated at GSM bitrate
  • AWGN at 270kHz and 1MHz bandwidth
  • both over a range of -110 dBm to -30 dBm

osmo-bts-sysmo did not report a single ghost RACH in about one hour of testing.

in /dev/rtfifo/dsp_trace, we could see RACH being detected, but none of them reached the existing min_qual_rach threshold in osmo-bts-sysmo:

[3200]____[279612:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-75.8 dBm,  49 qbits, LQ = -4.2819, BSIC = 3F, BER = 0.1944 (7/36)]____
[3201]____[279769:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-74.7 dBm,  -8 qbits, LQ = -3.8764, BSIC = 3F, BER = 0.1111 (4/36)]____
[3202]____[279780:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-76.4 dBm,  35 qbits, LQ = -5.3870, BSIC = 3F, BER = 0.2500 (9/36)]____
[3203]____[279893:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-74.6 dBm,  64 qbits, LQ = -5.0313, BSIC = 3F, BER = 0.1389 (5/36)]____
[3204]____[279911:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 0]____[-76.3 dBm,  87 qbits, LQ = -5.0002, BSIC = 3F, BER = 0.1389 (5/36)]____
[3205]____[279934:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 0]____[-76.0 dBm,  -6 qbits, LQ = -5.3354, BSIC = 3F, BER = 0.1944 (7/36)]____
[3206]____[280046:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-76.0 dBm,  11 qbits, LQ = -1.5729, BSIC = 3F, BER = 0.1111 (4/36)]____
[3207]____[280166:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-74.8 dBm,  87 qbits, LQ = -7.0291, BSIC = 3F, BER = 0.1944 (7/36)]____
[3208]____[280315:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-71.0 dBm,  72 qbits, LQ = -6.1674, BSIC = 3F, BER = 0.1944 (7/36)]____
[3209]____[280632:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-63.4 dBm,  60 qbits, LQ = -1.6252, BSIC = 3F, BER = 0.1389 (5/36)]____
[3210]____[280636:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-61.4 dBm,  60 qbits, LQ = -7.9217, BSIC = 3F, BER = 0.1667 (6/36)]____
[3211]____[280774:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-61.5 dBm,  59 qbits, LQ = -4.0441, BSIC = 3F, BER = 0.1944 (7/36)]____
[3212]____[280891:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-59.6 dBm,  34 qbits, LQ = -6.3125, BSIC = 3F, BER = 0.1944 (7/36)]____
[3213]____[280931:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-58.6 dBm,   2 qbits, LQ = -3.8033, BSIC = 3F, BER = 0.1389 (5/36)]____
[3214]____[280936:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-58.5 dBm,  45 qbits, LQ = -3.7295, BSIC = 3F, BER = 0.1389 (5/36)]____
[3215]____[280981:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-58.4 dBm,  48 qbits, LQ = -5.2272, BSIC = 3F, BER = 0.1111 (4/36)]____
[3216]____[281142:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-56.1 dBm,   9 qbits, LQ = -5.7374, BSIC = 3F, BER = 0.1111 (4/36)]____
[3217]____[281208:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-57.7 dBm,  22 qbits, LQ = -1.4843, BSIC = 3F, BER = 0.1389 (5/36)]____
[3218]____[281464:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-53.3 dBm,  11 qbits, LQ = -5.3268, BSIC = 3F, BER = 0.1389 (5/36)]____
[3219]____[281636:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-46.3 dBm,  80 qbits, LQ = -5.1819, BSIC = 3F, BER = 0.1944 (7/36)]____
[3220]____[281677:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 0]____[-45.4 dBm,  10 qbits, LQ = -5.4181, BSIC = 3F, BER = 0.1944 (7/36)]____
[3221]____[281694:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-44.2 dBm,   4 qbits, LQ = -5.4208, BSIC = 3F, BER = 0.1389 (5/36)]____
[3222]____[281789:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-42.4 dBm,  27 qbits, LQ = -1.6029, BSIC = 3F, BER = 0.1389 (5/36)]____
[3223]____[281794:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-42.5 dBm,  70 qbits, LQ = -1.5491, BSIC = 3F, BER = 0.1111 (4/36)]____
[3224]____[281843:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 0]____[-40.8 dBm,   2 qbits, LQ = -6.7427, BSIC = 3F, BER = 0.1389 (5/36)]____
[3225]____[281904:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-39.8 dBm,  60 qbits, LQ = -7.0963, BSIC = 3F, BER = 0.1944 (7/36)]____
[3226]____[281909:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 0]____[-39.7 dBm,  88 qbits, LQ = -7.3934, BSIC = 3F, BER = 0.1389 (5/36)]____
[3227]____[282098:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-33.1 dBm,  56 qbits, LQ = -3.7389, BSIC = 3F, BER = 0.1111 (4/36)]____
[3228]____[282163:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-33.7 dBm,  45 qbits, LQ = -4.1827, BSIC = 3F, BER = 0.1389 (5/36)]____
[3229]____[282207:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-30.9 dBm,  -1 qbits, LQ = -5.1973, BSIC = 3F, BER = 0.1944 (7/36)]____
[3230]____[282212:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-31.1 dBm,  42 qbits, LQ = -5.1664, BSIC = 3F, BER = 0.1389 (5/36)]____
[3231]____[282217:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-31.1 dBm,  85 qbits, LQ = -5.2099, BSIC = 3F, BER = 0.1389 (5/36)]____
[3232]____[282258:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 0]____[-32.2 dBm,  15 qbits, LQ = -5.4180, BSIC = 3F, BER = 0.1944 (7/36)]____
[3233]____[282304:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-30.8 dBm,  20 qbits, LQ = -5.9130, BSIC = 3F, BER = 0.1389 (5/36)]____
[3234]____[282370:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-32.5 dBm,  32 qbits, LQ = -1.6946, BSIC = 3F, BER = 0.1389 (5/36)]____
[3235]____[282454:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 2]____[-31.1 dBm,  56 qbits, LQ = -6.7238, BSIC = 3F, BER = 0.1667 (6/36)]____
[3236]____[282512:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-32.1 dBm,  32 qbits, LQ = -4.1076, BSIC = 3F, BER = 0.1667 (6/36)]____
[3237]____[282517:0]____[L1]____[RX]____[RACH]____[ACCESS TYPE 1]____[-32.4 dBm,  75 qbits, LQ = -4.0598, BSIC = 3F, BER = 0.1944 (7/36)]____

So we need to understand how to reproduce the bug first.

#6 Updated by laforge over 1 year ago

  • Status changed from In Progress to New
  • Assignee deleted (laforge)

#7 Updated by laforge over 1 year ago

  • Assignee set to daniel

#8 Updated by laforge 10 months ago

  • Assignee changed from daniel to laforge

#9 Updated by laforge 7 months ago

  • % Done changed from 30 to 80

A BER based RACH threshold has now been introduced as part of the https://gerrit.osmocom.org/#/c/6933/ patch. On the positive side, all BTS/PHY models should now have the same behavior in terms of RACH detection threshold.

#10 Updated by laforge 6 months ago

  • Status changed from New to Resolved
  • % Done changed from 80 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)