OsmocomBB

Initial attempt to extend L1CTL with CBCH was already done in 2013, please see:

http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003833.html

I think (ab)using L1CTL_DM_EST_REQ message is a bad idea. The L23 applications
should be able to receive CBCH messages without switching to a dedicated mode,
i.e. while being in IDLE mode.

I just implemented CBCH support for both Capypso and trxcon PHYs, please see:

https://gerrit.osmocom.org/11178/ trxcon/sched_lchan_desc.c: fix wrong chan_nr for PDCH
https://gerrit.osmocom.org/11179/ trxcon/l1ctl.c: properly handle indicated CCCH mode
https://gerrit.osmocom.org/11180/ firmware/layer1: inform about unhandled scheduler tasks
https://gerrit.osmocom.org/11181/ firmware/layer1: add scheduler tasks for CBCH
https://gerrit.osmocom.org/11182/ trxcon/scheduler: add CCCH/SDCCH mframe layouts with CBCH
https://gerrit.osmocom.org/11183/ l1ctl_proto.h: extend ccch_mode enum with CBCH

Please note that the L23 applications are unable to handle CBCH messages properly,
because we are using Osmocom specific cbits to "identify" them. But for TTCN-3
there should be no difference ;)

In short, sending L1CTL_FBSB_REQ or L1CTL_CCCH_MODE_REQ with CCCH_MODE_COMBINED_CBCH
would enable CBCH decoding tasks for both PHYs in idle mode (i.e. there is no need to
switch PHY to dedicated mode). This is actual for SDCCH/4+CBCH only!

In order to test CBCH on SDCCH/8, one would need to send regular L1CTL_DM_EST_REQ.
The problem is that decoded CBCH messages would arrive with cbits != 0xc8, because
the L1 code still needs to be modified in order to distinguish CBCH on SDCCH/8.

Ok, I've finally decided to split CBCH into two separate logical channels. This is required
because we need to distinguish between CBCH on SDCCH/4 (C0/TS0) and CBCH on SDCCH/8 (CX/TS0).

Also, activating CBCH on SDCCH/4 by default makes much more sense than on SDCCH/8, because
in the second case it can be a hopping channel (unlike SDCCH/4), so we would get garbage...

The problem is that decoded CBCH messages would arrive with cbits != 0xc8, because
the L1 code still needs to be modified in order to distinguish CBCH on SDCCH/8.

This should have been fixed in the latest patch set.

Merged. Please re-open if something wouldn't work.