Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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)