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.
The compiler can not know that the "int priv_nr" will hold the
enum values of the write queue, add a default branch and add a
warning and an assert there.
l1_transp_hw.c:108:1: warning: control reaches end of non-void function [-Wreturn-type]
Use 't' modifier for pointer diff in the printf statement.
oml.c: In function ‘oml_rx_set_bts_attr’:
oml.c:403:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 9 has type ‘int’ [-Wformat]
femtobts.c:249:2: warning: excess elements in array initializer [enabled by default]
femtobts.c:249:2: warning: (near initialization for ‘femtobts_clksrc_names’) [enabled by default]
If we don't do this on recent L1, the L1 will refuse the open after
re-starting osmo-bts.
There still is an issue in case osmo-bts crashes. We should have a
respawn loop that re-loads the DSP firmware before re-starting osmo-bts,
just to make sure...
Harald Welte
Holger Hans Peter Freyther