Bug #3235
closeddyn TS: on PDCH release, osmo-bts common code fails to recognise PDCH is released, and a later TCH act is thwarted by that
100%
Description
In osmo-bts, the rsl_lchan_lookup() wants to verify the chan_nr IE value with the lchan->ts->pchan kind.
For example, for a chan_nr reflecting a TCH/H, we want to verify a TCH/H TS.
For dyn TS, which might be in switchover, we do allow a pchan NONE as well,
to allow PDCH --(PDCH-deact)--> NONE --(TCH-act)--> TCH.
However, it turns out that even though we ack a PDCH release (to the BSC even),
osmo-bts fails to record that PDCH has been deactivated, hence above pchan NONE never succeeds.
<0000> ../../../src/common/rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK <0000> ../../../src/common/rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12 <0000> ../../../src/common/rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan <0000> ../../../src/common/rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64
In above log, the Tx RF CHAN REL ACK shows that we're through with PDCH release,
but the following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows that the state still reflects active switching.
Thus the DCHAN code decides that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the TCH activation.
(I already have a patch for this, just tracking it properly)
Updated by neels about 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 90
Updated by neels about 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100