Attention is currently required from: pespin, dexter.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32714 )
Change subject: TCH DL, FR & EFR: reshape SIDs per 06.31/06.81 section 5.1.2
......................................................................
Patch Set 3:
(5 comments)
Commit Message:
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/b5cc6710_3f11d6ed
PS2, Line 8:
> I will cover this topic in proper detail in June OsmoDevCall, but here is a shorter version: the pro […]
The new patchset has a reworded commit message - please review.
File include/osmo-bts/lchan.h:
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/dc80b0a5_b2a1be97
PS2, Line 281: } nonamr;
> I'll go with dexter's suggestion of dtx_fr_efr for the new substruct, plus renaming the old dtx subs […]
Done
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/fd4eefc1_b94817c8
PS2, Line 282: uint8_t last_cmr;
> dexter's comment is correct - the last_cmr member is in the larger tch substruct, not in either of t […]
Done
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/178637d9_25ae4dc5
PS2, Line 1315: if (lchan->type == GSM_LCHAN_TCH_F)
> I'll change this code to use nested switch statements for lchan->type and lchan->nr in the next vers […]
Done
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/7a1659ad_24dea7cc
PS2, Line 1334: bool is_nonamr_sid = false;
> Will do.
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32714
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5
Gerrit-Change-Number: 32714
Gerrit-PatchSet: 3
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: dexter <pmaier(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 15 May 2023 19:38:35 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: falconia <falcon(a)freecalypso.org>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: pespin, dexter.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-bts/+/32714
to look at the new patch set (#3).
Change subject: TCH DL, FR & EFR: reshape SIDs per 06.31/06.81 section 5.1.2
......................................................................
TCH DL, FR & EFR: reshape SIDs per 06.31/06.81 section 5.1.2
Section 5.1.2 of GSM 06.31 & 06.81 (DTX specs for FR & EFR) 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, 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/EFR (and in the future HR1 too)
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
---
M include/osmo-bts/lchan.h
M src/common/l1sap.c
2 files changed, 163 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/14/32714/3
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32714
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5
Gerrit-Change-Number: 32714
Gerrit-PatchSet: 3
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: dexter <pmaier(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Attention is currently required from: jolly, pespin.
dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/32694 )
Change subject: gprs_rlcmac: also use direct TLLI PCUIF for paging MAC blocks
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
> yes thinking of it, I think only the ImmAss sent over PCH need to be confirmed, I see no reason to c […]
Thanks for making that clear. To be honest I also do not see a why pagings should be confirmed. From the BSS perspective it is a fire and forget message and who knows when the MS decides to perform the channel request...
--
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/32694
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: I99cfe373fa157cfb32b74c113ad9935347653a71
Gerrit-Change-Number: 32694
Gerrit-PatchSet: 2
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 15 May 2023 19:16:06 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: pespin, dexter.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32714 )
Change subject: TCH DL, FR & EFR: reshape SIDs per 06.31/06.81 section 5.1.2
......................................................................
Patch Set 2:
(5 comments)
Commit Message:
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/50aa15b3_aeb9bb59
PS2, Line 8:
> It might be helpful to mention DTX to make more clear what this is about. […]
I will cover this topic in proper detail in June OsmoDevCall, but here is a shorter version: the problem being solved here is one of TrFO rather than DTX. DTX is defined and enabled/disabled separately for UL and DL directions; DTXu is always allowed and almost always desired, but DTXd is only possible if you have a cell with more than just C0. The problem is TrFO: what do we do when the RTP output of call leg A (which has DTXu enabled) goes to the RTP input of call leg B, which does not have DTXd? (Right now no OsmoBTS model has correctly working DTXd for non-AMR, but this lack of support is a separate problem, and a low-priority one because it matters only for users with lots of spectrum and multi-TRX hw.)
The scenario where a BTS receives DTX SIDs in its RTP input but does not do physical DTXd on the radio DL was not envisioned at all in any of the non-AMR DTX specs (not FR, not HR, not EFR), hence we have to improvise. My solution is to effect a kind of fake DTXd: in those frame positions where real DTXd would transmit nothing at all (physical Tx off), transmit something that would cause a BFI condition in the GSM MS receiver. It just so happens that all of our BTS models already transmit such induced-BFI conditions when fed a zero-length payload: osmo-bts-trx sends dummy FACCH, whereas sysmoBTS PHY appears to invert the CRC3 bits of GSM 05.03 section 3.1.2.1.
I should also note that in the case of FR1 and HR1 codecs this fake DTXd approach is not the only feasible one - the alternative would be to implement the rules of TS 28.062 section C.3.2.1.1 - these rules are written for in-band TFO, but can be applied just as well to TrFO. However, implementing those rules seems infeasible (or at least inordinately difficult) for EFR, leaving fake DTXd as the only feasible approach. And if we have to do fake DTXd for EFR, why not do it for all 3 classic non-AMR codecs?
I shall give your comment some thought - how to reflect in the commit message and code comments that we are dealing with DTX SIDs going to a BTS that may not have DTXd. Although when and if we do implement real DTXd for non-AMR, the same logic will apply there, so at least there's that.
File include/osmo-bts/lchan.h:
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/c05516a5_b76b3372
PS2, Line 281: } nonamr;
> I would rename it to fr_efr too. […]
I'll go with dexter's suggestion of dtx_fr_efr for the new substruct, plus renaming the old dtx substruct to dtx_amr.
I should also mention that the correct non-AMR DTX logic for HR1 is almost exactly the same as for FR & EFR, hence when and if someone extends my FR/EFR logic to also cover HR1, the same substruct will likely be used. Why am I not fully covering HR1 from the get-go? In addition to OS#5688, there are some extra difficulties with HR1 which I shall cover in my OsmoDevCall presentation in June.
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/6f50022c_aa1a8ff2
PS2, Line 282: uint8_t last_cmr;
> Its a sub struct "tch", so the location should be fine.
dexter's comment is correct - the last_cmr member is in the larger tch substruct, not in either of the two DTX substructs.
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/ea5453be_7dfff7d4
PS2, Line 1315: if (lchan->type == GSM_LCHAN_TCH_F)
> "switch (lchan->type)" should make this function less cryptic imho.
I'll change this code to use nested switch statements for lchan->type and lchan->nr in the next version.
https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/260dd889_584055bc
PS2, Line 1334: bool is_nonamr_sid = false;
> better rename this to is_fr_efr_sid as well.
Will do.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32714
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5
Gerrit-Change-Number: 32714
Gerrit-PatchSet: 2
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: dexter <pmaier(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 15 May 2023 18:10:45 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: laforge, pespin.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32110 )
Change subject: common+trx: make uplink ECU optional
......................................................................
Patch Set 4:
(1 comment)
File src/common/vty.c:
https://gerrit.osmocom.org/c/osmo-bts/+/32110/comment/9d296871_a24c8ff9
PS4, Line 809: bts->suppress_ul_ecu = false;
> I find it weird that you are kinda changing the boolean logic with the VTY command when using the va […]
I wrote the code the way I did so that the default of having this UL ECU enabled would happen on its own through zero-init of struct gsm_bts. But I agree that an affirmative boolean such as use_ul_ecu will be much better, and I just found the right place to set the backward-compatible default in bts_init(). I will spin a new patchset.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32110
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e
Gerrit-Change-Number: 32110
Gerrit-PatchSet: 4
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 15 May 2023 17:18:53 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: laforge, pespin, msuraev.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/31672 )
Change subject: osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()
......................................................................
Patch Set 5:
(1 comment)
This change is ready for review.
Commit Message:
https://gerrit.osmocom.org/c/osmo-bts/+/31672/comment/1738aa92_564e3011
PS4, Line 14: o that we can dynamically choose
: buffer size depending on the channel mode (speech/data).
> I don't know if this is really an advantage. […]
I changed the patch to allocate the maximum size (4 8-PSK modulated bursts) regardless of the lchan type being activated. In a follow-up patch the allocation size is further increased to hold up to 22 GMSK modulated bursts.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/31672
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I6a5f76023fc492786076a63016f81285b3576c33
Gerrit-Change-Number: 31672
Gerrit-PatchSet: 5
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: msuraev <msuraev(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: msuraev <msuraev(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 15 May 2023 17:07:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
Attention is currently required from: laforge, dexter.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/32685 )
Change subject: codec: replace GSM-FR ECU with new implementation
......................................................................
Patch Set 3:
(1 comment)
File include/osmocom/codec/ecu.h:
https://gerrit.osmocom.org/c/libosmocore/+/32685/comment/248ff8b3_6259a5db
PS3, Line 9: /* ECU state for GSM-FR - deprecated version only! */
> It is not so clear why we keep this. […]
The old implementation _with its state structure_ is a public API of its own, predating the abstracted ECU API, and at least gapk still uses that old, officially deprecated API - and "uses" not only in the sense of calling the old functions, but gapk code actually digs inside that struct osmo_ecu_fr_state!
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/32685
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I0200e423ca6165c1313ec9a4effc3f3047f5f032
Gerrit-Change-Number: 32685
Gerrit-PatchSet: 3
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 15 May 2023 16:47:32 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: comment