It has been tested with the OCXO and the network listen mode of the
firmware. For other sources we are not required to synchronize to
the network and the tool needs to be adjusted.
In v2 the calibration value is the clock error in ppb that needs
to be compensated. Create a V2 specific implementation. Write the
clock value unconditionally as it is initialized to 0 by default
and not 0xffff.
We now implement the fairly complex rules for schedulign of
SI 2bis/2ter/2quater, 13 and 9 on TC=4 and TC=5 of the BCCH Norm.
The patch is currently untested.
Once we get RF-ACTIVATE.conf from L1, we now enable the corresponding
LED. We also switch it off on RF-DEACTIVATE.conf. We do _not_ switch
it off when osmo-bts crashes or terminates before RF-DEACTIVATE.conf.
The latter is intentional, as RF may very well still be active at that
point. The re-spawning script will re-set the DSP and therby turn off
the RF and then disable the LED.
A better solution might be to do all this in the kernel driver for the
DSP.
an external application can create /var/lock/bts_rf_lock and then kill
the pid in /var/run/osmo-bts.pid in order to shut down the BTS. Any
re-spawning scripts will trigger, but osmo-bts will refuse to start up
until /var/lock/bts_rf_lock is removed again.
... and warn if the size is not what we expect.
This is required to work with sysmobts-v2 firmware >= v2.1, as the
SuperFemto_Prim_t is now larger than the GsmL1_Prim_t.
SI5/SI6 and other messages on SACCH need the C/R and the EA bit set in
the LAPDm header. Most devices accept a broken header, but especially
the Wavecom Q2686 responds with tons of RR STATUS messages if there is
any invalid bit.
This allows us to do RF measurements (EDGE EVM and the like) even
without having any PCU/RLC/MAC code as of now.
To use it, configure PDCH type timeslots (e.g. TS 7) in the BSC and then
use "trx 0 7 activate 0" to manually activate the PDTCH lchan on top
of that timeslot. The BTS will now happily transmit EDGE/8PSK data.
The ciphering parameters in L1 are persistent accross MPH
deactivate/activate, so we need to make sure to always initialize them
cleanly at RSL CHAN ACT time. This has the added benefit that we can
also activate channels that have encryption enabled from the very
beginning (required for encrypted handover).
where previously we would only see
<0006> oml.c:931 (bts=0,trx=0,ts=1,ss=0) MPH-DEACTIVATE.req (FACCH/F)
we now get
<0006> oml.c:931 (bts=0,trx=0,ts=1,ss=0) MPH-DEACTIVATE.req (FACCH/F RxUL)
to notice it is modifying the receive path in the uplink direction.
Send the RSL ACT ACK/NACK after the Layer1 firmware has acked the
activation/deactivation. In case the channel can not be activated
we will send a NACK. In case the channel can not be deactivated we
will send an ACK and the next time the channel is activated we will
send a NACK. The release ack will be sent once the TxDownlink of the
TCH/SDCCH is closed.
Change the rsl_tx_chan_nack method to create a new msgb to be used
by the hardware layer, change the return value to ask the caller to
delete the msgb.
Use the deact_sach (renamed to deact_sacch in master) to remember if the
SACCH has been disabled. This should fix the case of lchan errors due releasing
the lchan twice.
Do not msgb_free the msg as it will be re-used inside the nack
method and return 1 so the caller does not free the msgb. This
ownership model needs some consideration but the usage of ref
counts will not yield good results.
If the deactivation is failing the channel needs to be moved into
and error state, if the deactivation completed the channel needs to
be set to the none state and set the state to release reqeust on
the deactivation.
This will make app -V print the copyright information like the other
applications of our universe. An BTS integration that want to list
additionaly copyright holders needs to access the vty_app_info and create
a new copyright string.
We now check if the received message is an LAPDm I frame in order to
determine if we have received the first valid encrypted message on the
radio link. This relates to the fact that we often see 'old' UI frames
coming up from L1, even after it has confirmed decryption has been
enabled.
When the RR CIPH MODE CMD is transmitted to the MS, we need to tell the
L1 to enable decryption on RX. After the first received frame has been
decrypted successfully, we will enable encryption also on transmit.
This has been tested with A5/1 so far, but A5/2 and A5/3 should work
exactly identical.
In L1 RTP mode, the L1 already does all the bit-shifting and re-ordering
required for the RTP formats (which have different bit/nibble order than
the ETSI/3GPP encodings, for some odd reason).
We don't enable it by default yet, as only HR/FR/EFR work with it, but
AMR has some yet to be debugged problem.
Enabling USE_L1_RTP_MODE would save some CPU cycles on the ARM side.
The old firmware does not expose separate queues for PDCH and TCH. The change
appears to be too intrusive and I will try to find a more elegant solution.
Holger Hans Peter Freyther
Harald Welte