Project

General

Profile

Actions

Bug #2990

closed

OsmoBTS doesn't seem to ever send a DELETE INDICATION

Added by laforge about 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
02/24/2018
Due date:
% Done:

100%

Spec Reference:

Description

As per TS 48.058, when there are too many IMMEDIATE ASSIGN for the BTS to handle, it shall send DELETE INDICATIONs back to the BSC. There's little point in trying to grow the queue indefinitely. Rather, we should detect if the rate of new IMM.ASS is larger than those that we can actually send over Um, and then start to issue DELETE INDICATIONs

Actions #1

Updated by laforge about 6 years ago

  • Status changed from New to In Progress
  • Assignee set to laforge
  • % Done changed from 0 to 50

Patch implementing DELETE IND is in https://gerrit.osmocom.org/6875 but we also need to reduce the extremely high queue length of 1000 entries.

Actions #2

Updated by laforge about 6 years ago

FYI: I'm observing a rate of about 13 IMM.ASS messages (mac blocks) per second on my combined SDCCH/4 cell with BS-AG_BLKS-RES=1. This means a queue with 1000 entires would take 76 seconds to drain. Many higher-layer timers in the BSC will long have released a given channel by that time.

One idea would be to use 200 entries, like paging (equalling 15 seconds in above case). This is still quite long, but much more reasonable. Probably make sense to aling with some of the assignment related timers in the BSC.

Actions #3

Updated by laforge almost 6 years ago

  • Assignee changed from laforge to pespin
Actions #4

Updated by pespin almost 6 years ago

Patch https://gerrit.osmocom.org/#/c/osmo-bts/+/9515/ enables sending DELETE IND for messages dropped in the BTS once already been queued. Also, as per https://gerrit.osmocom.org/#/c/osmo-bts/+/9514/ we also drop messages different than imm ass reject, so now all dropped messages should send a DELETE IND. Unit test agch_test shows indeed a bigger number of rejected messages and as a result the queue takes less time to drain.

Also hard limit of 1000 was dropped to 100 in https://gerrit.osmocom.org/#/c/osmo-bts/+/9513/

Number is selected according to agch_test output table, 100 being slightly bigger than any biggest value found there:

Testing AGCH queue length computation.
T               BCCH slots
        1(NC)   1(C)    2(NC)   3(NC)   4(NC)
3       20      9       20      20      20
4       28      11      28      28      28
5       40      13      40      40      40
6       59      19      59      59      59
7       79      25      79      79      79
8       21      9       21      21      21
9       28      12      28      28      28
10      40      13      40      40      40
11      60      20      60      60      60
12      80      26      80      80      80
14      22      10      22      22      22
16      30      13      30      30      30
20      42      14      42      42      42
25      63      21      63      63      63
32      83      28      83      83      83
50      28      14      28      28      28

I close this task as the required bits have been implemented.

Actions #5

Updated by pespin almost 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100
Actions #6

Updated by laforge almost 6 years ago

I extended the AGCH test cases in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9526 to make sure we verify
  • the number of IMM.ASS on Um
  • the number of RSL DELETE IND on Abis
    when sending IMM.ASS at different rates.

I would expect us to write such a patch whenever introducing a new feature or fixing an issue.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)