The BTS IP address can now be specified by the L1FWD_BTS_HOST env
variable.
Option parsing would not have been that easy to integrate without
touching the main program...
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.
the RACH burst detection in the physical layer is appranetly providing many
false positives, and we need to raise the bar a bit in order to not allocate
channels in a useless way...
* gather measurements from each PH-DATA.ind
* check every TDMA frame about meas period expiration
* compute averages after period expired
* put MS DL MEAS REP into RSL MEAS RES messages, include UL meas
bugs:
* L3 INFO content seems to have some offset
* is_sub is not set anywhere
* measurement periods might have up/downlink offset
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