Project

General

Profile

Bug #1575

Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)

Added by laforge over 2 years ago. Updated 4 months ago.

Status:
Stalled
Priority:
High
Assignee:
sysmocom
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

60%

Estimated time:
Spec Reference:

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

Related to OsmoBTS - Feature #2366: OsmoBTS lacks EXTENDED BCCH supportNew2017-07-15

Related to OsmoBSC - Feature #1611: be more efficient in batching IMMEDIATE ASSIGN REJECT messagesRejected2016-02-23

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.

#8 Updated by msuraev 12 months ago

Related gerrit 3067 has been sent for review.

#9 Updated by laforge 11 months ago

  • Related to Feature #2366: OsmoBTS lacks EXTENDED BCCH support added

#10 Updated by laforge 10 months ago

  • Status changed from Stalled to In Progress

patches in gerrit under review, not stalled.

#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

#12 Updated by msuraev 9 months 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 9 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 9 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?".

#15 Updated by dexter 9 months 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 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.

#18 Updated by msuraev 6 months ago

  • Status changed from In Progress to Stalled

#19 Updated by laforge 4 months ago

  • Assignee changed from msuraev to sysmocom

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)