Regarding the removal of burst_mask2str() from the TCH/H handler,
it does not make sense to print it because the mask is already
shifted and an earlier logging should already contain this info.
Change-Id: I42d20e2da73c21ca366dd246244cd716c8ccb459
Related: OS#4823
In a typical setup operating on the real radio interface, it's
the duty of the transceiver (e.g. osmo-trx) to send NOPE.ind to
the L1 implementation (e.g. osmo-bts-trx). However, in a
virtual environment for ttcn3-bts-test we use a fake transceiver,
which due to its simplicity cannot send NOPE indications itself.
The lack of queues and buffering does not allow us to implement
NOPE indications in fake_trx.py, so the easiest approach is to
generate them from trxcon. Send TRXD PDUs without the burst bits,
and fake_trx.py will tranform them info NOPE.ind for us.
Change-Id: I1c7f1315b8ef44f651efd6a22fb5b854f65c0946
Related: SYS#5313, OS#1569
Similar to what we do in osmo-bts-trx, group everything related to
an Uplink burst into a structure. Pass a pointer to this structure
to the logical channel handlers. This makes the code easier to read,
and facilitates sending NOPE indications to the transceiver
(will be introduced in the upcoming patch).
Get rid of sched_trx_handle_tx_burst(), and instead just call
sched_trx_a5_burst_enc() directly from sched_frame_clck_cb().
Change-Id: Id45b27180c233fdc42ae1ef0b195554dd299a056
Related: SYS#5313, OS#1569
It's not clear why do we get frames with unexpected length, but
we definitely should not crash. Just log and ignore them.
Change-Id: I85392becbffdb3ba7365decfd8f3769abe3c02c7
Related: OS#5171
158 is basically: 8 + 148 + 2, where the last two are padding bytes
sent by legacy TRXDv0 transceivers. We don't need them, so do not
drop PDUs without these leggacy padding bytes.
Change-Id: I6c0734bc4669ccde2a93940c9cf50fdbbd67cb00
This is what trxcon sends to the network before the first SACCH
block is received from the higher layers. The indicated values
are of course invalid because they're hard-coded.
According to 3GPP TS 44.018, table 10.5.2.20.1:
0 The measurement results are valid
1 The measurement results are not valid
Change-Id: I7da767e146aec7cef1de71e4d735d6a02b6c5642
Related: SYS#4918
Table 10.5.2.20.0 "Measurement Results Contents" in 3GPP TS 44.018
is clear on what should be used as padding - '0**', i.e. zeroes.
Change-Id: I4db6845c98aded10291134f416da98fd0f4f58e3
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ied0f47378a5d348b857424adb5c874c1c093b485
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I6d80f3f2742d397e47f4f2970c951f2cf6d58172
Fixes: OS#4865
The signal handler was coded as if it was handling SIGABRT, but the
signal handler was not overwritten so it is actually used.
Change-Id: I5c597f3410fc97be138db6f3976df59f393819b6
Let's give a more human-readable decode of the TPU instructions,
naming the TSPACT pin names as well as the device_id/strobe.
Change-Id: Iac1ac74ac3e41cff9d3d347a167b43af58cc6e59
I was quite confused why I constantly see a bit error rate reported
by gsm48_rr, while at the same time the actual L1CTL_DATA_IND did
all state num_biterr == 0.
So the log statement was broken ...
Change-Id: I09bb6c606a8437b213bb444949c78a7c8a10542c
Both REQ and CNF share the same message structure, so we can
cheat a bit by changing the message type and sending it back.
Change-Id: I6f403ed0506b4b1872361d9976d3186bfe514b52
Related: OS#4799
Some commands, such as SETTA or SETPOWER, are expected to be sent
when the transceiver is powered on. We should not drop Uplink
bursts while waiting TRXC response.
For now it's easier to comment out the state check completely,
because the existing TRXC state machine is quite messy.
Change-Id: Iefe6030200b11b29a5790d1f4aa4070ed1d9a493
This way the layer1 can activate proper CBCH task and send us
CBCH block with proper RSL channel number, so they do not end
up being routed to LAPDm and rejected there.
Change-Id: Ib1d5c99587202a9d94aeb7b63de7ae8c4fb15af0
We cannot blindly assume that CBCH is present on TS0/SDCCH4 before
decoding CBCH Channel Description in System Information Type 4.
Change-Id: Ie8ce572df292d0b03c0f743bcf26184619176321
For more information, see 3GPP TS 44.014, sections:
- 5.1 "Single-slot TCH loops", and
- 8 "Message definitions and contents".
This feature has nothing to do with the Mobility Management, so
let's handle GSM48_PDISC_TEST messages in the Radio Resources
layer implementation (gsm48_mm.c -> gsm48_rr.c).
Change-Id: If8efc57c7017aa8ea47b37c472d1bbb1914389ca
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
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
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
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
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
Vadim Yanitskiy
Pau Espin
Harald Welte
Oliver Smith
Neels Hofmeyr