This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comHi Andreas, On Sat, Jan 25, 2014 at 12:08 PM, Andreas Eversberg <andreas at eversberg.eu> wrote: > Alexander Chemeris wrote: >>> >>> Yes, this is the behaviour of the filler table, which will resend the >>> >previous frame until a new frame arrives. Sending an idle frame will >>> >disable output, which is how the filler table is managed in OpenBTS. >>> >You can disable the filler table with this patch. >> >> Could you make this configurable from the command line or from the >> socket control interface? >> >> I believe we should leave filler table as the default option, but >> allow one to disable it when OsmoTRX is used with OsmoBTS. > > hi alexander, > > i think that it does not make sense to add a special option for osmo-bts. > better would be to make osmo-bts behave correctly, i.e. similar to OpenBTS. > currently osmobts-trx does not send a burst (TRX > 0), if the channel to > which it belongs is deactivated. > > the question to thomas was: how do i send an idle frame, so the filler table > gets cleared. I can't comment on what is an idle burst, but I want to clarify that I think that the filler table should be turned off. We had this discussion at the 30c3 and the conclusion was that the filler table should be turned off. 1. IIRC from the talk David Burgess did at OsmoDevCon two years ago, the filler table was introduced in OpenBTS as an optimization to reduce load. But nowadays I don't see that running OsmoBTS generates much load. 2. In a normal cell most channels are encrypted, which means that repeating bursts makes no sense for those channels. 3. Repeating bursts on non-encrypted channels can lead to messed L2 connection setup and to dropped calls. It's better to completely miss a burst which will be re-transmitted again after some time, than have a burst transmitted twice. Missing a burst is a normal situation in an air interface and happens all the time. 4. The only channels which benefit from the filler table are BCCH and FCCH. But then we have another issue. If a BTS dies, BCCH and FCCH continues to be transmitted and phones think that the cell is still here. But it reality it's dead. This is quite not handy both for development and for production. Note, that the BTS may die for a variety of reasons and not only because there is some bug in it, and RF transmission must stop at this point. Given these considerations, I believe that we should make the filler table configurable. It is required for OpenBTS and is a nice thing for some lab tests, but for OsmoBTS it's a harmful thing. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru