Bug #1575
Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)
90%
Description
there are several assumptions that BS_AG_BLKS_RES==1 in the code. Fix them in order to support more AGCH slots
I think this feature may be important for larger deployments. Sooner or later you might want to have a different (but static) or a
dynamic balancing between AGCH and PCH load on the downlink CCCH. For a single-TRX cell it is probably unlikely that AGCH load will be very high, but the more TRX you ahve (and imagine extreme situations with 2TRX and many SDCCH/8) we might run into the limitation.
Checklist
- support in osmo-bts-litecell15
- support in osmo-bts-sysmo
- support in osmo-bts-trx
- support in osmo-bts-virtual
- support in osmo-bts-octphy
Related issues
Associated revisions
trx: avoid deactivating lchan on LCHAN_REL_ACT_REACT
- do not deactivate lchan when called with LCHAN_REL_ACT_REACT
- add fixme comment
It's unclear yet if any special steps are required for osmo-bts-trx so
let's just make it compatible with setups [1] using BS_AG_BLKS_RES != 1
for now.
Background: CCCH is auto activated by some OsmoBTS - before we receive
SI3, see 4a8582846281322e8d7dfc577b18767cf35c24d1. To accommodate for
that we deactivate CCCH in common/rsl.c, which triggers BTS-model
specific callback sapi_deactivate_cb() which updates parameters and
activates it again.
In case of osmo-bts-trx there is no auto-activation and (seems to be) no
need in special interaction with hw to activate channel (no
lchan_activate()) hence we can just skip entire
deactivate/setup/activate again routine.
[1] "channel-descrption bs-ag-blks-res N" in OpenBSC config file.
Related: OS#1575
Change-Id: I20b89ba1e43d1414180b083cd1e085eeffe5d513
osmo-bts-octphy: Remove bogus warning about BS_AG_BLKS_RES
Contrary to osmo-bts-sysmo, the OCTPHY-2G does not have different L1
SAPI for AGCH and PCH. It uses cOCTVC1_GSM_SAPI_ENUM_PCH_AGCH for both,
and we convert that to the cbits=0x12 (Downlink CCCH) on the L1SAP.
The code above L1SAP can hence freely decide if it wants to respond with
an AGCH or PCH message, based on its knowledge of BS_AG_BLKS_RES,
without the OCTPHY specific code having to do anything about it.
Hence, there's nothing to do, and the warning can be removed
Change-Id: Ic1038b8dc57bdaf05493cd8479355b960275ea41
Related: OS#1575
paging: add unit-test to check different bs_ag_blks_res settings
The parameter bs_ag_blks_res, which is loaded into the BTS via the SI3
setting, defines how many of the CCCH blocks shall be used for AGCH. The
remaining CCCH blocks will then be available as PCH for paging.
Unfortunately there is no unit-test yet that verifies that all of the 8
different settings for bs_ag_blks_res.
- Separate the the decision logic that checks if a given fn is part of
an AGCH into a function to have it available in the unit-test.
- Add a test that checks all possible bs_ag_blks_res settings.
Change-Id: Ib9652f4013a4da3766852f8f03ce9ec5590f6989
Related: OS#1575
History
#1 Updated by laforge over 4 years ago
- Assignee set to msuraev
#2 Updated by msuraev over 4 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Should I implement static or dynamic variant? What should happen if new value for "channel-descrption bs-ag-blks-res" is entered in OpenBSC vty?
#3 Updated by msuraev over 4 years ago
Static variant sent for review as gerrit #1047. Not strictly speaking required, but handy for debugging is extended logging from gerrit #1043.
#4 Updated by msuraev over 4 years ago
- % Done changed from 10 to 20
Preliminary variant sent for review in gerrit #1099. Missing bits:
- it's unclear how/if octphy support different number of AGCH (equivalent of lch_par->agch.u8NbrOfAgch)
- it's unclear if/how we have to activate/deactivate lchan for osmo-trx (equivalent of sapi_deactivate_cb())
Current implementation is somewhat ugly because we 1st unconditionally activate CCCH before knowing SI3 with proper number of AGCH. When we finally receive AGCH value from SI3 we deactivate channel and than activate it again. osmo-bts-trx seems to be different in this regard - maybe we do not have to use reactivation hack in there. Also, once this early auto-activation hack is removed we can streamline this code.
#5 Updated by msuraev over 4 years ago
- Status changed from In Progress to Stalled
#6 Updated by msuraev over 4 years ago
- % Done changed from 20 to 50
Support for lc15 and sysmo has been merged.
Octphy: waiting for vendor response.
Osmo-trx: waiting for vendor response.
#7 Updated by laforge almost 4 years ago
I guess you need to follow-up with Octphy and Osmo-TRX folks regularly to make sure this doesn't stay stalled forever.
#9 Updated by laforge over 3 years ago
- Related to Feature #2366: OsmoBTS lacks EXTENDED BCCH support added
#10 Updated by laforge over 3 years ago
- Status changed from Stalled to In Progress
patches in gerrit under review, not stalled.
#11 Updated by msuraev over 3 years ago
- Checklist item support in osmo-bts-litecell15 added
- Checklist item support in osmo-bts-octphy added
- Checklist item support in osmo-bts-sysmo added
- Checklist item support in osmo-bts-trx added
- Checklist item support in osmo-bts-virtual added
- % Done changed from 50 to 60
#12 Updated by msuraev over 3 years ago
- Status changed from In Progress to Stalled
The octphy support requires vendor cooperation.
The virtphy support is planned. Might make sense to add corresponding TTCN-3 test if time permits.
#13 Updated by laforge over 3 years ago
- Checklist item deleted (
support in osmo-bts-octphy) - Priority changed from Normal to High
please add it to -virtual and extend the TTCN-3 test to cover it.
I've dropped the OCTPHY topic. I presume you had inquired them regarding this at the time you were working on the code? If not, please make sure they are aware we're waiting for them to add support to the PHY.
#14 Updated by msuraev over 3 years ago
I presume you had inquired them regarding this at the time you were working on the code?
Yes, twice actually. Although it's been a while ago so I'm pretty sure they forgot about it by now. Dexter, can you please ping them again? The question is basically "how do we instruct octphy l1 that it should use X AGCH channels (as in 3GPP TS 45.002 ยง3.3.2.3 a)BS_AG_BLKS_RES)?" or "is that supported by some fw version already?".
#15 Updated by dexter over 3 years ago
I wrote Jason an email, maybe he can give us more information about this or even point us to the right places in the documentaion/header files.
#16 Updated by laforge over 3 years ago
- Related to Feature #1611: be more efficient in batching IMMEDIATE ASSIGN REJECT messages added
#17 Updated by laforge about 3 years ago
- Checklist item support in osmo-bts-octphy added
- Status changed from Stalled to In Progress
Regarding Octphy: The response was that there is no different L1 SAPI between AGCH and PCH, so we don't ned to inform/instruct the PHY about where higher layers put the split.
Instead, both AGCH and PCH are leading to PH-RTS.ind of type cOCTVC1_GSM_SAPI_ENUM_PCH_AGCH. AFAICT, in osmo-bts-octphy/l1_if.c:chan_nr_by_sapi() we map this to cbits=0x12 which is "Downlink CCCH (AGCH/PCH)". So it "should simply work".
I've pushed a change Ic1038b8dc57bdaf05493cd8479355b960275ea41 that simply removes the related warning, see https://gerrit.osmocom.org/5148
osmo-bts-virtual (and related test case) thus remains the only open tasks here. Please get that done.
#18 Updated by msuraev about 3 years ago
- Status changed from In Progress to Stalled
#19 Updated by laforge about 3 years ago
- Assignee changed from msuraev to sysmocom
#20 Updated by laforge over 2 years ago
- Assignee changed from sysmocom to dexter
#21 Updated by dexter over 2 years ago
I have figured out how the paging and access grant channels should be laid out. I hope my understanding is correct here:
===================================================== == TDMA frame mapping for FCCH + SCH + BCCH + CCCH == ===================================================== F = FCCH H = SCH B = BCCH C = CCCH D = SDCCH S = SACCH I = Idle A = AGCH P = PCH 1 2 3 4 5 012345678901234567890123456789012345678901234567890 v v v FHBBBBCCCCFHCCCCCCCCFHCCCCCCCCFHCCCCCCCCFHCCCCCCCCI 0000 11112222 33334444 55556666 77778888 (B0 ... B8) PPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 0 AAAA PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 1 AAAA AAAAPPPP PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 2 AAAA AAAAAAAA PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 3 AAAA AAAAAAAA AAAAPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 4 AAAA AAAAAAAA AAAAAAAA PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 5 AAAA AAAAAAAA AAAAAAAA AAAAPPPP PPPPPPPP BS_AG_BLKS_RES = 6 AAAA AAAAAAAA AAAAAAAA AAAAAAAA PPPPPPPP BS_AG_BLKS_RES = 7 ======================================================================================= == TDMA frame mapping for FCCH + SCH + BCCH + CCCH + SDCCH/4(0...3) + SACCH/4(0...3) == ======================================================================================= F = FCCH H = SCH B = BCCH C = CCCH D = SDCCH S = SACCH I = Idle A = AGCH P = PCH 1 2 3 4 5 6 7 8 9 0 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901 v v v v v v v FHBBBBCCCCFHCCCCCCCCFHDDDDDDDDFHDDDDDDDDFHDDDDDDDDIFHBBBBCCCCFHCCCCCCCCFHDDDDDDDDFHDDDDDDDDFHDDDDDDDDI 0000 11112222 0000 11112222 (B0 ... B2) PPPP PPPPPPPP PPPP PPPPPPPP BS_AG_BLKS_RES = 0 AAAA PPPPPPPP PPPP PPPPPPPP BS_AG_BLKS_RES = 1 AAAA AAAAPPPP PPPP PPPPPPPP BS_AG_BLKS_RES = 2 Example #1: FN: MOD102: BLOCK: 165 63 B1 216 12 B1 220 16 B2 267 63 B1 271 67 B2 318 12 B1 322 16 B2 369 63 B1 372 66 B2 420 12 B1 424 16 B2 ==> B0 is never used for paging ==> BS_AG_BLKS_RES = 1 Example #2: FN: MOD102: BLOCK: 573 63 B1 577 67 B2 624 12 B1 628 16 B2 675 63 B1 679 67 B2 726 12 B1 730 16 B2 777 63 B1 828 12 B1 832 16 B2 ==> B0 is never used for paging ==> BS_AG_BLKS_RES = 1
I did an experiment. I have set BS_AG_BLKS_RES = 2 via the osmo-bsc VTY and ran BTS_Tests.TC_paging_imsi_200percent. The result looks like BS_AG_BLKS_RES = 1, so there is indeed something wrong here.
#22 Updated by dexter over 2 years ago
At least for the osmo-bts-trx/faketrx/trxcon case I can say that it works now. The reason why it did not work last time is that the setting for bs_ag_blks_res is quite confusing. It is not set via OML, so setting it via osmo-bsc.cfg does not change anything. The parameter must be changed in BTS_tests.ttcn as well at two places (for the test and for the SI3). Once this is changed correctly osmo-bts receives the parameter correctly and behaves accordingly.
#23 Updated by dexter over 2 years ago
For the ttcn3 test I have simplified the things a bit: https://gerrit.osmocom.org/10707
#24 Updated by dexter over 2 years ago
- Status changed from Stalled to In Progress
- % Done changed from 60 to 80
I have added now a unit-test. We see the expected behavior for all possible bs_ag_blks_res settings, which is very good.
https://gerrit.osmocom.org/#/c/osmo-bts/+/10724 paging: add unit-test to check different bs_ag_blks_res settings
#25 Updated by dexter over 2 years ago
- Checklist item support in osmo-bts-virtual set to Done
- % Done changed from 80 to 100
I have also checked the support for osmo-bts-virtual with an experiment. I have set different values for bs_ag_blks_res, started osmo-bts-virtual and observed the frame number of the emitted GSMTAP frames. The frame numbers of the paging channel (dummy pagings) all fell into the correct range. I have tested with bs_ag_blks_res=1 and bs_ag_blks_res=2.
Since the decision when to send pagings to the phy is made in l1sap.c:l1sap_ph_rts_ind() it is common code we can be very sure that the behavior of osmo-bts-virtual will not be different from other BTS. So I think we can conclude that bs_ag_blks_res is correctly handled in osmo-bts-virtual.
To increase the test coverage a bit I have added a check to BTS_Tests.ttcn that checks if the pagings on L1CTL actually fall into the PCH and not in the AGCH or even BCCH. We currently only check with bs_ag_blks_res=1. See also:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10726 BTS_Tests: check paging channel fn (bs_ag_blks_res)
#26 Updated by dexter over 2 years ago
- % Done changed from 100 to 90
While osmo-bts-trx seems to work just fine inside the TTCN3 tests we still have problems. When I set
bts 1 channel-descrption bs-ag-blks-res 2
The phone does not register anymore. So I think we have another problem that is related to bs-ag-blks-res. Here is a sample from the log:
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802121/1359/09/36/33 Too many contiguous elapsed fn, dropping 297 Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802142/1359/04/06/02 Too many contiguous elapsed fn, dropping 49 Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802144/1359/06/08/04 Too many contiguous elapsed fn, dropping 420 Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802175/1359/11/39/35 Too many contiguous elapsed fn, dropping 31 Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802205/1359/15/18/13 Too many contiguous elapsed fn, dropping 596 Fri Aug 31 17:43:58 2018 <0000> rsl.c:2672 (bts=0,trx=0,ts=0,ss=4)(NONE) is not active . Dropping message. Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802207/1359/17/20/15 Too many contiguous elapsed fn, dropping 32 Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802225/1359/09/38/33 Too many contiguous elapsed fn, dropping 584 Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802285/1359/17/47/45 Too many contiguous elapsed fn, dropping 143 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802337/1359/17/48/45 Too many contiguous elapsed fn, dropping 130 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802339/1359/19/50/47 Too many contiguous elapsed fn, dropping 984 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802352/1359/06/12/08 Too many contiguous elapsed fn, dropping 231 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802426/1359/02/35/30 Too many contiguous elapsed fn, dropping 74 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802446/1359/22/04/50 Too many contiguous elapsed fn, dropping 447 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802460/1359/10/18/12 Too many contiguous elapsed fn, dropping 255 Fri Aug 31 17:43:59 2018 <0000> rsl.c:2672 (bts=0,trx=0,ts=0,ss=4)(NONE) is not active . Dropping message. Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802533/1359/05/40/37 Too many contiguous elapsed fn, dropping 87 Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802535/1359/07/42/39 Too many contiguous elapsed fn, dropping 109 Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802621/1359/15/26/21 Too many contiguous elapsed fn, dropping 747 Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802655/1359/23/09/03 Too many contiguous elapsed fn, dropping 195 Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802712/1359/02/15/08 Too many contiguous elapsed fn, dropping 57 Fri Aug 31 17:44:00 2018 <0000> rsl.c:2672 (bts=0,trx=0,ts=0,ss=4)(NONE) is not active . Dropping message. Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802744/1359/08/47/40 Too many contiguous elapsed fn, dropping 459 Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802748/1359/12/00/44 Too many contiguous elapsed fn, dropping 411 Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802787/1359/25/39/35 Too many contiguous elapsed fn, dropping 75 Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802828/1359/14/29/24 Too many contiguous elapsed fn, dropping 80 Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802902/1359/10/01/46 Too many contiguous elapsed fn, dropping 677 Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802938/1359/20/37/30 Too many contiguous elapsed fn, dropping 194
I run the following channel combinations:
timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2
bs-ag-blks-res = 2 should be a legal setting, even if I would only use CCCH+SDCCH4 with no SDCCH8. I have tested on a sysmobts as well, there it worked, but the image on that BTS is not very recent.
#27 Updated by dexter over 2 years ago
- Status changed from In Progress to Stalled
#28 Updated by laforge over 1 year ago
- Assignee deleted (
dexter) - Priority changed from High to Normal
Fix AGCH/PCH proportional allocation
Do not assume that 1 == BS_AG_BLKS_RES but take that information from
SI3. Note: due to current implementation quirks we activate channels
before SI3 obtained, than we deactivate channels upon receiving SI3 and
activate them again. This might not be necessary once we migrate to
proper OML state machines.
This affects lc15 and sysmo hw.
Change-Id: I11377b12680ac3b2f77f80e742b6f0af63fc9c1e
Related: OS#1575