21 Jan
2014
21 Jan
'14
3:04 p.m.
Hi Jason,
On Tue, Jan 21, 2014 at 12:51:41PM +0000, Jason DSouza wrote:
I am not referring to your implementation, but to the general effects /
short-comings / implications of the GSM specification. As far as I
understand, you typically have lots of false positives as the CRC
_inside_ the RACH burst is so weak, that applying it to random noies
will still give you considerable number of hits.
But yes, if you actually operate with an antenna during R&D, then you
will likely see real RACH bursts of commercial phones.
The L1 just has to report RxLevel and C/I to osmo-bts, the rest is done
in osmo-bts.
This is a standard GSM radio parameter that will change behavior of the
MS. No support required in your PHY.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
which means
that you get lots of false positives from the PHY. Is
that the case?
I do not think they are false positives from the phy, neither I think
our CRC is weak. Those are mainly the rach from real commercial phones
around. In osmo-bts
code itself, you can set a threshold in terms of RxLevel
or C/I and drop all requests below a certain level or C/I
I need to check the support for those messages in our L1. In the system
information, you can play with paramters such as
Rx-Access-Level-Min.
The parameter rxlev access min <0-63> in the openbsc config takes care
of this? But again, this is measurement information I guess and need
to be supported by the phy.