Project

General

Profile

Feature #1611

be more efficient in batching IMMEDIATE ASSIGN REJECT messages

Added by laforge almost 3 years ago. Updated 7 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
A-bis RSL
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

0%

Spec Reference:

Description

The RR Immediate Assignment Reject message can handle up to fourr identities that are rejected in a single message.

We currently use one message per identiry, wasting downlink AGCH capacity.

I think this feature is relevant particularly in cases where many
REJECTs are expected, i.e. where many phones are around that are not
permitted to join. Think of a private/small GSM networrk in an area
where there is no (good) public network coverage, but where lots of
regular subscribers of the other operators pass by. Or in situations
where the public network fails, forcing all the phones to try to
register on the private/small network running OpenBSC.

The problem is actually amplified, as
  • we waste one entire 23 byte MAC block for rejecting only a single subscriber
  • We don't scale the AGCH up by means of BS_AG_BLKS_RES
    Both of the features above would enable rejecting more phones (with
    permanent reject cause) ensuring they don't overload RACH+AGCH on the
    cell.

Related issues

Related to OsmoBSC - Feature #2592: Use "waiting time" of IMMEDIATE ASSIGN REJECTResolved2017-10-23

Related to OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)Stalled2016-02-23

Related to OsmoBSC - Feature #2722: document RACH tuning parameters more thoroughly, give explanationsNew2017-12-08

History

#1 Updated by laforge over 1 year ago

#2 Updated by laforge about 1 year ago

  • Assignee set to sysmocom

#3 Updated by laforge about 1 year ago

  • Related to Feature #2592: Use "waiting time" of IMMEDIATE ASSIGN REJECT added

#4 Updated by laforge about 1 year ago

  • Related to Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH) added

#5 Updated by laforge about 1 year ago

#6 Updated by laforge about 1 year ago

  • Related to Feature #2722: document RACH tuning parameters more thoroughly, give explanations added

#7 Updated by laforge about 1 year ago

  • Project changed from OpenBSC to OsmoBSC
  • Category deleted (libbsc)

#8 Updated by laforge about 1 year ago

  • Category set to A-bis RSL

#9 Updated by laforge 11 months ago

  • Assignee changed from sysmocom to stsp

#10 Updated by stsp 11 months ago

  • Status changed from New to In Progress

#11 Updated by stsp 11 months ago

Assignment reject messages can be aggregated in either the BSC or the BTS.

It turns out that osmo-bts already has support for this: http://git.osmocom.org/osmo-bts/commit/?id=4fcda92d7be7dd2df1870156206fea30cd02d3cc

Would we need another implementation on the BSC-side? That would be a bit less straightforward then the BTS implementation, since the BSC would have to employ a heuristic to decide whether to keep aggregating or send an assignment reject to a BTS right away, whereas the BTS can aggregate any assignment rejects it has already received when it is time to make a transmission.

#12 Updated by laforge 11 months ago

On Tue, Jan 30, 2018 at 05:51:03PM +0000, stsp [REDMINE] wrote:

It turns out that osmo-bts already has support for this: http://git.osmocom.org/osmo-bts/commit/?id=4fcda92d7be7dd2df1870156206fea30cd02d3cc

great.

Would we need another implementation on the BSC-side?

Not for now, at least not until we know for sure that other relevant BTS models like nanoBTS fail to do this
inside the BTS.

#13 Updated by stsp 10 months ago

  • Status changed from In Progress to Stalled

Setting status to 'stalled', until we learn more about how BTS models such as nanoBTS behave.

#14 Updated by laforge 7 months ago

  • Status changed from Stalled to Rejected

reject this, as osmo-bts is already solving the problem.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)