Bug #3709
closedImmediate Assignment Reject triggered by no answer to Immediate Assignment
100%
Description
When the MS requests a dedicated connection (using RACH procedure), the BSC should allocate a channel
(if available), send RSL CHANnel ACTivetion ACK to the BTS, and Immediate Assignment to the MS. If
channel allocation failed, Immediate Assignment Reject is being sent to the MS.
For some reason, OsmoBSC additionally does send Immediate Assignment Reject when:
- a dedicated channel is requested and allocated,
- but no response to Immediate Assignment is received from the MS (e.g. ghost RACH).
DRSL abis_rsl.c:1357 (bts=0) CHAN RQD: reason: answer to paging (ra=0x23, neci=0x01, chreq_reason=0x01)
DCHAN lchan_fsm.c:78 lchan(0-0-0-CCCH_SDCCH4-0)[0x15660a0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout
DCHAN lchan_fsm.c:101 lchan(0-0-0-CCCH_SDCCH4-0)[0x15660a0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) Tx Immediate Assignment Reject (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout)
Please see attached capture.
I think there is no need to send Immediate Assignment Reject in such cases, since an
Immediate Assignment has already been sent. If nobody has responded to Immediate
Assignment (i.e. nobody sent anything on the allocated channel), who could be
interested in this Immediate Assignment Reject?
Files
Updated by fixeria over 5 years ago
- % Done changed from 0 to 10
The problem can be reproduced using this TTCN-3 test case:
Updated by neels over 5 years ago
- Status changed from New to Feedback
- Assignee set to fixeria
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?
Updated by fixeria over 5 years ago
- Status changed from Feedback to In Progress
- % Done changed from 10 to 80
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!
Updated by fixeria over 5 years ago
- Status changed from In Progress to Feedback
- % Done changed from 80 to 90
Both changes have been merged (even faster than I expected).
Updated by neels over 5 years ago
https://gerrit.osmocom.org/11942 addresses your logging suggestion.
For the general logging of the initial timeout, IMHO that should remain on LOGL_ERROR.
Updated by fixeria over 5 years ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
https://gerrit.osmocom.org/11942 addresses your logging suggestion.
Great, thanks! The issue itself is resolved now.
