25 Jan
2014
25 Jan
'14
8:54 a.m.
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(a)tsou.cc> wrote:
On Sat, Jan 25, 2014 at 1:22 AM, Andreas Eversberg
<andreas(a)eversberg.eu> wrote:
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
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. 
25 Jan
25 Jan
9:08 a.m.
New subject: RF power problems with current master of osmo-trx
Alexander Chemeris wrote:
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
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.
9:26 a.m.
New subject: RF power problems with current master of osmo-trx
Hi Andreas,
On Sat, Jan 25, 2014 at 12:08 PM, Andreas Eversberg
<andreas(a)eversberg.eu> wrote:
Alexander Chemeris wrote:
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
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. 
10:55 a.m.
New subject: RF power problems with current master of osmo-trx
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(a)schmid.xxx
http://www.bclog.de/
4165
days inactive
4165
days old
3 comments
3 participants
participants (3)
-
Alexander Chemeris -
Andreas Eversberg -
Ralph A. Schmid, dk5ras