falconia has uploaded this change for review. (
https://gerrit.osmocom.org/c/osmo-bts/+/37647?usp=email )
Change subject: sysmo: generate empty TCH/H payload on FACCH/H Rx
......................................................................
sysmo: generate empty TCH/H payload on FACCH/H Rx
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
---
M src/osmo-bts-sysmo/l1_if.c
1 file changed, 35 insertions(+), 16 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/47/37647/1
diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c
index 9ca1c32..aa4a739 100644
--- a/src/osmo-bts-sysmo/l1_if.c
+++ b/src/osmo-bts-sysmo/l1_if.c
@@ -987,23 +987,28 @@
return rc;
}
- /* If we got FACCH, the RTP clock needs to account for it,
- * and if we have rtp continuous-streaming enabled,
- * an actual BFI packet will be emitted.
+ /* When TCH UL receiver in sysmoBTS PHY detects FACCH,
+ * it behaves as follows (observed):
*
- * Only the case of TCH/F is currently handled; the task of
- * supporting TCH/H is left as a FIXME for other/later
- * developers. The difficulty with supporting FACCH/H is that
- * only one GsmL1_Sapi_FacchH message will be received,
- * covering 40 ms of time, but two RTP "tick" output calls
- * will need to be made, with appropriately adjusted frame
- * numbers. As a further consideration for rtp continuous-streaming
- * mode, having the two RTP BFI packets sent directly back to back,
- * as opposed to proper 20 ms timing, may be so undesirable
- * that some deployments may rather disable TCH/H (use only TCH/F)
- * than deal with the extra pain, or use TCH/H only on SDR-based
- * BTS with osmo-bts-trx where correct timing is easily achieved. */
- if (data_ind->sapi == GsmL1_Sapi_FacchF)
+ * - In each 20 ms window (both TCH/F and TCH/H), a single
+ * PH-DATA.ind arrives.
+ * - In the case of TCH/F, this PH-DATA.ind carries GsmL1_Sapi_FacchF
+ * instead of GsmL1_Sapi_TchF.
+ * - In the case of TCH/H, the PH-DATA.ind for block 0 carries
+ * GsmL1_Sapi_FacchH instead of GsmL1_Sapi_TchH. However,
+ * in the following 20 ms window (block 1 of FACCH/H)
+ * a PH-DATA.ind with GsmL1_Sapi_TchH arrives as normal.
+ * Typically the latter PHY message carries a BFI (0 length payload),
+ * but nonzero payloads have also been observed under some conditions.
+ * (The latter case remains to be investigated further.)
+ *
+ * In those 20 ms windows where we receive PH-DATA.ind for FACCH
+ * instead of the usual TCH kind, we need to pass an empty payload
+ * to the upper layers so we can produce the correct effect in
+ * the outgoing RTP stream depending on configuration.
+ */
+ if (data_ind->sapi == GsmL1_Sapi_FacchF ||
+ data_ind->sapi == GsmL1_Sapi_FacchH)
l1if_tch_rx_facch(trx, chan_nr, l1p_msg);
/* fill L1SAP header */
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/37647?usp=email
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Id6d966348fb2be084485279e75480f98f46e464b
Gerrit-Change-Number: 37647
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <[email protected]>
Gerrit-MessageType: newchange
