* parse AMR multirate config form 04.08 IE into easier format
* CMR, CMC and CMI on the L1 side are an _index_ into the current
mode array
* Fix conversion of AMR SID frames from RTP -> L1
We don't really know if the HR encoding is compatible with other
equipment, but it _should_ follow Chapter 5.2 of ETSI TS 101 318.
Please note that RFC5993 also specifies a way to encode GSM-HR into RTP,
we do not try to be compatible with that. The only difference seems to
be one additional TOC octet at the beginning of the payload field.
Using osmo-bts-sysmo and this code, it is now possible to do FR and AMR
based voice calls on TCH/F.
A lot of CPU is wasted in the conversion between the RTP formats and the
L1 specific formats for the codec frames. All data needs to be shifted
by four bits, and the order of bits needs to be reversed in every byte.
This only implements creating, binding, connecting and free'ing RTP
sockets, not yet anything regarding receiving or transmitting codec
frames on them.
You will need the rtp branch of libosmocore for libosmotrau
We didn't correctly format the RSLms message that went into LAPDm,
causing LAPDm to drop the message.
Also, disable the fake CIPH MODE COMPLETE generation hack for now
When seinding the fake CIPH MOD COMPL, we should wait a bit, as otherwise it
will reach the MSC _before_ we ever get the (still unencrypted) CLASSMARK
update from the MS.
This is not full encrpytion support, the bts-model part still
needs to detect the ENCR CMD when de-queueing from LAPDm and enable
the de-ciphering, detect the arrival of the first encrypted frame,
etc, enable en-ciphering, ...
when we activate the SCH in the DSP, we start a 5-second timer. If
we ever do not receive any MPH-TIME.ind primitives from L1 within
that time frame, we stop the process (and will be re-spawned)
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