In order to reflect the UL/DL delay caused by the premature burst
scheduling (a.k.a. 'fn-advance') in a virtual environment, the
Transceiver implementation now queues all to be transmitted bursts,
so they remain in the queue until the appropriate time of transmission.
The API user is supposed to call recv_data_msg() in order to obtain
a L12TRX message on the TRXD (data) inteface, so it gets queued by
this function. Then, to ensure the timeous transmission, the user
of this implementation needs to call clck_tick() on each TDMA
frame. Both functions are thread-safe (queue mutex).
In a multi-trx configuration, the use of queue additionally ensures
proper burst aggregation on multiple TRXD connections, so all L12TRX
messages are guaranteed to be sent in the right order, i.e. with
monolithically-increasing TDMA frame numbers.
Of course, this change increases the overall CPU usage, given that
each transceiver gets its own queue, and we need to serve them all
on every TDMA frame. According to my measurements, when running
test cases from ttcn3-bts-test, the average load is ~50% higher
than what it used to be. Still not significantly high, though.
Change-Id: Ie66ef9667dc8d156ad578ce324941a816c07c105
Related: OS#4658, OS#4546
Running with cProfile shows that there are quite a lot calls:
469896 0.254 0.000 0.254 0.000 trx_list.py:37(__getitem__)
Let's better avoid using it in performance critical parts.
Change-Id: I2bbc0a2af8218af0b9a02d8e16d4216cf602892a
In general, premature scheduling of to be transmitted bursts
inevitably increases the time delay between Uplink and Downlink.
The more we advance TDMA frame number, the greater gets this
delay. 20 TDMA frames is definitely more than a regular
transceiver needs to pre-process a burst before transmission.
Change-Id: Ia9b142b59d95f2cd7b2394596cf72c0bcd36d711
Related: OS#4487
When running together with fake_trx.py (mostly used back-end), it
is currently possible that Downlink bursts are received in a wrong
order if more than one transceiver is configured (multi-trx mode).
This is how it looks like:
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0
DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0
DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
since the last processed fn=633 (current fn=632)
so here a burst with TDMA fn=633 was received earlier than a burst
with TDMA fn=632. The burst loss detection logic considered the
latter one as lost, and substituted it with a dummy burst. When
finally the out-of-order burst with TDMA fn=632 was received, we
got the large number of allegedly elapsed frames:
((632 + 2715648) - 633) % 2715648 == 2715647
Given that late bursts get substituted, the best thing we can do
is to reject them and log an error. Passing them to the logical
channel handler (again) might lead to undefined behaviour.
Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Related: OS#4658, OS#4546
It's not something that we should be trying to fix, if the whole
TDMA multi-frame is lost. For some yet unknown reason, sometimes
the difference between the last processed TDMA frame number and
the current one is so huge, so trxcon eats a lot of CPU trying
to compensate nearly the whole TDMA hyper-frame:
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
since the last processed fn=633 (current fn=632)
Let's just print a warning and do not compensate more than one
TDMA multi-frame period corresponding to the current layout.
Change-Id: I56251d0d2f6fa19195ff105d3bdfbc22df6db8cd
This change fixes several warnings reported by GCC 10.1.0:
apps/rssi/main.c:238:30: warning: 'sprintf' may write a terminating
nul past the end of the destination
apps/rssi/main.c:238:4: note: 'sprintf' output between 10 and 17
bytes into a destination of size 16
apps/rssi/main.c:413:26: warning: '.' directive writing 1 byte into
a region of size between 0 and 9
apps/rssi/main.c:413:3: note: 'sprintf' output between 10 and 20
bytes into a destination of size 16
Change-Id: I7980727b78f7622d792d82170f73c90ac5770397
These symbols are defined, but never used:
- struct last_rach - seems to be copy-pasted from prim_rach.c,
- tall_msgb_ctx - already defined in libosmocore.
Change-Id: I6077c8e9b441f7848d1a4c25a8b5e1aed82f4b7d
By default RSSI on the Rx side is computed based on transmitter's
tx power and then substracting the the Rx path loss.
If FAKE_RSSI is used, then the values in there are used instead.
A default hardcoded value of tx nominal power = 50 dBm is set to keep
old behavior of RSSI=-60dB after calculations.
Change-Id: I3ee1a32ca22c3272e66b3ca78e4f67d283844c80
L1CTL is using the network byte order, because this protocol is
spoken between different devices and architectures. Somehow I
forgot about this while adding SETFH command back in 2018.
Change-Id: Ia2f70f0d5e35b6bf05e1fa6fb51a15c1bbe3ca4c
Related: OS#4546
Jenkins build #2516 has uncovered a problem in DATADumpFile.parse_msg():
======================================================================
FAIL: test_parse_empty (test_data_dump.DATADump_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/build/src/target/trx_toolkit/test_data_dump.py",
line 138, in test_parse_empty
self.assertEqual(msg, False)
AssertionError: None != False
I did a quick investigation, and figured out that this failure
happens when trying to call parse_msg() with idx == 0, because
DATADumpFile._seek2msg() basically does nothing in this case
and thus always returns True. The None itself comes from
DATADumpFile._parse_msg().
Let's ensure that DATADumpFile.parse_msg() always returns None,
even if DATADumpFile._seek2msg() fails. Also, update the unit
test, so we always test a wide range of 'idx' values.
Change-Id: Ifcfa9c5208636a0f9309f5ba8e47d282dc6a03f4
It would make sense to send the ARFCN list in parameters of SETFH
command, if there was a clear distinction between transceivers in
fake_trx.py, i.e. which one is an MS and which is a BTS.
Right now, every Transceiver is an abstract entity that emits
and receives bursts. So when you convert an ARFCN to a pair of
Downlink/Uplink frequencies, you don't know whether it maps
as Rx/Tx or as Tx/Rx for a given Transceiver.
Of course, we could assume that this is an MS specific feature,
and a pair of Downlink/Uplink frequencies always corresponds to
Rx/Tx, but what if some day we would need to implement and test
a similar approach for the BTS side? Also, by sending frequency
values in kHz (rather than ARFCNs) we can avoid inconsistency
with the existing RXTUNE / TXTUNE commands.
Change-Id: Ia2bf08797f1a37b56cf47945694b901f92765b58
Related: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
Related: OS#4546
There are two ways to implement frequency hopping:
a) The Transceiver is configured with the hopping parameters, in
particular HSN, MAIO, and the list of ARFCNs (channels), so the
actual Rx/Tx frequencies are changed by the Transceiver itself
depending on the current TDMA frame number.
b) The L1 maintains several Transceivers (two or more), so each
instance is assigned one dedicated RF carrier frequency, and
hence the number of available hopping frequencies is equal to
the number of Transceivers. In this case, it's the task of
the L1 to commutate bursts between Transceivers (frequencies).
Variant a) is commonly known as "synthesizer frequency hopping"
whereas b) is known as "baseband frequency hopping".
For the MS side, a) is preferred, because a phone usually has only
one Transceiver (per RAT). On the other hand, b) is more suitable
for the BTS side, because it's relatively easy to implement and
there is no technical limitation on the amount of Transceivers.
FakeTRX obviously does support b) since multi-TRX feature has been
implemented, as well as a) by resolving UL/DL frequencies using a
preconfigured (by the L1) set of the hopping parameters. The later
can be enabled using the SETFH control command:
CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> [... <RXFN> <TXFN>]
where <RXFN> and <TXFN> is a pair of Rx/Tx frequencies (in kHz)
corresponding to one ARFCN the Mobile Allocation. Note that the
channel list is expected to be sorted in ascending order.
NOTE: in the current implementation, mode a) applies to the whole
Transceiver and all its timeslots, so using in for the BTS side
does not make any sense (imagine BCCH hopping together with DCCH).
Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
L1CTL handling code should not be involved in such high level checks, so
while at it, move the check into a separate function in gsm48_rr.c and
add a length check. gsm48_rr_tx_voice() is the only caller of
l1ctl_tx_traffic_req().
Related: SYS#4924
Change-Id: Iba84f5d60ff5b1a2db8fb6af5131e185965df7c9
Use newly added audio / loopback config vty node to provide audio
loopback from mobile app. Only FR is supported for now.
Change-Id: Icd0b8d00c855db1a6ff5e35e10c8ff67b7ad5c83
The aim is to add configurable audio loopback to mobile. An existing patch on a
branch from fixeria [1] adds the audio config section. Add a reduced version of
this audio config to be compatible with the future merge.
Add the audio loopback setting, so far without functionality.
Subsequent patch adds the actual loopback.
[1] osmocom-bb branch fixeria/audio,
patch "mobile/vty_interface.c: add new 'audio' section"
Change-id I62cd5ef22ca2290fcafe65c78537ddbcb39fb8c6
Change-Id: Ie03e4a6c6f81ea3925266dd22e87506d722a6e1a
Since we're heavily using trxcon in ttcn3-bts-test, the logging
output should contain as much information as possible. Ideally
we should introduce the VTY interface (see OS#3666) and get
logging configuration options as a bonus. But let's just use
some beneficial hard-coded defaults for now:
- print category and level (huh, we use NOTICE everywhere?),
- do not print category-hex (who needs it anyway?),
- print extended timestamp, so we're in synce with other logs.
P.S. This configuration is based on my own debugging experience.
Change-Id: Ie3d259f3255d8af80e6780f850b808fa243f97b4
This change implements basic (receive only) support of the PDCH
channels that are used in GPRS. Several coding schemes are
defined by 3GPP TS 45.003, however we can only do CS-1
for now, since it's basically an equivalent of xCCH.
In order to support the other schemes (CS2-4), we would need to
know how to configure the DSP (look at Freecalypso code?).
Change-Id: I44531bbe8743c188cc5d4a6ca2a63000e41d6189
GPRS (PDCH) and CBCH related frames have nothing to do with LAPDm.
The former uses LLC for the user-plane data, while CBCH involves
its own segmentation described in 3GPP TS 23.041 and TS 44.012.
There is currently no code for handling these kinds of frames, so
let's just send them to GSMTAP and release the memory (msgb).
Change-Id: I59b4acbe22217f8989f73b79b128a43e8bcdfa2f
Related: OS#4439
As was noted by Pau Espin Pedrol, there is a theoretical chance
that lchan->tdma.num_proc would overflow, so as a consequence,
subst_frame_loss() will be unable to compensate one
(potentionally lost) Downlink burst.
On practice, given the size of unsigned long and duration of a
single TDMA frame, it would only happen once in roughly ~6 years.
FRAME_DURATION = 4615 * 10e-6
ULONG_MAX = 2 ** 32 - 1
FRAME_DURATION * ULONG_MAX -> ~198212740 seconds
-> ~55059 hours
-> ~2294 days
-> ~6 years.
Chances are that trxcon would crash much earlier, or even GSM
would be completely forgotten after such a long time run, but
let's work this around and simply start counting from 1
if that overflow eventually happens.
Change-Id: I3d40ef09b06039a85df52af06ab38de314e1a434
It may happen that the burst reception would start from bid != 0:
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
so in that case, both measurement processing and the frame number
calculation would yield incorrect and/or incomplete results. The
Rx burst mask can be used to eliminate this problem.
In particular, if we shift it left instead of cleaning, it would
never be equal 0x00 after at least one burst is received. This
would allow us to skip decoding of an incomplete frame at the
beginning when the logical channel was just activated.
Note that TCH/H handler is not affected because it already uses
the strategy described above, so we keep it unchanged.
Change-Id: Ib8ddf2edd5ef84f2ab12155f7a8874c9fc56d436
Related: OS#3554
Vadim Yanitskiy
Pau Espin
Harald Welte
Oliver Smith
Neels Hofmeyr