Re: RF power problems with current master of osmo-trx
Hi Thomas, I'm moving this discussion to the OpenBSC mailing list, as it has nothing to do with UmTRX, but rather with OsmoTRX. On Sat, Jan 25, 2014 at 11:36 AM, Tom Tsou <tom@tsou.cc> wrote:
On Sat, Jan 25, 2014 at 1:22 AM, Andreas Eversberg <andreas@eversberg.eu> wrote:
once a channel was activeated, there will be RF power on the specific TS, even when osmo-bts does not send bursts anymore. i guess that some filler table of osmo-trx causes it. i think it would be nice if osmo-trx would stop transmitting, when there are no more bursts comming from osmo-bts. (at least after a while.)
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. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
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. best regards, andreas
Hi Andreas, On Sat, Jan 25, 2014 at 12:08 PM, Andreas Eversberg <andreas@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
Hi,
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.
Definitely, this even can be a demand from regulation authority, depending on license conditions. This behavior may affect emergency call handling, and the least thing I want to see is interfering with 112/911! Besides, as a ham radio operator I simply consider it good practice taking a transmitter off-air when something dies. Even an unmodulated carrier can be accepted in this case, but not transmitting a BCCH without any meaning.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
Ralph, dk5ras :-) -- Ralph A. Schmid Mondstr. 10 90762 Fürth +49-171-3631223 ralph@schmid.xxx http://www.bclog.de/
participants (3)
-
Alexander Chemeris -
Andreas Eversberg -
Ralph A. Schmid, dk5ras