Bug #1575
Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)
60%
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.
Related issues
History
#1 Updated by laforge over 1 year ago
- Assignee set to msuraev
#2 Updated by msuraev over 1 year 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 1 year 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 1 year 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 1 year ago
- Status changed from In Progress to Stalled
#6 Updated by msuraev over 1 year 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 over 1 year 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 11 months ago
- Related to Feature #2366: OsmoBTS lacks EXTENDED BCCH support added
#11 Updated by msuraev 10 months 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
#13 Updated by laforge 8 months 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 8 months 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?".
#16 Updated by laforge 8 months ago
- Related to Feature #1611: be more efficient in batching IMMEDIATE ASSIGN REJECT messages added
#17 Updated by laforge 7 months 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.
