This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgThis is picking up on a discussion that fixeria and I have had in
https://gerrit.osmocom.org/#/c/6846 so far.
The goal is to be able to fully test the timing advance and power control loops
in unmodified osmo-bts-trx (from the BTS_Tests.ttcn test suite).
For this, we need:
* fake_trx must be able to insert additional false "delay"
* fake_trx must be able to insert additional false "path loss"
Let's look at TOA/timing first:
1) Implementation of TA in fake_trx
* MS sets timing advance via L1CTL
* trxcon translates this into SETTA command to fake_trx
* fake_trx stores this curernt TA value (in bit periods)
* fake_trx initializes the per-burst TOA (in 1/256th symbol periods) to the
negative of those values when converting from Tx to Rx burst format,
before feeding to osmo-bts-trx
2) implementation of "fake delay" in fake_trx
* test case at any time requests fake_trx to apply a "fake delay" (in 1/256th symbol periods)
* fake_trx stores this signed 16bit value
* fake_trx applies this fake_delay value when converting uplink Tx bursts to Rx bursts,
after having applied the timing advance.
So a typical exchange between MS and BTS looks like this:
* testcase instructs fake_trx to apply fake_delay of 512 (2 bit periods)
* MS sends RACH burst with no timing advance at all
* fake_trx applies TA=0 and adds fake_delay value (512), resulting in
reported timing value of 512 in the bursts passed to osmo-bts-trx
* osmo-bts-trx detects '512' and forwards this as timing offset to the BSC
* BSC will allocate a channel, and instruct MS to use TA=2 on it
* MS sends SETTA=2 to fake_trx
* any bursts from MS in fake_trx are processed as follows:
** set toa=-256*2=-512 (TA value of 2)
** add fake_delay: toa=-512 (result of above) + 512 (fake delay) = 0
* osmo-bts-trx receives bursts with toa=0, i.e. timing advance loop is balanced
When the MS is moving further away, we can simulate this by:
* testcase sends fake_delay=1024 to fake_trx
* uplink bursts now are processed in fake_trx as:
** set toa=-256*2=-512 (TA value of 2)
** add fake_delay: toa=-512 (result of above) + 1024 (fake delay) = +512
* osmo-bts-trx receives bursts with toa=512, reports this to timing advance loop code
* TA loop code will result in SACCH downlink L1 header to contain TA=4 (not just 2
like before)
* MS will send "SETTA 4" to fake_trx
* uplink bursts now are processed in fake_trx as:
** set toa=-256*4=-1024 (TA value of 4)
** add fake_delay: toa=-1024 (result of above) + 1024 (fake delay) = 0
* loop is balanced again
For RSSI processing it's slightly more complicated:
* fake_trx would need to know the nominal transmit power of both MS and BTS.
This could be from config file, command line argument or some control commands.
For this example, let's assume MS nominal power is +30dBm and BTS +23 dBm
* fake_trx will have some "SET PATH LOSS" command by which the test case can tell
it about the path loss it shall apply (in uplink and/or downlink direction)
* fake_trx receives "SET PATH LOSS 110" for 110dB path loss
* uplink burst processing then looks like this
** fake_trx knows MS nominal power is +30 dBm
** fake_trx subtracts the attenuation value from the Tx Burst Data header (e.g. 10 dB)
** fake_trx computes +30 (nominal power) -10 (burst attenuation) - 110 (path loss) = -90 dBm
** fake_trx reports -87dBm RSSI in the uplink burst to osmo-bts-trx
* downlink burst processing then looks like this
** fake_trx knows of BTS transmit power level is 23dBm
** fake_trx reads attenuation from tx burst header (e.g. 0dB)
** fake_trx computes +23 (nominal power) -0 (burst attenuation) - 110 (path loss) = -87 dBm
** fake_trx reports Rx bursts with -87dBm RSSI to trxcon
I hope this makes sense. Comments welcome.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)