Cellular Network Infrastructure » Radio Access Network » OsmoBSC

The problem can be reproduced using this TTCN-3 test case:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11939/

fixeria wrote:

the BSC should allocate a channel
(if available), send RSL CHANnel ACTivetion ACK to the BTS

The BSC sends a CHAN ACT, and if it feels so inclined, the BTS might send the ACK to that.

For some reason, OsmoBSC additionally does send Immediate Assignment Reject

That's because the FSM goes into _lchan_on_activation_failure() for any failure.
Normally, the logical conclusion is to reject the assignment. But you're right:

I think there is no need to send Immediate Assignment Reject in such cases, since an
Immediate Assignment has already been sent.

The way to solve this would be:

https://gerrit.osmocom.org/#/c/osmo-bsc/+/11940

Can you try to reproduce with that patch in place?

Hi Neels,

The BSC sends a CHAN ACT, and if it feels so inclined, the BTS might send the ACK to that.

Ah, sure, thanks for clarification!

https://gerrit.osmocom.org/#/c/osmo-bsc/+/11940
Can you try to reproduce with that patch in place?

Great! It makes the test case pass, and I don't see IMM ASS Reject anymore :)

Let me have a closer look at your patch. One thing I would change is the debug
message that appears in case of such deactivation now:

DRSL abis_rsl.c:1357 (bts=0) CHAN RQD: reason: answer to paging (ra=0x23, neci=0x01, chreq_reason=0x01)
DMSC osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
DMSC a_reset.c:74 A-RESET(msc-0)[0x18989d0]{DISC}: SIGTRAN connection succeded.
DCHAN lchan_fsm.c:78 lchan(0-0-0-CCCH_SDCCH4-0)[0x18a50f0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout
DCHAN lchan_fsm.c:103 lchan(0-0-0-CCCH_SDCCH4-0)[0x18a50f0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan activation failed, after Immediate Assignment message was sent (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout)

• "lchan allocation failed in state ..." - this sounds / looks a bit confusing, because a channel
  was already successfully activated (this is ACKnowledged by the BTS).

• Both messages are using LOGL_ERROR. This is not error actually, so I would rather use LOGL_NOTICE.

Thanks for your quick feedback, Neels!

Both changes have been merged (even faster than I expected).

https://gerrit.osmocom.org/11942 addresses your logging suggestion.
For the general logging of the initial timeout, IMHO that should remain on LOGL_ERROR.

https://gerrit.osmocom.org/11942 addresses your logging suggestion.

Great, thanks! The issue itself is resolved now.