Hello Harald, thanks for you quick answer, I'll take a look on that. Have a nice day, Antony
On Fri, Apr 6, 2018 at 10:59 AM, Harald Welte <lafo...@gnumonks.org> wrote: > Hi Antony, > > On Fri, Apr 06, 2018 at 10:36:06AM +0200, Antony Lemmens wrote: > > I have read articles about the superframe mechanism but I do not figure > out > > how to advertise the CBCH functionality on the BCCH, > > The Osmocom stack should take care of this "automatically" if > the osmo-bts-trx low-level code gets the required support. > > As you may have seen, CBCH operation is already supported with several > other > BTS back-ends inside osmo-bts. Unfortunately, for osmo-bts-trx nobody has > been contributing the related code so far. > > > nor how to adapt the scheduler to enable the CB channel. > > This boils down to the tables in osmo-bts/src/scheduler_mframe.c where > you can e.g. find "static const struct trx_sched_frame frame_bcch[51]" > which defines the 51-multiframe for the non-combined BCCH and "static > const struct trx_sched_frame frame_bcch_sdcch4[102]" for the combined > BCCH, as well as "static const struct trx_sched_frame frame_sdcch8" > > AFAIR, the BCCH can be on a combined BCCH or on a SDCCH/8. You would > have to create copies of "frame_bcch_sdcch4" and "frame_sdcch8" and edit > those copies to confirm with the way how the respective multiframe is > specified when CBCH is enabled. As far as I remember from memory, it's > always the second sub-channel that's replaced with CBCH instead of > SDCCH. See the related specs, I think mostly 3GPP TS 45.002 > > > Is it someone also interrested in this and/or working on the Bug 1617? > > I'm interested but seriously have no time to work on this. At sysmocm > we could work on it as a development project under contract, but we also > have quite a backlog so it might be best if somebody else works on this. > > > Or is it someone that can me give a track to start the implementation? > > My notes above should help with implementing it. > > -- > - Harald Welte <lafo...@gnumonks.org> > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) >