mirror of
https://gitea.osmocom.org/cellular-infrastructure/osmo-bts.git
synced 2025-10-23 08:22:10 +00:00
TCH UL path: add out-of-band BFI flag
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
This commit is contained in:
@@ -13,21 +13,38 @@
|
||||
|
||||
struct msgb;
|
||||
|
||||
/* Access 1st part of msgb control buffer */
|
||||
/****************************************************************
|
||||
* Accessor macros for control buffer words in RTP input path (DL)
|
||||
*****************************************************************/
|
||||
|
||||
/* Storing RTP header fields in the path from RTP and Osmux
|
||||
* Rx callback functions to TCH-RTS.ind handling.
|
||||
* FIXME: do we really need this RTP header info downstream
|
||||
* of the jitter buffer mechanism in the RTP endpoint library?
|
||||
*/
|
||||
#define rtpmsg_marker_bit(x) ((x)->cb[0])
|
||||
#define rtpmsg_seq(x) ((x)->cb[1])
|
||||
#define rtpmsg_ts(x) ((x)->cb[2])
|
||||
|
||||
/* Access 2nd part of msgb control buffer */
|
||||
#define rtpmsg_seq(x) ((x)->cb[1])
|
||||
|
||||
/* Access 3rd part of msgb control buffer */
|
||||
#define rtpmsg_ts(x) ((x)->cb[2])
|
||||
|
||||
/* Access 4th part of msgb control buffer */
|
||||
/* l1sap_rtp_rx_cb() does some preening or preparsing on some
|
||||
* RTP payloads, and in two cases (HR with RFC 5993 input and
|
||||
* CSD NT modes) this preparsing step produces some metadata
|
||||
* that need to be passed to TCH-RTS.ind handling.
|
||||
*/
|
||||
#define rtpmsg_is_rfc5993_sid(x) ((x)->cb[3])
|
||||
|
||||
/* Access 5th part of msgb control buffer */
|
||||
#define rtpmsg_csd_align_bits(x) ((x)->cb[4])
|
||||
|
||||
/********************************************************
|
||||
* Accessor macros for control buffer words in TCH UL path
|
||||
*********************************************************/
|
||||
|
||||
/* We provide an ability for BTS models to indicate BFI along with payload
|
||||
* bits just like in GSM 08.60 TRAU-UL frames, and the same BFI flag can
|
||||
* then be set by model-independent functions for higher-level BFI
|
||||
* conditions. This cb word shall act as a Boolean flag.
|
||||
*/
|
||||
#define tch_ul_msg_bfi(x) ((x)->cb[0])
|
||||
|
||||
/**
|
||||
* Classification of OML message. ETSI for plain GSM 12.21
|
||||
* messages and IPA/Osmo for manufacturer messages.
|
||||
|
Reference in New Issue
Block a user