Project

General

Profile

Bug #3709

Immediate Assignment Reject triggered by no answer to Immediate Assignment

Added by fixeria 19 days ago. Updated 18 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
A-bis RSL
Target version:
-
Start date:
11/27/2018
Due date:
% Done:

100%

Spec Reference:

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?

imm_ass_reject.pcapng.gz imm_ass_reject.pcapng.gz 903 Bytes fixeria, 11/26/2018 06:11 PM

History

#1 Updated by fixeria 19 days ago

  • % Done changed from 0 to 10

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

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

#2 Updated by neels 18 days 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?

#3 Updated by fixeria 18 days 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!

#4 Updated by fixeria 18 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 90

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

#5 Updated by neels 18 days 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.

#6 Updated by fixeria 18 days 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)