Feature #6448
openSupport Themyscira RTP extensions in Osmocom BSS
0%
Description
As discussed in OsmoDevCall 2023-06-21, the industry transition from TDM transport per TS 48.060 & 48.061 to RTP transport in the standard formats of RFC 3551 or TS 101 318 (same format defined in both specs) has brought on a functional regression: there are metadata bits present in 48.060/48.061 UL frame formats that have been dropped in the standard RTP formats. Themyscira Wireless is seeking to recreate the classic GSM architecture in its full glory, but do so under the constraint of economic realities that only allow IP transport between physically distant network elements. In order to implement a network edge transcoder that logically and semantically functions like a classic GSM TRAU (of MSC-colocated variety) despite physically being nothing more than ordinary Unix/Linux processes running on a rented server with only IP connectivity, we had to invent our own non-standard extensions to RTP payload formats for transport within a GSM RAN. TW-TS-001 and TW-TS-002 are formal specifications for Themyscira RTP extensions, corresponding to TS 48.060 and 48.061, respectively:
https://www.freecalypso.org/specs/tw-ts-001-v010100.txt
https://www.freecalypso.org/specs/tw-ts-002-v010100.txt
However, 3GPP TS 48.103 (the spec for AoIP user plane) says indirectly (by referencing 26.102) that RTP payload formats at the AoIP interface shall be those of RFC 3551 (FR & EFR) and RFC 5993 (HR). Therefore, if a given network needs to pass TW-TS-001 & TW-TS-002 payloads instead across that interface, it will be in direct violation of TS 48.103. But what if a given CN implementation really needs these Themyscira RTP extensions? Themyscira government's official answer is an extension to BSSMAP by which the MSC asks the BSS to use the RTP formats in question and thereby deviate from 48.103, codified here:
https://www.freecalypso.org/specs/tw-ts-003-v010001.txt
Now bringing this matter to Osmocom: my current vision (as Themyscira HPS of telecom) is that the AoIP interface shall serve as the boundary between Osmocom-controlled and Themyscira-controlled network elements. On the CN side we'll be implementing our own MSC (based on OsmoMSC, but with changes so big that a merge doesn't seem likely), but for the 3 Osmocom BSS sw components (OsmoBSC, OsmoBSC-associated OsmoMGW and OsmoBTS), I am hoping to be able to continue using Osmocom mainline, if we can merge the small changes required for Themyscira RTP extensions.
In order to add support for Themyscira RTP extensions to Osmocom BSS, there will need to be signaling at both AoIP and Abis-IP interfaces negotiating the use of these non-standard extensions, with the requestor at each interface asking for the extension to be used and the respondent acknowledging or failing to acknowledge that request. At the AoIP interface the signaling extension is codified in TW-TS-003, but its counterpart for Abis-IP will need to be defined entirely in Osmocom, given that Abis-IP as it currently exists is inherently an Osmocom-specific interface altogether.
Here are current Gerrit patches implementing the initial parts of this feature proposal, namely signaling interface definitions:
https://gerrit.osmocom.org/c/libosmocore/+/36669
https://gerrit.osmocom.org/c/libosmocore/+/36704
https://gerrit.osmocom.org/c/libosmocore/+/36705
https://gerrit.osmocom.org/c/osmo-bts/+/36706
Checklist
- add TW-TS-003 definition to libosmocore gsm0808
- define Osmocom Abis-IP extensions for signaling the use of Themyscira RTP formats
- implement the necessary support in OsmoBSC
- implement the necessary support in OsmoBTS
Updated by falconia 11 days ago
As noted in the initial ticket, implementation of this feature will require defining a mechanism whereby OsmoBSC can test whether or not a given IP BTS supports Themyscira RTP extensions, and can ask the BTS to use these enhanced RTP payload formats if the CN asked for them via TW-TS-003 BSSMAP extension. In furtherance of this goal, I propose the following extensions to Osmocom-controlled Abis-IP interface:
- BTS feature flags indicating support for TW-TS-001 and TW-TS-002, one flag for each.
- An Osmocom-specific IE in Abis RSL, to be added to CRCX and MDCX command messages, directing the BTS to use specific RTP extensions.
Here are libosmocore patches implementing parts 1 and 2 of the above proposal:
https://gerrit.osmocom.org/c/libosmocore/+/36704
https://gerrit.osmocom.org/c/libosmocore/+/36705
plus this patch to the Abis document:
https://gerrit.osmocom.org/c/osmo-bts/+/36706
I have marked them as WIP in Gerrit so that the principal idea can be discussed in the present ticket, before delving down into line-by-line code review of the final implementation.
One question has come up in Gerrit review of the Abis document patch, before it was changed to WIP: should this new IE be defined as having TV or TLV format? From my PoV, I say that TV would be more efficient: the ultimate origin of the request to use Themyscira RTP formats is the CN, which asks the BSS to use these RTP formats via TW-TS-003 BSSMAP extension. OsmoBSC will do little more than pass this special request along from the A interface to the BTS (Abis RSL), hence it makes logical sense for the new IE on Abis RSL to mimic the one on the A interface - and that one is defined as a TV-format IE in TW-TS-003. However, it would be entirely reasonable for other Osmocom developers to argue that the new IE on Abis RSL should be a TLV so that it can be extended later to do other functions that aren't related to TW-TS-003 per se. Hence the present discussion - which should it be?
Updated by pespin 11 days ago
falconia thanks. I'd like to have the full patchset in gerrit implementing all the bits here and there before merging stuff (even if some patches depending on libosmocore changes still fail when running in jenkins gerrit verification).
Then once we are fine with the full patchset, merge them together.
Updated by falconia 11 days ago
In Gerrit review of the existing introductory patches (adding definitions of new IEs on A and Abis interfaces), laforge and pespin indicated that new IEs shall be in TLV coding format, not TV. This ruling conflicts with the original instruction of TW-TS-003 spec - however, because that spec is still very new and open to revision, I have issued a new revision of the spec that conforms to the will of Osmocom in this regard:
Updated by falconia 10 days ago
pespin wrote in #note-2:
falconia thanks. I'd like to have the full patchset in gerrit implementing all the bits here and there before merging stuff (even if some patches depending on libosmocore changes still fail when running in jenkins gerrit verification).
Then once we are fine with the full patchset, merge them together.
Ack. Looking at my current work queue, for the next few days I will probably be busy putting together the next release of ThemWi GSM codec libraries and utilities package, but then I'll switch gears to putting together the necessary test rig that will enable me to develop and test the patches to OsmoBSC and OsmoBTS for the present issue. In the meantime, this branch will facilitate builds of components that depend on libosmocore patches:
