The sequence is as follows:
0) start osmo-bts
1) start connection attempts to BTS
2) issue L1-RESET.req
3) receive L1-RESET.conf
4) issue RF-ACTIVATE.req
5) receive RF-ACTIVATE.conf
6) receive attributes for TRX
7) receive opstart for TRX
8) issue MPH-INIT.req
[...]
The important point here is: We don't want the BSC to set TRX attributes or do
TRX opstart before our RF related hardware is initialized.
In SDCCH4, we use lchan number 0...3 for the SDCCH/SACCH, and
we statically use lchan[4] as the dummy for activating the CCCH
L1 SAPIs.
In order to make combined and non-combined CCCH orthogonal, we simply
also use lchan[4] in that case. On a 'pure' CCCH, therefore lchan
0..3 are unused and 4 is the actual CCCH.
This code re-works osmo-bts to add support for the upcoming sysmocom BTS.
It also tries to add some level of abstraction between the generic
part of a BTS (A-bis, RSL, OML, data structures, paging scheduling,
BCCH/AGCH scheduling, etc.) and the actual hardware-specific bits.
The hardware-specific bits are currently only implemented for the sysmocom
femtobts, but should be (re-)added for osmocom-bb, as well as a virtual
BTS for simulation purpose later.
The sysmocom bts specific parts require hardware-specific header files
which are (at least currently) not publicly distributed.
Harald Welte