On Sat, Jan 25, 2014 at 2:57 AM, Andreas Eversberg andreas@eversberg.eu wrote:
so when i stop sending the bursts, the filler table will continue to transmit bursts. do i understand it correctly: if i send a single idle burst (frame??) after sending bursts, the filler table is disabled until new bursts are sent?
Sorry, I misspoke about disabling transmission. The filler table resends the last burst in the multiframe, so the idle burst is usually just a dummy burst, which does not actually stop physical transmission. To fully turn off the downlink signal on a particular slot requires disabling the slot by the channel combination.
That said, I agree with Alexander that the retransmission portion of the filler table should be turned off because the behavior is incorrect. With a few exceptions (e.g. FCCH), bursts should *not* be retransmitted at L1 and doing so generates an invalid signal.
Note that the filler table cannot be completely disabled because it is part of the real-time loop that drives the device I/O. If the upper layer does not send a burst for a particular slot, or that burst arrives late (stale burst), something still must be transmitted. Currently, in that case, the burst comes from the filler table if the slot is active or zeros if the slot is turned off. Again, I do not think the current implementation is entirely correct, but that depends on expectations of the upper layers.
-TT
Tom Tsou wrote:
That said, I agree with Alexander that the retransmission portion of the filler table should be turned off because the behavior is incorrect.
hi thomas,
this makes sense. repeating any LAPDm frame is definitely something that might cause problems (SDCCH/FACCH/SACCH). even repeating (interleaved) TCH bursts in a multiframe does not make much sense in my opinion.
i have just tried your patch. i still get RF power on second TRX. osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send any burst data (TRX 1) to osmo-trx.
best regards,
andreas
On Sun, Jan 26, 2014 at 9:32 AM, Andreas Eversberg andreas@eversberg.eu wrote:
i have just tried your patch. i still get RF power on second TRX. osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send any burst data (TRX 1) to osmo-trx.
Yes, that is expected behavior. There will be power output as long as the slot is enabled. Right now the only way to turn off transmission is to disable the slot.
-TT
Hi Thomas,
On Sun, Jan 26, 2014 at 8:35 PM, Tom Tsou tom@tsou.cc wrote:
On Sun, Jan 26, 2014 at 9:32 AM, Andreas Eversberg andreas@eversberg.eu wrote:
i have just tried your patch. i still get RF power on second TRX. osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send any burst data (TRX 1) to osmo-trx.
Yes, that is expected behavior. There will be power output as long as the slot is enabled. Right now the only way to turn off transmission is to disable the slot.
This is an incorrect behavior for TRX1, unlike TRX0.
For TRX1 there are no idle bursts and there should be no transmission if there is no data sent. I can't check this right now, but I'm pretty sure that at least some time ago osmo-trx respected this behavior and didn't transmit on TRX1 until it gets something to transmit.
I would appreciate if you confirm that the current code still respects this and if you make filler table optional for TRX0 as well.
On Sun, Jan 26, 2014 at 4:12 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
For TRX1 there are no idle bursts and there should be no transmission if there is no data sent. I can't check this right now, but I'm pretty sure that at least some time ago osmo-trx respected this behavior and didn't transmit on TRX1 until it gets something to transmit.
Burst selection at a particular time works in the following order of priority.
1. Slot is disabled with channel combination set to NONE (default) 1. Burst exists in priority queue for the current time. 2. Filler table entry is used
This ordering has never changed.
What you are probably thinking of is the multi-ARFCN branch and derived code, which explicitly separated the beacon carrying channel. In that codebase, retransmissions were limited to the C0 TRX and the filler table on non-C0 channels was loaded with zeros. Osmo-TRX does not make this distinction and treats both channels are possible C0 beacons.
I agree that Independent channel configuration of the filler table is the correct approach.
-TT
On Mon, Jan 27, 2014 at 5:52 AM, Tom Tsou tom@tsou.cc wrote:
What you are probably thinking of is the multi-ARFCN branch and derived code, which explicitly separated the beacon carrying channel. In that codebase, retransmissions were limited to the C0 TRX and the filler table on non-C0 channels was loaded with zeros. Osmo-TRX does not make this distinction and treats both channels are possible C0 beacons.
Yes, I was speaking about the multi-ARFCN branch, as that's what we tested most deeply and which we used in production.
I agree that Independent channel configuration of the filler table is the correct approach.
You mean that it'll be configurable at runtime on per-TRX basis? That'll be a nice way.
On Sun, Jan 26, 2014 at 11:35 AM, Tom Tsou tom@tsou.cc wrote:
On Sun, Jan 26, 2014 at 9:32 AM, Andreas Eversberg andreas@eversberg.eu wrote:
i have just tried your patch. i still get RF power on second TRX. osmobts-trx configures all 8 channels (SETSLOT to TCH/F), but does not send any burst data (TRX 1) to osmo-trx.
Yes, that is expected behavior. There will be power output as long as the slot is enabled. Right now the only way to turn off transmission is to disable the slot.
Hi Andreas,
Please try the filler branch, which zero fills and disables filler table retransmissions by default. You can re-enable the OpenBTS type behavior for C0 on the command line.
git://git.osmocom.org/osmo-trx filler
-TT
Tom Tsou wrote:
Please try the filler branch, which zero fills and disables filler table retransmissions by default. You can re-enable the OpenBTS type behavior for C0 on the command line.
just tested it. it works, i get no RF power when not sending a burst. actually i get some RF power that is 40dB lower than the power of actual bursts, but this is caused by using ARFCNs that are close. (869 and 872)
On Thu, Jan 30, 2014 at 2:42 AM, Andreas Eversberg andreas@eversberg.eu wrote:
Please try the filler branch, which zero fills and disables filler table retransmissions by default. You can re-enable the OpenBTS type behavior for C0 on the command line.
just tested it. it works, i get no RF power when not sending a burst. actually i get some RF power that is 40dB lower than the power of actual bursts, but this is caused by using ARFCNs that are close. (869 and 872)
Great. It's just zero's during the non-burst periods so anything else that still shows up is probably RF related.
-TT
Tom Tsou wrote:
Yes, that is expected behavior. There will be power output as long as the slot is enabled. Right now the only way to turn off transmission is to disable the slot. -TT
hi thomas,
in case of TRX 0, osmo-bts always sends bursts, even on idle bursts. it sends dummy bursts in this case. i suggest that there is no RF power in case of TRX>0 for each single burst, that is not sent from osmo-bts. the reasons are:
- one TCH/H channel of one TS may be in use, so the other channel should be disabled, to reduce noise on the spectrum. - DRX (in the future) might be used to reduce noise on the spectrum. - SACCH is disabled when leaving dedicated mode, so the MS runs into radio link timeout, if the release message does not go through or some error occurs.
i think about three solutions to make make osmo-trx send no RF power per burst:
1. omso-bts does not send any burst to osmo-trx 2. sends a dummy burst with lowest possible power indication (pwr=255) 3. sends a burst with zero length data (only the 6 bytes header)
i prefer the first solution.
best regards,
andreas
On Thu, Jan 30, 2014 at 2:31 AM, Andreas Eversberg andreas@eversberg.eu wrote:
in case of TRX 0, osmo-bts always sends bursts, even on idle bursts. it sends dummy bursts in this case. i suggest that there is no RF power in case of TRX>0 for each single burst, that is not sent from osmo-bts. the reasons are:
- one TCH/H channel of one TS may be in use, so the other channel should be
disabled, to reduce noise on the spectrum.
- DRX (in the future) might be used to reduce noise on the spectrum.
- SACCH is disabled when leaving dedicated mode, so the MS runs into radio
link timeout, if the release message does not go through or some error occurs.
i think about three solutions to make make osmo-trx send no RF power per burst:
- omso-bts does not send any burst to osmo-trx
Please try out the filler branch I posted earlier. It does exactly that.
-TT
-
Alexander Chemeris -
Andreas Eversberg -
Tom Tsou