Project

General

Profile

Bug #4772

PDCH timeslots are always full-power on secondary TRX

Added by laforge about 2 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
10/01/2020
Due date:
% Done:

0%

Spec Reference:

Description

The problem is that a dynamic TS (probably also a normal/static PDCH) is transmitting in downlink on a TRX != 0 even if there are no TBF on it (and hence no information transmitted)

The question is "how do we make sure a PDCH only transmits in DL when there is actual, real RLC/MAC blocks being transmitted".

Vadim wrote:

If I remember correctly, osmo-bts-trx would not Tx anything on PDCH (idle state of TCH/F_TCH/H_PDCH) unless osmo-pcu is connected. As soon as you start osmo-pcu, it starts sending valid RLC/MAC blocks (PACKET_DOWNLINK_DUMMY_CONTROL_BLOCK in Wireshark) to osmo-bts-trx.
In my understanding, we must ensure constant Tx power on a PDCH slot if there is at least one MS/UE is listening to it, because it needs to decode every RLC/MAC block and check the USF assignments, paging, etc. And the problem is that on the BTS side it's impossible to know if there is any TBF activity in the PCU or not, because they're basically separate entities.

understood. So it's osmo-pcu which would need to take that decision: Do we have any TBF allocations on a given timeslot? If yes -> send valid RLC/MAC blocks. If no -> send nothing (or some type of idle request) so osmo-bts doesn't transmit on those timeslots (if on TRX != 0).

History

#1 Updated by laforge about 2 months ago

  • Description updated (diff)

#2 Updated by laforge about 2 months ago

Vadim Yanitskiy wrote:

Hi Harald,

understood. So it's osmo-pcu which would need to take that decision: Do we have any TBF allocations on a given timeslot? If yes -> send valid RLC/MAC blocks. If no -> send noting (or some type of idle request) so osmo-bts doesn't transmit on those timeslots (if on TRX != 0).

yes, this approach sounds good. On the [PCUIF] protocol level, I see two potential solutions:

  • Add a new NOPE.req message that would be sent in response to RTS.req in case if there is no TBF activity on a given PDCH slot. This would require us to either bump the PCUIF version [again], or add a new flag to INFO.ind indicating NOPE.req support to the PCU.
  • Abuse one of the fields in DATA.req, which is not used by the current osmo-bts-trx version. We do have DATA.ind specific fields (Uplink measurements) in DATA.req message, so one of them could indicate a frame that is not necessary to transmit.

#3 Updated by laforge about 2 months ago

laforge wrote:

Vadim Yanitskiy wrote:

yes, this approach sounds good. On the [PCUIF] protocol level, I see two potential solutions:

  • Add a new NOPE.req message that would be sent in response to RTS.req in case if there is no TBF activity on a given PDCH slot. This would require us to either bump the PCUIF version [again], or add a new flag to INFO.ind indicating NOPE.req support to the PCU.

I would go for adding the flag to INFO.ind. So the BTS indicates this flag to the PCU, and the PCU can then start sending those new requests in response to RTS.req (on TRX != 0). This is fully backwards compatible to both older BTS with newer PCU and vice-versa.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)