In speech TCH operation, there will always be times when a speech frame
needs to be transmitted on the downlink, but there is no frame available
to transmit (gap in the incoming RTP stream), or the logic of DTXd says
that no frame shall be transmitted at this FN, but we are not doing
physical DTXd. Previous osmo-bts-trx code sent dummy FACCH during such
conditions, but this approach is bad for TCH/HS where we would like to
transmit good speech frames or speech frame gaps one 20 ms frame at a
time, rather than take out pairs of frames for dummy FACCH/H. Other
BTS models (sysmoBTS PHY) send out invalid speech blocks with inverted
CRC3 under the conditions in question - do the same in osmo-bts-trx.
The present change modifies osmo-bts-trx TCH DL frame gap behavior
only for TCH/FS, TCH/HS and TCH/EFS; for all other channel modes,
including AMR speech, the previous behavior of sending dummy FACCH
is left unchanged.
Depends: Iade3310e16b906efb6892d28f474a0d15204e861 (libosmocore)
Change-Id: I78106802a0aa4af39859c75d29fe0e77037899fe
Suppose we receive RTP from the uplink of another BTS, and the
UL-handling BTS has channel-decoded an HR1 frame which it deems
(per GSM 06.41 section 6.1.1) to be a valid SID, even though it is
not a perfect, error-free SID. How will this SID frame be
represented in RFC 5993 transport? My reading of the RFC tells me
that the UL-handling BTS will need to apply an operation like our
osmo_hr_sid_reset() to the payload before sending it out in RTP -
but because the text of the RFC does not explicitly address this
scenario, others may have interpreted it differently.
If we receive an RFC 5993 RTP payload in which FT is set to 2,
indicating good SID, but the actual HR payload is not a perfect SID
(the SID field is not all 1s), the only reasonable interpretation
of such occurrence is that the sender of this payload was another
BTS whose implementors interpreted the RFC as not requiring them
to rejuvenate the SID codeword prior to RTP output. Therefore, let's
treat such payloads as valid SID for our DTXd logic, and rejuvenate
the SID codeword ourselves.
Change-Id: Ife00de6220a8ca7cc180a61734497f1acb7f5b83
osmo-bts-trx always accepted (and previously required) HR1 codec RTP
input in RFC 5993 format; currently we accept this RTP format as
input for all BTS models, but no longer require it. However, we
have never applied any checks to this format's ToC header, even
when we previously required it in osmo-bts-trx. Check this header
and reject invalid payloads that just happen to have the same octet
length as valid ones.
Change-Id: If16d38641913bb46bcd7cc11685407ed17136bfe
GSM 06.31, 06.41 and 06.81 are the respective DTX specs for FR, HR
and EFR. In each of these specs, section 5.1.2 specifies the
expected shape of radio downlink in the presence of SIDs: one SID
frame after each talkspurt (after speech frames), and one SID frame
in every SACCH-aligned position every 480 ms (every 240 ms for HR),
or if the actual SACCH-aligned position is taken up by FACCH,
then just one SID frame as soon as possible after that FACCH -
and no transmitted SID frames in other positions.
This just-referenced spec section was written with the assumption
that it will only be applied when DTXd is enabled - however, if
the RTP stream for call leg B DL comes from call leg A UL (TrFO),
then we are going to receive SID frames in the stream intended for
our DL even when DTXd is disabled or not supported altogether.
The easiest solution is to apply FR/HR/EFR DTXd logic whenever
the incoming RTP stream contains SID frames, irrespective of physical
DTXd enable/disable state. If we apply such "logical DTXd" when
physical DTXd is disabled, the BTS model PHY will end up transmitting
induced BFIs (dummy FACCH or inverted CRC3) in those frame positions
where the "logical DTXd" function says "please transmit nothing".
The point remains, however, that the prescribed SID shape on the
radio downlink (expected positions of SID frames) won't happen on its
own: in the case of TrFO, whichever SID frames are present will be
in wrong positions for leg B DL, and even in the case of transcoded
calls the responsibility for DL SID shaping cannot be placed on the
RTP stream source because that source won't know where SACCH alignment
will lie. Therefore, the necessary DL SID reshaping has to be done
in the RTP stream receiver in OsmoBTS.
Related: OS#5996
Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5
There is no more need to access the UL/DL buffers via pointer to pointer
thanks to the previous patch [1] moving the memory management routines
out of the logical channel specific Rx/Tx handlers.
Change-Id: Ib1e8e86ac60a7ac9b0415ef66b609eaa33443c19
Related: [1] c45e03726af8a2b46b7166b3c47bc666ba933a69
It's a lot cleaner if the Rx/Tx burst buffers are allocated and free()d
in one place rather than in each lchan handler individually. Allocate
the buffer(s) during the lchan activation, free() on deactivation.
Regardless of lchan type, allocate the maximim size of 4 * (3 * 2 * 58)
bytes, which is sufficient to store 4 8PSK modulated bursts. This way
we reduce the load on the memory allocator at the cost of memory
consumption, what should not be a big problem.
Change-Id: I6a5f76023fc492786076a63016f81285b3576c33
Depends: libosmocore.git I1c38ccc2b64ba9046bb3b1221d99cc55ec493802
Related: OS#1572
The new vty option "rtp hr-format (rfc5993|ts101318)" selects the
RTP output format to be used for HR1 codec, consistently across
all models. The default is set to match legacy behavior: ts101318
on osmo-bts-{lc15,oc2g,sysmo} and rfc5993 on osmo-bts-trx.
On models where no legacy behavior is applicable, the default is
set to rfc5993 as a forward-looking measure - see OS#6036.
Closes: OS#5688
Change-Id: I168191874a062429a57904511a1e89e3f588732e
As a preliminary step before making the RTP output format from
OsmoBTS configurable with a vty option, we need to make the internal
format consistent across all models. The "natural" output from a
"pure" GSM 05.03 channel decoder is TS 101 318, which is also the
output format of all currently supported proprietary PHYs - adopt
it as our internal format.
Related: OS#5688
Depends: I6e75ca95409b5c368e8e04d0e0aba41e0331d9e6 (libosmocore)
Change-Id: I41bce6226964975cb85aea89e4c0f9e11e4929b8
As of commit 1160cabefb, the common layer of osmo-bts accepts both
TS 101 318 and RFC 5993 formats for HR1 codec, and always passes
the more basic TS 101 318 format to the BTS model. Unfortunately,
osmo-bts-trx has model-specific code checking the payload length
that was overlooked in that patch, causing breakage. Fix that bug.
(The actual channel encoding function in libosmocoding already
accepts 14-byte payloads.)
Related: OS#5688
Fixes: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e
Change-Id: I0e251faeffb76d2604a4100c848141d239d1d86f
There exist two different RTP encoding formats for HR1 codec: one
"simple" format defined in ETSI TS 101 318, and an extended format
(adding a ToC octet) defined in IETF RFC 5993. Following the
liberal-accept clause of Postel's law, we would like to accept
both formats. Implement this feature by first converting all HR1
RTP inputs to the more basic TS 101 318 format at the point of
input preening, and then consistently using this basic format
internally.
Related: OS#5688
Depends: I13eaad366f9f68615b9e9e4a5f87396a0e9dea0f (libosmocore)
Change-Id: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e
Up until now, our approach to validating incoming RTP payloads and
dropping invalid ones has been to apply the preening function inside
l1sap_tch_rts_ind(), at the point of dequeueing from the DL input queue.
However, there are some RTP formats where we need to strip one byte
of header from the payload before passing the rest to our innards:
there is RFC 5993 for HR codec, and there also exists a non-standard
extension (rtp_traulike) that does a similar deal for FR and EFR.
Because of alignment issues, it will be more efficient (avoids memmove)
if we can do this header octet stripping before we copy the payload
into msgb - but doing so requires that we move this preening logic
to the point of RTP input before enqueueing. Make this change.
Related: OS#5688
Change-Id: I7fc99aeecba8303b56d397b8952de5eea82b301e
As detailed in OS#6033, osmo-bts-trx was emitting its own invented
packet formats to signal BFIs (bad frame indications), different
from the vty-configured ("rtp continuous-streaming" or not) BFI
signaling method implemented in l1sap and used by all other BTS models.
In the case of EFR codec, the made-up BFI format previously used by
osmo-bts-trx caused EFR operation to be broken: a spec-compliant EFR
decoder on the receiving end of the RTP stream (a network transcoder
or the MS on the other GSM call leg) would receive and decode garbage
EFR frames of 244 zero bits instead of invoking the spec-defined bad
frame handler, causing bad audio artifacts for the user. The same
situation would also happen for FR1 codec, but the application of
ECU masked this bug: with the ECU invoked in the UL output path,
the BFI emitting code for FR1 never executed.
In the case of AMR and HR1 codecs, the model-specific BFI packet
format of osmo-bts-trx is currently harmless, but:
* The extra code adds unnecessary complexity;
* BFI packet formats are inconsistent between osmo-bts-trx and
other OsmoBTS models;
* BFI format is even inconsistent within osmo-bts-trx itself, as
under certain conditions the common code in l1sap will override
the UL payload from the BTS model and emit its own form of BFI
instead.
Fix all of the above by removing trx model-specific BFI formats
for all codecs, and let l1sap handle all BFIs.
Related: OS#6033
Change-Id: I8f9fb5b8c5b2cad4b92ac693c0040779f811981a
The paging interface towards the PCU has a confusing API. In fact what
the PCU does when it wants to page or do an immediate assignment is
sending a ready formatted MAC block to the BTS. The BTS then puts this
MAC block in the paging queue and then eventually it justs sends it
without looking at the contents. For the code in paging.c it is not
imortant if the MAC block is an immediate assignment, it only cares if
the paging record contains a MAC block or paging parameters.
Related: OS#5927
Change-Id: Ifab37fdedaba98b160718113767e4ef6ee7d16ad
In all OsmoBTS models in FR and EFR speech modes, as the UL traffic
frame stream is passed from the PHY to l1sap and ultimately to RTP
output, all passed frames are checked for SID. The Boolean result
of this SID check is used in two ways:
* RFC 3551 instructs that the Marker bit in the RTP header SHOULD be
set in the first packet of a talkspurt after a period of silence
suppression. OsmoBTS implements this recommendation by setting
the Marker bit in the first RTP-transmitted non-SID UL packet
that was preceded by SID.
* In osmo-bts-trx only, this same SID check serves a second purpose:
handling of BFI conditions depends on whether or not the last received
good traffic frame was a SID. If a BFI condition is received after
a non-SID traffic frame, the ECU is invoked, and if this ECU fails
or when libosmocodec does not provide an ECU for the codec in use,
a special FR (EFR) BFI frame of 260 (244) zero bits is emitted.
Both the ECU call and the peculiar form of BFI are skipped when the
last received good traffic frame was a SID.
For both of the above purposes, in all BTS models, change the SID check
from osmo_{fr,efr}_check_sid() to osmo_{fr,efr}_is_any_sid(). The
effect of this change is that "what counts as a SID" for the just-listed
purposes changes from recognizing only perfectly uncorrupted SID frames
without any bit errors to recognizing all frames which the rules of
GSM 06.31 (FR) or 06.81 (EFR) classify as either valid or invalid SID.
Change-Id: I5c24b379deda8ae551f9924d10770da50e6acbbd
Commit 32682c63f6 fixed EFR SID handling in osmo-bts-sysmo,
but that fix was never propagated into osmo-bts-{lc15,oc2g} versions,
which are essentially copies of osmo-bts-sysmo. Fix that oversight.
Change-Id: I509c1ea374e640d819952d58592b12fa884ad9d8
Those network elements which receive a stream of codec frames that
may come from the uplink of GSM call A and which are responsible
for preparing the frame stream for the downlink of GSM call B
(such as OsmoBTS receiving RTP and feeding DL to its PHY) must be
prepared for the possibility that their incoming frame stream may
contain corrupted SID frames, presumably from bit errors on radio
link A. Per the rules of section 6.1.1 of GSM 06.31 for FR and
GSM 06.81 for EFR, SID frames with just one errored bit are still
to be accepted as valid, whereas frames with more corrupted bits
which are still recognizable as SID are classified as invalid SID.
In the case of a TrFO call, the entity switching from leg A UL to
leg B DL is responsible for *not* transmitting invalid SID frames
on the destination leg (they should be treated like BFIs), and any
deemed-valid SID frames that are forwarded should be preened,
correcting that one bit error they may exhibit. Implement this
functionality in OsmoBTS.
Change-Id: I89df2f12c49dd5378667cf149d19bde654f80134
When the NM_EV_RX_OPSTART event is received, it will call bts model
specific function bts_model_opstart(), which is responisble for
answering back with NM_EV_OPSTART_ACK or NM_EV_OPSTART_NACK.
Since that answer could be done sequentially in same callback code path,
we could end up twice at the end of the st_op_disabled_offline()
function checking for statechg (due to reentring that function).
As a result, one can see the following message appear during OML
bring up:
nm_bb_transc_fsm.c:185 NM_BBTRANSC_OP(bts0-trx0){ENABLED}: transition to state ENABLED not permitted!
Fix the issue by avoiding ending up at the end of the function in code
paths which should not be triggering any change.
The case of bbtransc is a bit different than that of rcarrier for
NM_EV_RX_SETATTR, since the former really doesn't receive any such
message from the BSC yet, so if we checked for that one before
continuing, it would never go on.
Change-Id: I5184a33dd8da9244e8aacf3ab8bb8930f732a136
The info indication on pcu_sock cann only support a limited but
sufficient number of TRXs, when we detect that we overflow the maxiumum
number of TRXs, then break and do not continue.
(this is more or less a cosmetic problem)
Change-Id: If4d7eecaded22f86750283f7aa13072064724537
The function rtppayload_is_valid() is called from the receiving RTP code
path. Lets use the word "forwarding" instead of "sending" to avoid the
impression something is sent (like sending RTP packets to the outside
world)
Change-Id: Ie7fcc53dea462b0d575b0c9ca73ba7507289eefe
This code has been there since first octphy support was added.
New gcc 13.1.1 is catching this and reporting compilation errors:
"""
/osmo-bts/src/osmo-bts-octphy/l1_oml.c: In function ‘ts_connect_as’:
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1518:60: error: ‘oc’ is used uninitialized [-Werror=uninitialized]
1518 | tOCTVC1_GSM_MSG_TRX_ACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1518:60: note: ‘oc’ was declared here
1518 | tOCTVC1_GSM_MSG_TRX_ACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c: In function ‘bts_model_ts_disconnect’:
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1803:62: error: ‘oc’ is used uninitialized [-Werror=uninitialized]
1803 | tOCTVC1_GSM_MSG_TRX_DEACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1803:62: note: ‘oc’ was declared here
1803 | tOCTVC1_GSM_MSG_TRX_DEACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
"""
Change-Id: I0da7d3a94e9eba15b8d3d3d995bba532170d9df7
osmo-bts-trx uses the RFC5993 RTP payload format, so when handling the
RTP payload use GSM_HR_BYTES_RTP_RFC5993, instead of GSM_HR_BYTES + 1
Depends: libosmocore.git I125ef9cdab98c073971841c175b1a7dcd927f9c2
Related: OS#5688
Change-Id: I54dd3adab88e2262913f7b1e89340a0246c88a8a
We should not maintain BCCH carrier power reduction mode if we loose
connection to the BSC. When entering NM_BTS_ST_OP_DISABLED_OFFLINE,
reset the related state fields if it was enabled.
Change-Id: I34468e3fccc490f48e30b159b63308a395b65fa9
Related: SYS#6435
- Add out-parameter to enable returning a NACK cause (ignored if NULL)
- Return appropriate NACK cause if TRX number is unknown (fixes OS#5967
together with change I37e6b23ed95260a8188910cf9754faffcba519c5)
Change-Id: If734ea2c8cae4c1f99b02520dffa4e3862a67745
Related: OS#5961, OS#5967
- Add out-parameter to enable returning a NACK cause (ignored if NULL)
- Return appropriate NACK cause if TRX number is unknown (part of fix
for OS#5967)
Change-Id: I37e6b23ed95260a8188910cf9754faffcba519c5
Related: OS#5961, OS#5967
The following output can be seen when doing 'show bts' in the VTY:
BTS model specific (internal) flags:
001 Measurement and Payload data combined
003 unknown 0x8
Fix this by adding the missing values to the value-string array.
Change-Id: I83e5065f9f80b4f81e9767f184c8dc027883025a
Fixes: 0277cddab "sysmo,oc2g,lc15: Make RadioChannel MO depend on RadioCarrier MO"
Fixes: ee5eb6169 "l1sap: check if BTS model supports interference reporting"
In change 8e04613e I overlooked that osmo-bts-virtual is re-using the
scheduler of osmo-bts-trx and forgot to update its OML logic. As a
result, osmo-bts-virtual is broken and does not transmit anything on
the broadcast channels.
Change-Id: I2276f7e5e4042e56ddf1fd1642c917dba0005ac4
Fixes: 8e04613e "osmo-bts-trx: properly activate [CBCH/]BCCH/CCCH"
Related: OS#6001, OS#1572
Better wait until the DSP is reset and all the information is retrieved
before telling upper layers that the phy is ready. Keep it in CONNECTING
state meanwhile.
Change-Id: Ifdc791336fb8efd42f4428893f687093085af129
The fields used to fill in pinst->version are set when info_compl_cb()
is called, which happens asynchronously and hence later than when in
bts_model_phy_link_open().
Hence, copying the values when in bts_model_phy_link_open()
(l1if_open()) makes no sense at all.
Fill in pinst->version in info_compl_cb(), just when the layer receives
the required information.
Related: OS#5978
Change-Id: Ica53a5d852214b24de7f75b08ad7e595ce5236ee
If the TRX_NR had no matching TRX it would access a NULL pointer trx
after failing to resolve it.
This commit refactors the code path to only require the trx pointer at
the very end, and NACKs the message if TRX fails to be resolved.
Change-Id: If27639ae1727fc5232e1a964a1b29f50c8805d80
All the other objects already use that one; there's no need to have a
specific one for the NM Channel FSM.
Change-Id: Ic5fd37367b500c75a0a53b1d868ba2aed3edef1b
Mychaela N. Falconia
Vadim Yanitskiy
Oliver Smith
Philipp Maier
Pau Espin