oml.c:461:20: error: returning 'HANDLE' {aka 'void *'} from a function with return type 'uint32_t' {aka 'unsigned int'} makes integer from pointer without a cast [-Wint-conversion]
Change-Id: I0831e448692713c488c0590a86bdc99b37160f47
OsmoBTS supports TW-TS-001 enhanced RTP format for FR and EFR codecs
since 2024, providing functional equivalent of GSM 08.60 TRAU-UL
output over IP physical transport. Now do the same with TW-TS-002,
IP equivalent of GSM 08.61 for HRv1 codec.
Only TCH UL path is affected; no changes are needed to TCH DL path
because existing RTP Rx handling for RFC 5993 also covers TW-TS-002.
Related: OS#6036
Change-Id: Icf11e43d4ce9df990d0e0a856d62d9ea11cb837c
As a result of how FR/HR/EFR DTX interacts with block diagonal
interleaving, at the beginning and end of each DTX pause a
correctly functioning TCH receiver will always pick up an
artifact consisting of 4 received bursts (2 for TCH/HS)
and same number of omitted bursts. Standard channel decoding
of this Rx artifact will produce a "half-block" in which half
of the bits prior to convolutional decoding will come from
a SID repetition whose Tx was notionally suppressed, while
the other half will be garbage. As a result of convolutional
decoding, the result will often appear as valid SID per
classification rules - but passing it as such to the Rx DTX
handler is wrong. Classic E1 BTS and GSM MS implementations
include a kind of SID filter at this point, setting BFI on
these received half-blocks, so that the Rx DTX handler will
see an invalid SID condition. Invalid SID means that comfort
noise generation is to be continued, but no updated CN
parameters are available - which is the truth in half-block
Rx situations. Implement the same filter.
Additional background info can be found here:
https://osmocom.org/projects/retro-gsm/wiki/DTXu_half-blocks
Change-Id: I46c62312316b04567bcadf6050597673f071247d
In any environment where GSM MS may exercise DTXu on TCH/FS, TCH/HS or
TCH/EFS, the BTS receiving this TCH UL has to classify each received
traffic frame as valid SID, invalid SID or non-SID speech. For E1 BTS
this SID classification requirement is explicit as there are dedicated
bits in TRAU-UL frames carrying the SID code. For an IP BTS the need
for this classification is less obvious as most RTP payload formats
omit SID indicator bits - however:
* For HR codec, RTP output in RFC 5993 and TW-TS-002 formats does
include explicit SID classification;
* Also for HR output in both TS 101 318 and RFC 5993 formats
(but not TW-TS-002), SID classification must be considered in order
to turn valid SID with some bit errors into perfect SID codeword;
* OsmoBTS already had logic for all 3 of FR/HR/EFR whereby if a frame
is received that is an accepted SID frame in GSM 06.31/06.41/06.81
definition, a flag is set so that the next good speech frame will
be emitted in RTP with marker bit set. This logic implies SID
classification in TCH UL path.
Prior to this patch, OsmoBTS performed limited, non-consolidated
SID classification:
* For FR and EFR, the only SID classification in TCH UL path was done
for RTP marker purposes by way of osmo_{fr,efr}_is_any_sid() Boolean
result fed to lchan_set_marker();
* For the same RTP marker logic with HR codec, only perfect, error-free
SID frames were detected;
* The same limitation applied to SID classification for RFC 5993 output.
Centralize this SID classification by moving it from BTS model to common
l1sap code and unifying it across all 3 codecs. Immediate functional
effects from this change are:
* On TCH/HS we now detect imperfect (partially corrupted) SID frames
and classify them as valid or invalid SID as intended by ETSI,
like we already did for TCH/FS and TCH/EFS;
* When emitting TS 101 318 or RFC 5993, we apply the inherent limitations
of those RTP formats to valid and invalid SID;
* With all 3 codecs, the check for a good speech frame as exit criterion
from DTXu state now happens after the link quality check in l1sap,
rather than before.
AMR speech mode is not affected at all by these changes: AMR DTX model
is completely different from that of FR/HR/EFR.
Related: OS#6036
Change-Id: Id6c8c146962de2f173760889eb232693bb4229d3
In original OsmoBTS architecture prior to Themyscira patches,
BFI (Bad Frame Indication) condition was signaled internally by
zero-length payload passed from BTS model to l1sap, and externally
by absence of RTP output (intentional gap) or a zero-length RTP
payload emitted in 'rtp continuous-streaming' mode. However, this
paradigm is contrary to classic GSM BSS architecture in which BFI
is an out-of-band metadata flag that travels alongside with frame
payload bits, whether the latter are valid or invalid.
Since 2024 OsmoBTS supports the option of TW-TS-001 output for
FR and EFR codecs, which allows the possibility of BFI-with-data
in RTP. OsmoBTS can already emit such BFI-with-data packets when
the BTS model delivered a deemed-good traffic frame, but that frame
was subsequently deemed bad by the link quality check in l1sap -
but there is still no explicit out-of-band BFI flag inside OsmoBTS
TCH UL path.
By introducing an out-of-band BFI flag, we make it possible for BTS
model PHYs to deliver marked-bad traffic frames: when CRC fails
in GSM 05.03 channel decoding step, a PHY that permits modification
(libosmocoding or future FOSS DSP PHY) can be enhanced to preserve
channel-decoded bits while conveying BFI.
The link quality check in l1sap is reworked to use the new OOB BFI
flag. Follow-on patches will introduce further logic that can also
assert BFI at high level, above BTS model PHYs.
While reworking the link quality check in l1sap, restrict it to
speech modes only: per GSM specs, BFI does not exist in CSD.
Change-Id: I8097946429e83eae90f89e49d17ffb8eb0636fcb
If osmo-bts-trx exit()s due to the PC clock issues, e.g. if the
process stalls, it produces rather confusing logging messages:
DL1C ERROR PC clock skew: elapsed_us=387574, error_us=382959
DOML NOTICE ... Shutting down BTS, exit 1, reason: No clock from osmo-trx
The second message suggests that the transceiver (osmo-trx) is the
culprit, but the first one reflects the actual reason (PC clock skew).
Let's pass proper shutdown reason to avoid confusion.
Change-Id: Ibbbbc4e919e6eb812882fc60de4be13fa77934b7
The purpose of the power control interval (P_CON_INTERVAL) is to
temporarily suspend the decision-making process of the MS/BS power
control algorithm, allowing time to observe the effects of a
previous adjustment.
However, input value (RxLev/RxQual) averaging must continue
uninterrupted, regardless of the power control interval.
Otherwise we're simply loosing measurement samples.
Change-Id: I2ccad1cb0ebbfcce64a93bc81b66db37b1399769
We receive a TXT indication that contains the PCU_VERSION from the PCU when the
connection to the PCU is established. This message contains a BTS number, which
is always 0. This is a hard coded value that does not refer to a specific BTS
object. Also it is not logical to inform a specific BTS object about the PCU
version. This information should be directed to the connecting process as a
whole. However, we use this TXT indication to trigger certain initialization
processes on the BTS object we manage inside the BTS process (currently this
is only 1 bts, but this may change in the future). So instead of using the
BTS in the TXT indication, we should iterate of over all BTS objects and
trigger the initializations for each of the BTS objects.
This change does not have any dependencies, nor does it change the current
behavior of osmo-bts. It just cleans up the logic, so that it works by
intension and not just by chance.
Related: OS#6507
Change-Id: I1bb8d0ec5e8d4b9f822f94249a75d8dc477144a3
That header is only really used to provide an old hack for
ipaccess-proxy tool in openbsc.h/osmo-bsc.h, and will be deprecated
soon.
Take the chance to organize a bit better the includes based on dependency
chain.
Change-Id: Ie4540eb6f535375a1e4ddf3849602aecb6260914
Call to e1inp_sign_link_destroy() may trigger a sign_down() callback,
which if happening synchronously, could end up reentring the same code
path we are in before bts->*_link was set to NULL.
Avoid it by marking the pointer as NULL immediatelly before calling
e1inp_sign_link_destroy().
Change-Id: Ibc06cdc2d2cd2028b7676fa0c3211ae251cca587
Add cmdline args to control logging, as already present in other more
usual bts models.
This is extremely important here since there's no VTY at all to
configure them.
Change-Id: I0b33919d71bacefe60be192810518fd927625127
Thanks to the work done by Mychaela (see the related Change-IDs), we
can finally implement handling of TCH/F14.4 (both T and NT modes) for
osmo-bts-trx and osmo-bts-virtual.
This channel mode is special in a way that it employs a different
rate adaptation function RAA' (defined in 3GPP TS 48.020 chapter 11),
which converts between between 290-bit blocks used on Um and Abis-E1
interfaces (E-TRAU frames on the latter) and A-TRAU frames spoken
over the A interface.
The result of function RAA' in the Uplink direction is 320 bits,
which is equal to 4 x 80-bit V.110 frames, but actually carrying
8 x 36-bit packed frames. These 320 bits are then fed to the RA2
function, like we do for other CSD channel modes.
Change-Id: I3c3bef0bd2f72b8381597b5699e2060165b702a0
Depends: libosmo-abis.git I11fc1529f5be88fa778c7e05cb11eef58a389d40
Depends: libosmo-abis.git I1347a25ce97d5022502ee9112caded66315b09a4
Related: OS#6167
According to 3GPP TS 44.021, section 10.3.2, a radio-interface data
block for a TCH/F14.4 channel consists of eight 36-bit data frames
and two M-bits (290 bits total). Let's fix our definition.
Change-Id: I4f11eda98420587efa339484b62f46bf19f78809
Related: OS#6167
A radio-interface block in GSM carries several modified 36-bit or
60-bit V.110 frames. Let's rename the fields to avoid confusion.
Change-Id: If97787a64e30ff9b39c26749ba32aed09d3d7983
The 'resp_msg' will be NULL if msgb_dequeue_count() returns NULL,
i.e. in the case of Downlink queue underrun. We need to handle
this gracefully and check 'resp_msg' before dereferencing it.
Change-Id: I4e1ea1d1ded2ffb3a07cc06f8b9b5dd922d32ec6
Fixes: 0a34af153 ("CSD NT modes: transmit properly aligned RLP frames on DL")
The mapping sched_tchh_dl_csd_map[] is valid for DL TCH/H4.8 and
TCH/H2.4, but not for DL FACCH/H. We already use a separate
lookup table sched_tchh_dl_facch_map[] when sending RTS.ind for
DL FACCH/H, so no additional checks are added in this commit.
Change-Id: Idb753fa5c87dc79e9ad19e550680de6f462eed69
Fixes: 95407f3f6 ("osmo-bts-trx: implement CSD scheduling support")
Related: OS#1572, OS#6618
lchan->abis_ip.rtp_socket is NULL before the BSC indicates the RTP
parameters using the CRCX/MDCX procedures. send_ul_rtp_packet()
does check lchan->abis_ip.rtp_socket against NULL before calling
osmo_rtp_send_frame_ext(), so should send_ul_rtp_packet_hrdata().
Take a chance to make send_ul_rtp_packet_hrdata() more consistent
with the send_ul_rtp_packet() by reordering code a bit.
Change-Id: I05d88a739dc54ca68e50d20b2d0d0b097ae8ca4a
Fixes: 59686cd27 ("CSD: implement half-rate modes correctly")
Related: OS#6618
There are two levels of alignment inside clearmode RTP packets
carrying CSData per TS 48.103 section 5.6:
1) Alignment of 2 or 4 V.110 (T) or pseudo-V.110 (NT) frames within
one RTP packet of 160 octets of an imaginary ISDN B channel;
2) For NT modes only, alignment of 4 pseudo-V.110 frames to form
a single 240-bit RLP frame.
Per previous patch, alignment 1 is to be treated as mandatory for
RTP transport inside an Osmocom network. Alignment 2 _could_ be
made mandatory for TCH/F9.6 NT, but the same is not possible for
TCH/[FH]4.8 NT: in the best case of half-alignment, alternating
RTP packets will carry alternating halves of RLP frames.
Implemented solution: allow arbitrary state of alignment 2
(aligned or misaligned) in the incoming RTP stream for all CSD NT
modes, and perform the necessary alignment internally.
This approach is consistent with the world of E1 BTS: a TRAU in
data mode is responsible for alignment 1 (with 20 ms TRAU frames
taking the place of our clearmode RTP packets), but only the BTS can
perform alignment 2, as the TRAU is agnostic to T vs NT distinction.
Related: OS#6579
Change-Id: Idaebfce6da13b23ba265a197502712d83991873e
The next patch in the series will add code for alignment of downlink
RLP frames in CSD NT modes; that code will go into new file csd_rlp.c.
RLP GSMTAP code logically belongs in the same place - hence move it
there in preparation.
Change-Id: I824ce6614c8591cccc5f6bcdde767fe49d551378
The code in this function used else-after-return constructs, which
are now rejected by the linter for newly committed code. This
function needs to be moved to a new source file, which will cause
it to be treated as new code by the linter - hence fix this code
style issue first.
Change-Id: Ide00e819222bb0173eca42ee3714db7f7e1a6d1e
Modify CSD RTP input path code so incoming bits E2 & E3 from V.110
frames reach the TCH-RTS.ind handler in l1sap. These bits will be
used in the next patch to ensure proper alignment of DL RLP frames
in non-transparent CSD modes.
Related: OS#6579
Change-Id: I43b97caa6030b9401779998ca5dddc4cfe636e2f
Since the beginning of CSD implementation, OsmoBTS has operated
with an implicit (unstated) policy that V.110 frames must be
perfectly aligned within received clearmode RTP packets - a requirement
which is NOT set anywhere in TS 48.103 or any of the other specs
it references. This design policy is sensible from the standpoint
of implementation complexity (both OsmoBTS and osmo_trau2rtp emit
such perfectly aligned packets; if someone is building a gateway
between an Osmocom GSM network and ISDN-style external networks,
that gateway can act as the aligner), but it should be explicit
rather than implicit.
Check V.110 frame alignment in received clearmode RTP packets,
and reject packets that fail this alignment check.
Change-Id: Icd704dc7fa02e60074efc8a29ad7e42ebdf63783
In all classic NT modes below 14.5 kbit/s, V.110 frame bits E2 and E3
are repurposed to indicate the alignment whereby a single 240-bit RLP
frame is composed of 4 pseudo-V.110 frames in switching transport.
(TS 48.020 section 15.1.) In the case of TCH/F9.6, setting both E2
and E3 is easy because all 4 pseudo-V.110 frames go out in the same
clearmode RTP packet as a result of a single channel decoding
operation. However, in the case of TCH/F4.8 there are two separate
channel decoding operations producing two separate RTP packets
20 ms apart. Furthermore, GSM 05.03 section 3.4.1 specifies which
TDMA frame positions hold which half of the RLP frame - therefore,
the correct emission of bit E2 needs to be based on the TDMA frame
number at which the block was received.
A similar situation occurs with TCH/H4.8 NT: we receive a single
block from the 05.03 decoder every 40 ms, containing a full RLP frame,
but we emit it as two separate RTP packets, each carrying 20 ms worth
of bits. These RTP packets also require correct setting of E2 bit.
Related: OS#6579
Change-Id: I485af5e01ea87c1721a298a486cd344a17884200
TCH/H4.8 and TCH/H2.4 modes are different from all other TCH in that
the channel coder runs (statistically) every 40 ms instead of the usual
20 ms. However, the standard RTP interface of TS 48.103 still requires
20 ms packets for all CSD modes; furtherfore, this requirement is not
just a matter of 3GPP spec being obstinent, but is highly useful for
interoperability, both between FR and HR and between OsmoBTS and E1 BTS.
The handling of CSD HR was totally broken in this regard: wrong RA2
packing mode, RTP clock model was violated, and even an internal
mismatch with l1sap sending TCH.req prims at twice the rate
at which the PHY expects them.
With this patch CSD HR handling becomes correct for TCH/H2.4 and for
TCH/H4.8 transparent; fully correct handling for TCH/H4.8 NT will
appear in a follow-up patch.
The packet/frame rate mismatch (40 ms Rx/Tx times while each RTP packet
carries 20 ms worth of data) is reconciled by emitting two RTP packets
directly back-to-back for UL, and pulling two RTP packets at a time
from the Rx jitter buffer at the needed times for DL.
Note: due to bug OS#6604, TTCN3 tests for CSD half-rate transparent modes
will start failing once this patch is merged; to make them pass again,
TTCN3 test code will need to be reworked to fix that bug.
Related: OS#6577
Change-Id: Ib35e910df263743cd243f51fb0bd6551ddfcf4c5
In commit 66eae187, I skipped assigning LCHAN_CSD_M_NT (0) to
lchan->csd_mode for non-transparent channel modes. I assumed that
the entire gsm_lchan struct was zero-initialized during activation
or release procedures, but this assumption was incorrect.
In fact, some lchan fields are initialized during activation, while
others are initialized during release. Specifically, lchan->csd_mode
is zero-initialized when the process starts, and then updated only
for transparent mode requests. For non-transparent mode requests,
this field is not updated, meaning it retains its previous value.
This bug caused incorrect E1/E2/E3 bit settings and missing GSMTAP
RLP output for channels that were previously used for transparent
CSD calls. This patch is fixing it.
Change-Id: I793ab4dc25fa852eade6f7a3b67ae961ceb7a093
Fixes: 66eae187 "rsl: rsl_handle_chan_mod_ie(): set lchan->csd_mode"
Related: OS#1572, OS#6579
The existing tests are all for T (transparent mode).
Add NT (non-transparent mode) variants.
Change-Id: Ie335bc0623dd7e887a0b3b1c40d61153b84924b2
Related: OS#1572
When sysmoBTS PHY decodes TCH UL Rx as FACCH, it sends only one
PH-DATA.ind for the FACCH, but none for TCH. This case was handled
correctly for TCH/F in 2023-03, but FACCH/H has not been handled
correctly until now.
Change-Id: Id6d966348fb2be084485279e75480f98f46e464b
In a typical lab setup the BSC is co-located on the same host with
the BTS process. Using the localhost address instead of random
addresses makes life easier for those using example configs.
Change-Id: I41b8de14c19088ef614ce751c738e4fc5969f0da
These lines yield nothing without the 'gsmtap-remote-host' parameter
actually enabling GSMTAP Um logging. Remove them to avoid confusion.
Change-Id: Icde668b5829a56663c258e54957e2f639a8e82a9
Ensure that the 'ipa unit-id' in all config examples is set to
value 6969, matching the value used in the osmo-bsc config examples.
Change-Id: I2b5ed8eaa5c2cbfe20091dcfea0dd1a70f148f7c
The access burst detection must be enabled on channel activation, if the
handover is activated or if the channel is used for group / broadcast
call.
Related: OS#6467
Change-Id: I467a11662a580e33932ae142dcf605f4c0672daf
Themyscira Wireless Technical Specification TW-TS-001 defines
an enhanced RTP transport format for FR and EFR codecs within
an IP-based GSM RAN, restoring the full functionality and semantics
of GSM 08.60 TRAU-UL format that were lost in the industry transition
to RTP with payload formats standardized by TIPHON and IETF.
Given that this new enhanced RTP transport format runs counter
to commonly accepted standards, it is strictly optional. OsmoBTS
always accepts both basic and extended RTP formats, but it sends
the extended RTP format of TW-TS-001 only when commanded to do so
by the BSC via an RSL extension IE; OsmoBSC will in turn direct
the BTS to use this extension only when the CN asks for it via
the BSSMAP extension defined in TW-TS-003.
Spec references:
https://www.freecalypso.org/specs/tw-ts-001-v010100.txthttps://www.freecalypso.org/specs/tw-ts-003-v010002.txt
Related: OS#6448
Depends: I0eccfe5ddcf44f8f20440acb01e2d4870ec0cd91 (libosmocore)
Change-Id: Id997e8666bc19e60936aaa83b43a968d30320bd7
This IE has TLV format, even though the only valid form is a single
value octet. To guard against pathological input with L=0 in this IE,
we have to check the length explicitly with TLVP_PRES_LEN before
accepting TLVP_VAL as if it was TV.
Change-Id: I15fa75b6c30d7fa0bf50424d25fc47a088dada0a
I have verified that with AmbientCapabilities=CAP_SYS_NICE, setting
scheduling policy as described in the manual still works as expected.
Related: OS#4107
Change-Id: I37be0dd4df012047a495235195912bd06ad2423d
A new command was recently added to libosmovty:
show fsm-state-graph NAME
This is now the longest command, affecting spacing in the output
of 'show ?' command. Align spacing to make the test pass again.
Change-Id: I80f896e45a88550909c5767169286fc321a36e56
Related: libosmocore.git I09ee0a8c3fc4b1aa991ab5c93c0b654fccd7ea4c
