The trx_data_rx_cb() needs to be modified because it's accessing and
modifying the receive buffer via the bi.burst pointer, which
becomes const after this patch.
Change-Id: I68773d247725a6dc2cbbc58b63c0fd19ffdb1a16
Related: OS#5599
The key idea is to allow triggering the scheduler only for a specific
timeslot of a frame, while keeping the API for triggering all together.
Split off the main part from l1sched_trigger() to l1sched_pull_burst().
While at it, rename l1sched_trigger() to l1sched_pull_send_frame().
Change-Id: Ibb7f9d7de26733f21b0753a2c655a250286bf1f0
Related: OS#5599
Use the given Fn instead, no need to go that deep for it. The
sched->fn_counter_proc is an internal field of the scheduler,
which is not necessarily holding a valid value when pulling
Uplink bursts synchronously via the Ready-to-Send PHYIF API.
Change-Id: I56027876b50e53b474c2f54ac216cd141142020e
Related: OS#5599
This app will allow setting up a tun device to transmit/receive data
as a GPRS MS against a GSM network.
This is just the initial skeleton so that people can work on it further
in follow-up commits.
Related: OS#5503
Change-Id: I8a1121b3287da7d7330c30e3118affa8fd1da61b
Do not mix up Downlink burst handling with the clock delivery. Add
a separate PHYIF API function and call it from the TRXC/TRXD PHYIF.
This way calling trxcon_phyif_handle_burst_ind() would not trigger
the internal timer-driven Uplink scheduler in libl1sched, letting
the underlaying PHYIF logic to pull Uplink bursts synchronously.
Change-Id: Ieeee25573d1142aec2fee28d884127f14573b681
Related: OS#5599
This is needed for the integration with osmo-trx-ms. It was decided
to run the scheduler within the transceiver process, so that we can
reduce scheduling latency. The idea is to maintain trxcon as a sub-
module in osmo-trx.git and link osmo-trx-ms against the libtrxcon.
We cannot use hard-coded logging categoris in a library, so add new
API for setting them: trxcon_set_log_cfg(). Use DLGLOBAL by default.
Change-Id: Idf207947f620a7394e0a0e5bf2c37bcd8df64bbe
Related: OS#5599
The L1CTL codec (implemented in l1ctl.c) is going to be part of the
upcoming libtrxcon, so let's uncouple it from the l1ctl_server API.
Change-Id: I8d80af240b0e57f76263907c552288d4184876c0
Related: OS#5599
The l1ctl_client_read_cb() is using L1CTL_HEADROOM, so let's avoid
inconsistency and use L1CTL_HEADROOM in the l1ctl_alloc_msg() too.
Change-Id: I248f8c662ae0836cba61fb708a5dc73c57131f4c
Related: OS#5599
Currently the trxcon_fsm is simply passing start and stop ARFCN values
(as received from the L1CTL peer) over the PHYIF, and expecting the
PHY to perform the measurements within the given range. This approach
requires the PHY implementation to maintain some state internally.
Let's simplify the job of the PHY implementation(s) by maintaining the
power scan state in the trxcon_fsm and sending a PHYIF_CMDT_MEASURE
command for each ARFCN in the given start/stop boundaries separately.
Change-Id: Ic5f724a11e225b439ec10aed7697e3e03b7929e5
Related: OS#5599
If $CFLAGS is empty prior to calling the LT_INIT, this macro will
set $CFLAGS to "-g -O2". We don't want implicit flags out of
nowhere, so let's simply move the invocation of LT_INIT down below.
Change-Id: I8d8eb1e3428ffcb84ddd53230fada39328337d15
Related: OS#5749
Found this problem while trying to build with "-flto":
../include/osmocom/bb/trxcon/l1ctl.h:21:5: error: type of
'l1ctl_tx_dt_conf' does not match original declaration
[-Werror=lto-type-mismatch]
21 | int l1ctl_tx_dt_conf(struct l1ctl_client *l1c,
| ^
l1ctl.c:288:5: note: type mismatch in parameter 2
288 | int l1ctl_tx_dt_conf(struct l1ctl_client *l1c, bool traffic,
| ^
The trxcon_fsm is passing only two arguments to l1ctl_tx_dt_conf().
The 'traffic' flag is included in struct trxcon_param_tx_data_cnf,
so the 2rd argument is not needed and should have been removed.
Change-Id: Ifc538f940571172fa237ecb7000f3cfea3655edc
Allow TRXCON_ST_{FULL_POWER_SCAN->FULL_POWER_SCAN} state transition
so that we can call osmo_fsm_inst_state_chg() unconditionally.
Change-Id: I1ea69561a2d3cf73009c6244b1d0f090d744d7b2
Related: OS#5599
The PHYIF implementation shall not have direct access to the struct
trxcon_inst it belongs to. All communication shall be done via the
abstract PHYIF interface (see <include/osmocom/bb/trxcon/phyif.h>).
* Introduce struct trx_if_params containing all necessary params.
* Make trx_if_open() accept a struct trx_if_params pointer.
Change-Id: I1a97c4c783ab671636ca33700eca97dede2a4a09
Related: OS#5599
The PHYIF implementation shall not send events to the trxcon_fsm
directly. The measurement command is sent in form of an abstract
PHYIF primitive (PHYIF_CMDT_MEASURE), so it's more logical that
the response is sent in form of a PHYIF primitive too.
Change-Id: Ie20616c288c16559d0a566979b24d57b50369fab
Related: OS#5599
We already handle DATA.req/TRAFFIC.req via TRXCON_EV_TX_DATA_REQ,
so let's handle the respective *.cnf messages via the FSM too.
Change-Id: Ica7a25f0bf8c7f89037a776d711ac641c57c9ad5
Related: OS#5599
It's not really necessary to handle signalling and traffic via
different events, so let's reduce complexity by merging them.
Change-Id: I8c2b3274f32d4d52424512d988b93d6233dd09a0
Related: OS#5599
The trxcon_fsm should not be dealing with the L1CTL protocol, so
let's better hand over the trxcon_param_rx_traffic_data_ind to
l1ctl_tx_dt_ind() and compose the l1ctl_info_dl there.
Change-Id: Ie57d86ffd9ea7c44187aafba0df1f519d1c523fb
Related: OS#5599
It does not make sense to call function sched_frame_clck_cb() via
a configurable pointer in the l1sched_state. Make this function
public (thus rename) and call it directly. Remove the .clock_cb.
Having l1sched_trigger() globally available makes it possible to
call this function directly, bypassing the internal timer driven
clock module. This is needed for the integration with osmo-trx-ms.
Change-Id: Ied0eed6d514acabb94d819b2f9485868390c0f24
Related: OS#5599
In commit [1] I introduced a regression by removing the conditional
part completely. My intention was to remove the logging statement,
the return should be kept to prevent sending POWERON twice.
This regression affects the following TTCN-3 testcases:
* TC_sacch_chan_act_ho_async,
* TC_sacch_chan_act_ho_sync.
Change-Id: Iccd0bbac91a7899ef72df3dfe623b56eb66305fa
Fixes: [1] 1c75c0012b
With the introduction of the abstract PHYIF, the trxcon_fsm has lost
access to the internal state of the PHY, so now it may be sending the
PHYIF_CMDT_POWERON even if the PHY is already powered on.
Change-Id: Ib500c746430c9082a5fda342257cee7293f46ba0
Related: OS#5599
This change is aimed to simplify the integration of trxcon with
osmo-trx-ms by allowing to replace the TRXC/TRXD interface with
direct API calls.
Change-Id: I3d7c717cfc3616809d22efb1903abbf843594258
Related: OS#5599
We already have the lookup tables for Downlink, so let's also add
the respective tables for Uplink. This renders ul_amr_fn_is_cmi()
useless, so remove it together with the sched_utils.h file.
Change-Id: Ibc23b5a94bd37fba8d918ad6ee61b93a6290d8a3
This reverts commit 1a8a80aeae.
We currently get ALL SI messages wrong - the protocol disseminator is
accidentally being used as SI msg type, and
6=radio resources management - but 6 is also type=si5ter.. so all SI we
receive end up being parsed as SI5, what a coincidence!
Change-Id: I3822f74295920680a935f3031c642ba00162d09d
This reverts commit c5d9507b5d.
Using osmo_ubit2sbit() was a bad idea because this function treats
the input buffer as ubits (while we deal with usbits) and produces
absolute sbit values: either 127 or -127. This is wrong, because
all intermediate usbit values are getting converted to -127.
This bug remained unnoticed so far because trxcon is mostly used in
combination with fake_trx.py, a virtual Um interface which simulates
ideal RF conditions by default and feeds trxcon with 'perfect' bits.
Change-Id: I3a32da19c9f419d51d55b301461ce28ce11b2249
The remote L1CTL peer may send another L1CTL_PM_REQ message right
after getting L1CTL_PM_CONF from us. Handle this properly.
Change-Id: I8e5fd778467567e8ca69ed420b9815073daa7e16
The L1CTL interface logic currently gets access to the trxcon_fsm
via an associated struct trxcon_inst. No other fields are used,
so we can pass trxcon->fi directly. All communication shall be
done via the FSM anyway.
Change-Id: I5a15a676ce3917d2eddc44f1143cea8d3cd8781f
This allows TTCN3 L1CTL module (used in BTS_Tests) to transmit and
receive AMR payloads towards osmo-bts-trx.
Related: SYS#5987
Change-Id: Ia20bc96e39726a919a556c83c8be48cb31af7331
For consistency with trxcon_inst_alloc():
* first allocate an instance of trx_fsm as a child of trxcon->fi,
* then allocate a trx_instance as a child of the trx_fsm.
Change-Id: Iafc486347c6ca7a80da88be73c772397fa2deb7d
Calling l1sched_free() from trxcon_fsm_pre_term_cb() may result in
l1sched_handle_config_req() being called when trxcon->phyif is NULL.
Handling l1sched_config_req via TRXCON_EV_SET_PHY_CONFIG_REQ guards us
against NULL pointer dereference during teardown of a trxcon_fsm
instance, if it's caused by TRXCON_EV_PHYIF_FAILURE.
Change-Id: I44bbc695e8a406a7acb9c163bf223f4ea966ea12
Related: OS#5599
* trxcon_inst_alloc(): allocate trxcon_fsm as a child of the given ctx.
* trxcon_inst_alloc(): allocate trxcon_inst as a child of trxcon_fsm.
* trxcon_inst_free(): move the cleanup logic to .pre_term() callback
of the trxcon_fsm, represented by new trxcon_fsm_pre_term_cb().
* trxcon_allstate_action() properly handle TRXCON_EV_{PHYIF,L2IF}_FAILURE.
Change-Id: I5eb8ef6f62b1dc949dc60eaa558f123b3b93819c
Related: OS#5599
The underlying L1 implementation uses both chan_nr and link_id to
determine a logical channel for sending an Access Burst. If not
set (both 0x00), RSL_CHAN_RACH is assumed. Indicate it implicitly.
Change-Id: Ia40f67920bd712e572b8ea5219eb83064106bd5d
There is a time window between activation of a dedicated channel and
receipt of a L1CTL_DATA_REQ with the first RR Measurement Report, in
which trxcon may need to start transmission on Uplink SACCH.
In this case trxcon is using a dummy SACCH block with hard-coded L1
SACCH header values and hard-coded Measurement Results. This mimics
behavior of the layer1 implementation in firmware for Calypso phones.
When running the mobile application, this error can be seen:
DAPP ERROR trxcon(0)[0x55ee57bee1a0]{FBSB_SEARCH}:
Event TRXCON_EV_RX_DATA_IND not permitted
which means that the mobile is sending L1CTL_DATA_REQ *before*
establishing a dedicated channel. And this message contains an
RR Measurement Report. The idea behind this is to populate the
SACCH cache in advance and thus avoid sending dummy values.
Let's allow the L2 apps populating SACCH cache before establishing
a dedicated connection using new TRXCON_EV_UPDATE_SACCH_CACHE_REQ.
Change-Id: I0f467fc07cf844cc73465f235b36ba7d00788c9f
Related: OS#5635, OS#5599
Basically, everything below layer 2 is layer 1. Let's clarify the
domain of TRXCON_EV_L1IF_FAILURE by saying 'PHYIF' instead of 'L1IF'.
Change-Id: I9159492a04bc071b7b04d9b88d4e6fd13cc3af31
The original trxcon_fsm I wrote back in 2017 [1] was more like
a boolean flag, as there were only two states: IDLE and MANAGED.
Not surprising, given that until recently handling of multiple
L1CTL connections was not supported. Now that we have this
implemented, lifetime of a trxcon_fsm instance is limited by
lifetime of a L1CTL connection, what renders the FSM useless.
This change removes the old 'boolean' trxcon_fsm and introduces
the new one, which will allows us to abstract the L1CTL interface
from the TRXC/TRXD interfaces, as well as the scheduler. The new
FSM will also simplify development of the RLC/MAC layer for GPRS.
Change-Id: Ifaf63ead9dd180181358e771367b2a686ba159ca
Related: [1] I7ee6fc891abe5f775f5b7ebbf093181a97950dea
Related: OS#5599
Currently it may happen that the transceiver (e.g. fake_trx.py) remains
powered on when we loose a L1CTL client connection. This is going to
be fixed in change [1] re-implementing the trxcon_fsm. For now let's
ensure that the transceiver is properly powered off by sending
"CMD POWEROFF" from trx_if_close().
Change-Id: I9c5178907304b36ec3de0ee31b7f7a9ed2e31c16
Related: [1] Ifaf63ead9dd180181358e771367b2a686ba159ca
This change makes it possible to configure l1sched related logging:
* l1sched_logging_init() allows to configure logging categories for
common and data messages (by default, DLGLOBAL is used);
* struct l1sched_cfg allows to configure a logging prefix to be
used in l1sched messges (by default, 'l1sched[0x%p] is used)'.
Let's use osmo_fsm_inst_name(trxcon->fi) as the logging prefix.
Change-Id: I26da1a506b02502a3a6a887533c35fb09c13c429
Related: OS#5599, OS#3761
This should have been done in [1], but somehow I forgot about TRXD.
Change-Id: Ia5124061fe391644267a6117ac2627cad7adf873
Fixes: [1] Ic253903e7b8635bb13e210acfe929c73f8870632
Related: OS#5599
l1ctl_server_start() does not actually start the server, it simply
allocates memory and initializes it. l1ctl_server_shutdown() does
the opposite. Let's use more precise symbol names.
Change-Id: Ie039abdff3911c5b566c760b26c31203824c5764
Calling l1ctl_server_shutdown() whenever the server is not initialized
will result in accessing uninitialized values. This can happen if we
goto exit before l1ctl_server_start() was called.
Initializing the server with zeroes is not an option, because we need
to initilize llist_head and osmo_fd structures with proper values.
Allocate and initialize struct l1ctl_server in l1ctl_server_start(),
deinitialize and free() in l1ctl_server_shutdown().
Change-Id: Idf13914fd0b0ae09b2ce5ece1f4203ebcae05d6e
Related: CID#275254
Ideally, FBSB procedure should be implemented as a state of trxcon's
FSM. For now let's simply move the related fields to trxcon_inst.
Remove l1ctl_shutdown_cb() as it's not needed anymore.
Change-Id: I92b50cf1bb36886fbe3d6460af3c0b1c57256ae8
trxcon consists of the following three main components:
* the L1 TDMA scheduler (libl1sched),
* L1 interface (TRXC/TRXD over UDP),
* L2 interface (L1CTL).
In [1] and [2] the L1 scheduler was abstracted out from both L1
and L2 interfaces and separated into a library, so it does not
use the TRXC/TRXD nor L1CTL related API directly.
This change is the next step towards the goal of having all three
components abstracted from each other. Moreover, this patch brings
us closer to another goal of being able to support multiple L1CTL
connections (each having its own scheduler).
The idea is to give both L1 and L2 interfaces access to the
'trxcon_inst' structure, which basically groups all three components
mentioned above into a single piece. The end goal is to eliminate
direct interaction between the interfaces, and the scheduler, so that
one could easily replace TRXC/TRXD and/or L1CTL with something else.
Change-Id: I23319951c56577085e1092669b5534f9d6bda48d
Related: [1] I31f77976a7a225ef292fe6dcd583513aec97ed44
Related: [2] I001fb7bc2663eea308b5a8882746ed9863f2c2f8
Timeslot Number can never be negative, so let's use unsigned.
Rename the counter to 'tn' for consistency with other projects.
Change-Id: I93b5a91341e7f79ced0591e13250632ba5e5adef
Using L1CTL specific structures as the primitive payload was a
beautiful hack in the early days of trxcon. But since we're
going to separate the scheduler into an interface independent
library, we have to introduce and use an abstract API.
Change-Id: I84597d44ea7d74b8840a919ecb09988ba1980a73
Related: OS#5599, OS#3761
Make l1sched_prim_alloc() private and call it from l1sched_prim_push().
This makes the API more convinient, because both functions are always
used together.
Change-Id: Ia9c0170fb06efcef569e987b57ab9ab7f7c7e847
Related: OS#5599, OS#3761
Using uint8_t makes it impossible to allocate primitives with payload
of size 255 - sizeof(struct l1sched_ts_prim) and greater.
Change-Id: Ic19b8433118798f57500119f1caf10e117e5db19
Related: OS#5599, OS#3761
The current function name is confusing, because l1sched_prim_init()
is not only initializing a primitive, but also allocating it on heap.
Let's use '_alloc' instead of '_init' to reflect that.
Change-Id: Ie1bebb6829ba9f640455685fcd7309b6aa442ef0
Related: OS#5599, OS#3761
This is the first step towards the goal of moving the scheduler
into a separate library.
Change-Id: Ifa6137c239c215a3d323213ee74d34b419622be4
Related: OS#5599, OS#3761
File '.version' must be also listed in EXTRA_DIST, otherwise I get:
echo 0.0.0 > ../../.version-t && mv ../../.version-t ../../.version
/bin/sh: line 1: ../../.version-t: Permission denied
Change-Id: I65f7c505f5a231bab114c45f5fdd7421601dfbc0
Related: OS#5599, OS#3761
In reality, trxcon does not switch back to BCCH itself. Neither
the firmware does, so let's correct this confusing log message.
Change-Id: Iad308ad980af4caa7d7d1b358ba7288885f96e04
Do not send a dummy authentication response with the test sim.
Fixes: 39dc9c46 ("mobile/subscriber.c: consider GSM_SIM_TYPE_SAP too")
Change-Id: I0ee910c171d383fb2cdcaf5eb54eafe18da3430b
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I73be012c01c0108fb6951dbff91d50eb19b40c51
Some logging categories use LOGL_INFO or even LOGL_DEBUG. Lets set those
to LOGL_NOTICE to have a less crowded default log output.
Change-Id: I3faefccae2218b17bd942bc2afac7d8e515897b7
Related: OS#2577
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
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
It may happen that one or more Downlink bursts are lost on their
way to the MS due to a variety of reasons. Modern transceivers
supporting TRXDv1 protocol would substitute lost bursts with
so-called NOPE indications. Hovewer, neither fake_trx.py nor
grgsm_trx do support this feature at the moment.
We can still detect and compensate TDMA frame loss per logical
channels in the same way as it's already done in osmo-bts-trx.
In short, we should keep TDMA frame number of the last received
burst in the logical channel state, and using the appropriate
multiframe layout, check if there were any gaps between TDMA
frame number of the current burst and the stored one.
Change-Id: I3551d79796a3730565c2c70577e9d134e636f275
Vadim Yanitskiy
Pau Espin
Eric Wild
Oliver Smith
Harald Welte
Philipp Maier
Neels Hofmeyr