Feature #1611
closed
be more efficient in batching IMMEDIATE ASSIGN REJECT messages
Added by laforge about 8 years ago.
Updated almost 6 years ago.
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 to Feature #2592: Use "waiting time" of IMMEDIATE ASSIGN REJECT added
- Related to Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH) added
- Related to Feature #2722: document RACH tuning parameters more thoroughly, give explanations added
- Project changed from OpenBSC to OsmoBSC
- Category deleted (
libbsc)
- Category set to A-bis RSL
- Assignee changed from 4368 to stsp
- Status changed from New to In Progress
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.
- Status changed from In Progress to Stalled
Setting status to 'stalled', until we learn more about how BTS models such as nanoBTS behave.
- Status changed from Stalled to Rejected
reject this, as osmo-bts is already solving the problem.
Also available in: Atom
PDF
