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
Using TDMA frame number of a burst with bid=0 is fine for xCCH,
but not for TCH and FACCH, because they use the block-diagonel
interleaving. A single block on TCH may be interleaved over
8, 4 or even 6 consecutive bursts depending on its type.
Since we now have the measurement history, we can attach TDMA
frame number to each measurement set, and then look up N-th
one when averaging the measurements in sched_trx_meas_avg().
Change-Id: I9221957297a6154edc1767a0e3753f5ee383173f
This allows us to bind the multicast sockets to a given network device
and/or to set the TTL of the multicast frames and hence control their
reach in terms of number of network hops.
Change-Id: Ia74aa381a4c1921cb8c7e263842a864ea8028139
Related: OS#2966
The files are used in both projects, and while the osmo-bts code has
evolved, this copy didn't. Let's sync again (to libosmocore
change-Id I303f2e616d2d32b5a8005c3dcf0f5fad19ad3445).
Change-Id: I189ee28a85a6d7a7a07b062f6b07012478503e8f
Depends: libosmocore.git Ib52d22710020b56965aefcef09bde8247ace4a9c
Related: OS#2966
In case we get assignments to secondary TRXs, the ARFCN of that
TRX must be used, and not the serving cell BCCH ARFCN.
Change-Id: Ief6cf5816969d819ff9506be70bec9b8d0d9d9be
GSMTAP_CHANNEL_VOICE is the mechanism by which GSMTAP can [finally!]
be used to transport circuit-switched voice codec payload, and not
just signalling.
Original patch by Neels Hofmeyr, heavily extended by Harald Welte.
Change-Id: Id72cf23b7c6587efae4cdaa7b50ab4d85b8c8d22
These BFI (Bad Frame Indications) substitute speech frames stolen
by FACCH/F or FACCH/H frames, so there can be no bit errors in
something that was not even transmitted over the air interface.
Change-Id: Icdb6209f75ead6581e3c18aeee0da9831aaa272a
According to 3GPP TS 45.003, clauses 4.2.5 and 4.3.5:
- one FACCH/F frame steals a single speech frame,
- one FACCH/H frame steals two speech frames.
A BFI (Bad Frame Indication) needs to be sent for each stolen
speech frame. This does not apply to CSD (data) channels though.
The BFI frames must have measurement data attached to them, and
due to their virtual nature (they do not actually come from the
air interface), the measurements must be crafted by trxcon.
Assigning a negative value to n_errors makes the code below the
'bfi' label craft fake measurement data. Otherwise, the actual
measurements belonging to the FACCH frame will be used.
Change-Id: Ia2f7c3cf7b1ef3737da6b1818cae2f001ee8768f
So far we used to store the sums of ToA and RSSI measurements in the
logical channel state, and after decoding of a block, we did calculate
the average. This approach works fine for xCCH and PDTCH, but when it
comes to block-diagonal interleaving (which is used on TCH/F and TCH/H
channels), the results are incorrect. The problem is that a burst on
TCH may carry 57 bits of one encoded frame and 57 bits of another.
Instead of calculating the sum of measurements on the fly, let's push
them into a circular buffer (the measurement history), and keep them
there even after decoding of a block. This would allow us to calculate
the average of N last measurements depending on the interleaving type.
A single circular buffer can hold up to 8 unique measurements, so the
recent measurements would basically override the oldest ones.
Change-Id: I211ee3314f0a284112a4deddc0e93028f4a27cef
In Change-Id Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2 we
introduced a new member to the ccch_mode enum: CCCH_MODE_COMBINED_CBCH,
which is to be used to tell the PHY if a CBCH is present on the combined
CCCH+SDCCH/4+CBCH or not (CCCH+SDCCH4).
This was implemented in trxcon + calypso firmware, but cbch_sniff has
not been updated accordingly.
Related: OS#4439
Change-Id: I429d45cfb181da4a2e767e92f1213ccd08c6d440
Doing so can create a number of warning messages in e.g. 'mobile'
like
<0015> lapd_core.c:1239 Unnumbered frame not allowed. (dl=0x55c632f9f220)
<0015> lapd_core.c:392 sending MDL-ERROR-IND cause 12 from state LAPD_STATE_IDLE (dl=0x55c632f9f220)
<0015> lapdm.c:481 sending MDL-ERROR-IND 12
<0001> gsm48_rr.c:4977 MDL-Error (cause 12) ignoring
Change-Id: I2cf65be5b2f879fe940e08c9f369bc1cada7b0dd
Closes: OS#4439
We so far relied on it being free'd once the TDMA item is free'd,
but let's make it more explicit. After we've unlinked it from the
list, nobody is going to reference it ever again.
Change-Id: I57a596428be10ce720e0b528ecfc44a70e3e3078
That function encapsulates the RTP payload in an MNCC header, but the l1ctl dl
header has to be removed first to get only the RTP payload in the MNCC
structure.
Change-Id: Id6ddc9b1da43e88c5b9468d4397a39953bdf533a
This pointer cs->si stores an address to the System Information of
a currently selected cell. When we release System Information,
ensure that it does not point to free()d memory.
Change-Id: Ife2ddf7274a48447a9ded9035f9dd01befaf2e6c
Some applications (e.g. ccch_scan) may not initialize ms->cellsel.si,
some (e.g. mobile) may need some time to initialize it. Let's assume
that 'bs_ag_blks_res' is 1 if System Information is not available.
Change-Id: Ie695d9700c01ee1e6778950a2f3c8610b69d2143
During 3.19->3.20 dev cycle, some fields were transformed from
timestamp_t or double to timespec_t. See for instance gpsd.git
f7c230fceb6d64483757f8c32afb98e6a2cb9413.
Change-Id: Ie8ba19d030b6f46f2d8afc270a732ce8c26c438f
In several code paths we put / push structures from 'gsm48_mm.h' into
the message buffers, so then they're unpacked by the message receivers.
The AddressSanitizer complains about unaligned pointer access and
potentially unexpected behaviour. Let's fix this by explicitly
marking those structures as 'packed'.
Change-Id: I6af7475c609b3293af708540d569fe1616fab43f
In some cases (e.g. at start up) ms->rrlayer may not be initialized.
Let's access ms->settings directly since we already have a pointer
to struct osmocom_ms.
Change-Id: Ia9720132fcda960dcecefab9ae48398946503dc4
Due to recent include dependency tree change in libosmocore, trxcon
fails now to build since it uncovered it's missing a header inclusion
for a symbol it is using:
osmocom-bb/src/host/trxcon/sched_trx.h:204:20: error: ‘GSM_MACBLOCK_LEN’ undeclared here (not in a function)
204 | uint8_t mr_cache[GSM_MACBLOCK_LEN];
| ^~~~~~~~~~~~~~~~
Change-Id: Ide22e525c106342b00171a8c08bb7265d19a651b
This feature may be useful for our TTCN-3 testing infrastructure.
By default it's disabled, and can be enabled using command line
arguments of the main binary:
./trxcon -g 127.0.0.1 ...
Change-Id: Iab4128fee5f18d816830fdca6c5ebebaf7451902
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - it has nothing to do with xCCH coding. Instead, we need
to use rx_pdtch_fn() for Downlink and tx_rach_fn() for Uplink.
Also, since we only have a shared RSL channel number for PDCH
(Osmocom-specific RSL_CHAN_OSMO_PDCH), there should be a way
to distinguish both PDTCH and PTCCH logical channels. Let's
introduce TRX_CH_LID_PTCCH for that.
Change-Id: I2d1e9b8a66f027047f8d7bdc3f82ff9d8ebcc25e
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: I25baaa30b097dad2fae507c5321778f43e863611
Related: OS#4138
According to GSM TS 04.08, section 10.5.4.11, location and coding
standard are encoded before the cause value, not vice-versa!
Also, coding standards other than "1 1 - Standard defined for the
GSM PLMNs" shall not be used if the cause can be represented with
the GSM standardized coding.
Change-Id: Ic6abcfb9a9589f5b0c9c40def863f15ae04d0bdd
The gsm0503_pdtch_encode() returns negative number on error,
and the amount of encoded bits in case of success.
Change-Id: I7d75141142922909330c5e86be8734bb06cd57a4
During the handover the MS needs to release the existing dedicated
channel(s), establish the new one(s) as indicated by the network,
and then, depending on the synchronisation state, send one or more
HANDOVER ACCESS messages carried by Access Bursts.
In order to implement this, trxcon needs to be able to transmit
Access Bursts on any TDMA timeslot regardless of the logical
channel type and the associated handler, i.e. != TRXC_RACH.
The controlling side on L1CTL (layer23 or TTCN-3) needs to send
one or more L1CTL_RACH_REQ message(s) with properly populated
UL info header. Otherwise a regular RACH on TS0 is assumed.
Change-Id: Ia967820a536c99966ba2c60b63d2ea9edb093f46
Before this patch, prim_dequeue_sacch() used to ignore SACCH primitives
with odd length (e.g. 21, when sender forgot to push 2 octets of L1
SACCH header), so neither they were transmitted, nor rejected.
As a result, they would stay in the Tx queue until a dedicated
connection is released. The only way to notice such problem
was looking at the constantly growing talloc's report.
Instead of ignoring the primitives with odd length and keeping them
in the queue, let's pass them to a logical channel handler, so they
would be dequeued and rejected with a proper logging event.
Also, to simplify further debugging, let's print the final decision
of SACCH prioritization: whether it's a Measurement Report or not.
Change-Id: I3149fa518439470b397953306209eb859c83450a
According to 3GPP TS 05.02, section 6.4.1, CBCH replaces
SDCCH number 2 in both V (BCCH+CCCH+SDCCH/4+SACCH/4) and
VII (SDCCH/8+SACCH/8) logical channel combinations.
Unfortunately it is not clear whether we can use stolen UL slots
for RACH or not. For now, we should mark all of them as IDLE.
Somehow TRXC_SDCCH4_2 slots were left in the definition of
combination V (combined CCCH+BCCH). This is not critical,
but may be looking confusing. Let's fix this.
Change-Id: Id30f2fac3274de3edff4ae59f77d9c9cf8059155
The existing logic unconditionally wants to send a POWERON command
on TRXC whenever L1CTL_FBSB_REQ is received. That may cause some
problems when sending subsequent L1CTL_FBSB_REQ, e.g. due to signal loss.
Sending POWEROFF when transceiver is not powered on is normal though.
This can happen if trxcon is restarted while fake_trx was running.
The existing FSM state could unfortunately not been used, as it's a
mixture between the TRX connection state and the command/response state.
The current solution is just a work around. We definitely need to
introduce separate state machines for transceiver and its TRXC
interface.
Change-Id: I834e8897b95a2490811319697fc7cab6076db480
Both PRIM_IS_RACH() and PRIM_IS_EXT_RACH() macros to be used for
handover RACH detection in the follow up changes, thus we need
have them widely available. Let's also give them better names:
PRIM_IS_EXT_RACH -> PRIM_IS_RACH11
PRIM_IS_RACH -> PRIM_IS_RACH8
and introduce a new generic one for checking whether a given
primitive is RACH in general (either 8-bit or 11-bit) or not.
Change-Id: Ibc39c57fda000647be1829786f6423dcf3f435cd
It makes sense to do this first, before tuning to a different
ARFCN and changing the training sequence. Otherwise, if no
multi-frame configuration is found, trxcon would switch to
a different channel and then remain inactive there.
Change-Id: I274588ce3a9c49372b5da0629930afece46f799c
Having magic pre-calculated hex-masks gives one quite high chances
to shoot oneself in the foot, and decreases readability in general.
Let's do this pre-calculation during the compilation process, so
it's much easier to read, extend and spot potential bugs.
Change-Id: If945b3654e35c83fc0220fdd6d99c1c7a0503386
In I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843 I introduced a regression.
TRXC_SDCCH4_CBCH should have TRX_CH_FLAG_AUTO, because it's a part of
GSM_PCHAN_CCCH_SDCCH4_CBCH multi-frame layout. If the controlling
side on the other end of the L1CTL link requests this particular
multi-frame layout, CBCH channel is expected to be active.
Change-Id: I3ed942106a03220417b5cb9176107af057120fbe
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Also, let's get rid of field 'chan' of 'trx_lchan_desc' structure
since it's not used anywhere, and not actually needed because the
position of each lchan description is defined by its TRXC_* type.
As a bonus, let's add a human readable description to each
lchan definition, so it can be printed in the VTY some day.
Change-Id: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
PDCH channel support was introduced quite a while ago, but there
was no way to activate it via L1CTL so far. Let's fix this.
Change-Id: I3b66cab26108ab999a7fe969365ab57dc661399c
Wherever possible, use #defines from libosmogsm as opposed to magic
numbers. Using magic numbers in several places has the danger of
different programs/repositories having different views on what those
values mean.
Change-Id: I7ab4958801b3422973b67ff0452b90afa8a3f501
Related: OS#4027
Depends: libosmocore Change-Id I93e557358cf1c1b622f77f906959df7ca6d5cb12
OsmoBTS, BSC and TTCN3 used cbits == 0x18 for dynamic PDCH, while
trxcon wanted to use 0x18 for CBCH on SDCCH/4. Let's fix this and
bring everyone in agreement.
Related: OS#4027
Change-Id: Ia9a415628c659cbc2dd5dc65b875b7f935d6e211
sap_fsm.c: In function ‘sap_negotiate_msg_size’: sap_fsm.c:103:15:
warning: passing argument 1 of ‘__bswap_16’ makes integer from pointer
without a cast [-Wint-conversion]:
size = ntohs((uint16_t *) param->value);
^~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Ie58af6162c67ae377809b42daa897ca3f3d72af1
According to the man page of recv(), the only difference of this
call from read() is the presence of flags. With a zero flags
argument, recv() is generally equivalent to read().
Change-Id: I6d43bbf8d52c5fbb8ee0592b7d1c1dfd2dd1548e
Since we only set both ARFCN and TDMA frame number of the DL info
header, other fields remain uninitialized. Let's memset() them.
Change-Id: Ib39c333f1724fefa5d8bd8a2315b77a5612f7fa9
This would allow to abstract both L1CTL and TRX interfaces
from each other in the upcoming refactoring.
Change-Id: I74a23c73b03bad822272b9cfe76c2501666912b7
In both gsm48_mm.c and gsm48_rr.c we put / push 'gsm48_rr_hdr'
structure into the message buffers, so then it's retrieved by
the message receivers. The AddressSanitizer complains about
unaligned pointer access and potentially unexpected behaviour.
Change-Id: I8aa2c0074b405afd0e76044ef076b6819fe1083b
In gsm322_l1_signal(), if S_L1CTL_FBSB_ERR is received, we free
stored System Information of the current cell, but cs->si may
still point to it. Let's set it to NULL.
Found with AddressSanitizer:
DL1C ERROR l1ctl.c:96 FBSB RESP: result=255
DCS INFO gsm322.c:2995 Channel sync error, try again
DCS INFO gsm322.c:467 Sync to ARFCN=860(DCS) rxlev=-106
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DL1C ERROR l1ctl.c:96 FBSB RESP: result=255
DCS INFO gsm322.c:3008 Channel sync error.
DCS DEBUG gsm322.c:3013 free sysinfo ARFCN=860(DCS)
DCS INFO gsm322.c:3020 Unselect cell due to sync error!
DCS INFO gsm322.c:509 Unselecting serving cell.
=================================================================
==6014==ERROR: AddressSanitizer: heap-use-after-free on address
0x61b0000000e6 at pc 0x00000050d6dd
bp 0x7fff7f84aa60 sp 0x7fff7f84aa58
Change-Id: I9cc526c18d69695d810de98703579818408de011
According to 3GPP TS 05.03, section 5.3, two coding schemes are
specified for access bursts: one for regular 8-bit bursts,
another - for extended 11-bit packet access bursts.
According to 3GPP TS 05.02, section 5.2.7, there are two
additional training (synchronization) sequences for RACH
bursts: TS1 & TS2. By default, TS0 synch. sequence is used,
unless explicitly stated otherwise (see 3GPP TS 04.60).
According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability
can be indicated by the MS using an alternative training sequence
(i.e. TS1 or TS2) and the 11-bit RACH coding scheme.
Change-Id: I36fd20cd5502ce33c52f644ee4c22abb83350df8
Vadim Yanitskiy
Oliver Smith
Harald Welte
Philipp Maier
Pau Espin
Neels Hofmeyr
Martin Hauke
Eric Wild