Project

General

Profile

Actions

Bug #4772

closed

PDCH timeslots are always full-power on secondary TRX

Added by laforge over 3 years ago. Updated over 2 years ago.

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

100%

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).

Actions #1

Updated by laforge over 3 years ago

  • Description updated (diff)
Actions #2

Updated by laforge over 3 years 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.
Actions #3

Updated by laforge over 3 years 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.

Actions #4

Updated by pespin over 2 years ago

  • Status changed from New to Feedback
  • Assignee changed from fixeria to pespin
  • % Done changed from 0 to 90

Patch was submitted, this should be fixed when merged (osmo-pcu.git Change-Id I8d66dd5e838748611e7b77b504fc86295f02c019)

Actions #5

Updated by pespin over 2 years ago

  • Assignee changed from pespin to fixeria
Actions #6

Updated by fixeria over 2 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from fixeria to pespin
  • % Done changed from 90 to 100

pespin AFAICS, all your patches have been merged. Closing this ticket.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)