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/gerrit-log@lists.osmocom.org/.
Harald Welte gerrit-no-reply at lists.osmocom.orgPatch Set 3: > Good idea. I would prefer to have the following: > > CMD FAKE_TOA <TOA_BASE> <TOA_TRESHOLD> > > where both values define a range of ToA randomization: > > min: TOA_BASE - TOA_TRESHOLD > max: TOA_BASE + TOA_TRESHOLD In tests, you normally don't want randomization, but you want reproducible results. So if you need randomization for some reason, feel free to do it. But in any case, it should be optional / disable-able. And the randomness/fuzziness should also be a "delta" regarding the ToA. In my tests, I want to be abl to change the simulated propagation delay e.g. while a channel is active. So I establish a SDCCH/TCH, and then use the FAKE_TIMING command to alter the propagation delay, simulating the MS to move away from the BTS. > Let's first focus on the Uplink path: > > When trxcon sends a burst, it doesn't care about ToA, it shouldn't. > There is a SETTA command, which forwards the current Timing Advance > value (indicated by the network) to transceiver, because exactly > transceiver takes care about the TX burst timings... fine. > The SETTA command is handled by GRGSM-TRX, but not by FakeTRX for > now. > I think, it makes sense to implement it in FakeTRX too. I'll do > this. Thanks, it's quite logical to have this in FakeTRX. The SETTA however doesn't need to do anythin other than be stored as a vaile on the BB side of fake_trx. So let's say you're doing SETTA=2 (symbols), then for a burst in uplink direction, the following should happen: * fake_trx receives Tx burst from trxcon * fake_trx converts from Tx burst to Rx burst * fake_trx sets TOA value to -512 (-256 * SETTA-value) * fake_trx adds the timing offset from FAKE_TIMING/FAKE_TOA (e.g. 512), resulting in 0 So when the TA loop is balanced, the TA and FAKE_TOA values compensate each other and the TOA reported in the UL Rx burst header in osmo-trx will state "0" As soon as the FAKE_TOA value is increased via TRXCTRL command from the testcase (e.g. trom 512 to 1024), fake_trx will compute -512+1024=512 and report the uplink bursts with +512, which is recognized by osmo-bts-trx which in turn will increment the TA value, which is sent by the SACCH downlink header into the MS, and the MS will instruct the PHY via L1CTL to apply that higher TA value, which is sent via the SETTA to fake_trx, which will from that point on compute -256*(TA=4)=-1024 + 1024 (FAKE_TOA) = 0 and the TA loop is balanced again. > Now let's look at the Downlink path: I don't think you need to do anything on the downlink side at all. TA is measured in uplink and applied in uplink transmission. Downlink only contains the L1 SACCH header with the TA value, but that's completely transparent/invisible to fake_trx and trxcon. > I think, the FAKE_* commands shall be implemented for both > Uplink and Downlink directions separately in FakeTRX, because > now we have them in CTRL_BB interface, but each one affects > both directions at the same time... I don't think this is needed. I currently don't know what I would use it for. See above, only the uplink part is needed, and the SETTA and FAKE_TOA only affect the uplink. > In other words, if you send e.g. FAKE_RSSI on CTRL_BB, then > the RSSI value would be changed for both directions... > This is incorrect. Well, *if* you want to simulate an unymmetric path loss, where UL-loss is diffrent from DL-loss, then yes it is "incorrect". For many practical use/test cases, I think it's sufficient to assume the path loss is equal, i.e. the same path loss of e.g. 110 dB applies in both directions. But yes, it makes sense to be able to set the path loss separately for uplink and downlink. But even in that case, you would want to set them from the saem test program/controller. It's not something that you would want to configure differently and independently from two sides simulteneously. -- To view, visit https://gerrit.osmocom.org/6846 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia23becec4104d47e7b22350db67b8834d6f1ad1b Gerrit-PatchSet: 3 Gerrit-Project: osmocom-bb Gerrit-Branch: fixeria/trx Gerrit-Owner: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com> Gerrit-HasComments: No