When FACCH stealing occurs and sysmoBTS L1 delivers GsmL1_Sapi_FacchF
instead of GsmL1_Sapi_TchF, that 20 ms unit still needs to be
accounted for in the RTP timestamp cadence, and if we run with
rtp continuous-streaming enabled, then an actual BFI packet needs
to be emitted. The original code failed to do either; the present
change implements correct behavior for TCH/F.
The present patch only covers the case of TCH/F; handling of TCH/H
is left as a FIXME for other/later developers.
The check for (tch_ind->lqual_cb >= bts->min_qual_norm) in
l1sap_tch_ind() has the intent of suppressing valid-seeming
speech frame output from lower layers when the link quality is
too low; this check is particularly important for FR1 codec
where the intrinsic validity check is only a 3-bit CRC which has
1/8 probability of indicating "correct" when decoding radio noise
during DTXu silence.
However, this check is effectively defeated in the current
implementation of rtp continuous-streaming: the RTP packet being
output is the presumed-bogus speech frame from lower layers,
rather than the intended zero-length payload. Fix this bug.
This implements RTP based GSM BER testing for osmo-bts, implementing
ideas described in https://osmocom.org/projects/osmobts/wiki/BER_Testing
In short: The command transmits a PRBS sequence encapsulated in RTP
frames, which are sent to the BTS, which transmits that data in the
(unimpaired) downlink. The mobile station receives the data and is
instructed to loop it back in the (possibly impaired) uplink. The BTS
receives that uplink, puts in in RTP frames which end up being received
back by this very tool. By correlating the received RTP with the PRBS
sequence, this tool can compute the BER (Bit Error Rate) of the
(possibly impaired) uplink. Doing this with different RF channel model
simulators in the uplink allows to establish BER at different levels and
Original code by Sylvain Munaut extended with some comments and Automake
integration by Harald Welte.
oml.c: In function ‘bts_model_apply_oml’:
oml.c:1814:17: error: variable ‘cell_size’ set but not used [-Werror=unused-but-set-variable]
1814 | uint8_t cell_size;
This default phase of the Codec Mode Indication in downlink direction is
called "odd", which is defined by starting with CMC in every 26
At call set-up, after every successful handover and after a channel mode
modify, the default phase (odd) shall be used in downlink direction.
During a call, the phase of Codec Mode Indication may be changed in
downlink by using a RATSCCH message.
As we don't implement RATSCCH, odd is always correct.
oml.c: In function ‘bts_model_opstart’:
oml.c:1883:32: warning: variable ‘ts’ set but not used [-Wunused-but-set-variable]
1883 | struct gsm_bts_trx_ts *ts;
l1_if.c: In function ‘activate_rf_compl_cb’:
l1_if.c:1280:17: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
1280 | if (bts_lc15->led_ctrl_mode == LC15_LED_CONTROL_BTS)
In file included from ../../include/osmo-bts/dtx_dl_amr_fsm.h:3,
l1_if.c:1282:25: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
1282 | osmo_fsm_inst_dispatch(trx->mo.fi, NM_EV_DISABLE, NULL);
In some environments it is highly desirable for the RTP stream
coming from each GSM call UL on a BTS to be fully continuous,
without any gaps, with _some_ RTP packet emitted every 20 ms,
even if there is no speech or SID frame to be sent in that frame
time window. The present change adds an rtp continuous-streaming
vty option which, when enabled, causes the BTS to emit RTP packets
with a zero-length payload, instead of producing gaps in the RTP
stream, when it has nothing else to send.
Handling of SID in EFR mode was broken in osmo-bts-sysmo.
l1_to_rtppayload_efr(), the function for UL Rx, was using completely
bogus logic (passing bits in ETSI TS 101 318 EFR format to an AMR
decoding function), whereas l1if_tch_encode(), the function for
DL Tx, had missing SID logic for EFR while supporting SID detection
for all other codecs. The fix is to use the new osmo_efr_check_sid()
function in libosmocodec.
The TCH/F Rx code in osmo-bts-trx uses osmo_fr_check_sid() to detect
when the MS sends SID, and passes the flag to lchan_set_marker().
However, equivalent logic was missing for EFR, as until recently
there was no EFR SID check function in libosmocodec. Now that
we have osmo_efr_check_sid(), use it.
When we receive a SID_FIRST_P1 frame from the PHY (during AMR/HR DTXu),
we must generate a SID frame on the RTP side.
The existing code
* ignored that the Amr_SidFirstP1 PHYIF message actually contains the
* manually generated the same content using osmo_amr_rtp_enc()
* forgot to prefix that with the AMR CMR+TOC
* in the end, sent a completely broken (too short) AMR SID frame over RTP
Let's fix this by simply using the 7-byte RTP payload with CMR+TOC that
the PHY is providing to us.
So far, we've had LOGPLCHAN() and LOGPFN(). This resulted in a number
of log lines containing frame numbers *not* containing the lchan
context, which makes it difficult to deterine which of potentially many
concurrently active lchans is logging.
Let's introduce LOGPLCFN() for a FN-extended version of LOGPLCHAN(),
and convert all callers that have the related context.
We're printing DEBUG messages for all other DTX frames, but not for
ONSET. This made me think that we never received any ONSET frames
when looking at log output.
Let's add ONSET for completeness.
ph_tch_req() is a recursive function and conditionally calls itself at
the very bottom. The recursive call happens iff all of the following
conditions are met:
* DTXd is enabled,
* AMR codec is in use,
* DTX DL AMR FSM state is recursive.
The problem is that ph_tch_req() may pull sizeof(*lsap) from the given
msgb twice: during the initial and the recursive calls. The second
attempt to pull sizeof(*lsap) causes the process to abort, because
the remaining room is less than it's attempting to pull.
AFAICT, doing msgb_pull() is not really necessary, given that
l1sap_tch_rts_ind() thankfully does set msg->l2h before pushing
the lsap header in front of the actual frame.
Update osmo-bts-sysmo and its copy-pasted siblings, which are likely
affected too, except osmo-bts-octphy which does not do the recursion.
It makes no sense to push interference meas results for those TRX since
they are disabled, unused and hence won't be reported in RSL RF Res Ind.
The timeslot carrying BCCH/CCCH on C0 is a bit special in a way that
it's being activated implicitly - there is no explicit RSL CHANnel
ACTIVation for that. This is why we have TRX_CHAN_FLAG_AUTO_ACTIVE,
which marks sub-channels of BCCH/CCCH in the trx_chan_desc.
The upcoming patch changes the burst buffer allocation strategy, so
that the memory is allocated on channel activation and then free()d
on channel release. This patch facilitates that by making the
activation/deactivation logic consistent for all sub-channels.
The header file <osmocom/gprs/protocol/gsm_04_60.h> was recently
deprecated and moved to <osmocom/gsm/protocol/gsm_44_060.h>, so
it's now part of libosmogsn and depending libosmogb is not needed.
Related: libosmocore.git I70cc21bf25a7081070738abacb409ed19094c3b2
The code in that function is pretty rotten:
* osmo_fd_write_disable() is called for each message in the queue,
there's no need for that. Let's simply call it at the end if the queue
* Asserting for obvious stuff like dequeue returning the first entry in
* Having error code path for empty message: That shouldn't happen, abort
With all thse changes, the function is way simpler, easy to read and
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
These two messages indicate that no ACK/NACK message is going to be
sent to the BSC because activation/deactivation was requested by the
PCU. This is absolutely normal and requires no attention from the
user/operator, so better use LOGL_INFO.
Parse the RTP CSD Format and reply with NACK if the mode is not
RSL_IPAC_RTP_CSD_TRAU_BTS, which is the only one we plan to implement
Add documentation for rsl_ipac_rtp_csd_format_d/_ir from
libosmocore.git, include/osmocom/gsm/protocol/gsm_08_58.h and
Forwarding of PDCH related data over multicast works for me.
Without these features osmo-bsc would reject the OML connection
if it's configured with [E]GPRS enabled.
osmo-pcu requires to get DATA.ind for all FN/TS it manages in order to
tick its internal FN clock and trigger timeouts. Without this, some
events are ticked in a delay fashion when osmo-pcu detects FN jumps.
Differentiate in each TRX between being provisioned (configuration available) and being provisioned *plus enabled*.
TRX0 waits for all other TRX to be ready before sending POWERON, since
all TRX need to have been minimally configured over TRXC before POWERON
is called. This "ready" state though, doesn't necessarily mean the
TRX!=0 are enabled (aka NM Enabled and rf_locked=0). With them being
configured it es enough to start the whole PHY.
With the old logic, given any TRX was rf_locked=1 at startup, the PHY
would not become UP because it the TRX_PROV FSM was waiting for OPSTART
to arrive on all TRX, which wouldn't happen on TRX that had rf_locked=1.
So in summary, the desired requirements to start the PHY are (in any
1- Wait all TRX are configured
2- Wait for TRX0 OPSTART