Themyscira Wireless RTP Extensions¶

When ETSI developed GSM and defined all of the interfaces between different network elements, they created a beautiful design that assumes TDM transport throughout - see TRAU page. Each call leg is carried in a 16 kbit/s (TCH/F) or 8 kbit/s (TCH/H) sub-timeslot between the BTS and the TRAU, using special frame formats called TRAU frames. GSM 08.60 (TCH/F) and GSM 08.61 (TCH/H) define the format of these TRAU frames for both uplink and downlink: the two formats are distinct and carry different functional semantics. TRAU-DL frames are semantically simple (each frame position must be filled with either a good speech frame or a valid SID frame, no other possibilities allowed), but TRAU-UL frames are more complex. In the uplink direction, each frame position may contain either a well-received frame or a frame that was received with errors, and the transport format needs to preserve these nuances. Toward this end, TRAU-UL frame format defined in GSM 08.60 and 08.61 includes a rich set of metadata flags, indicating reception status and alignment position of each frame.

Unfortunately when the industry moved to implementing GSM over IP transport, all of this beauty was lost. RTP payload formats that were adopted as general industry standard (ETSI TS 101 318, RFC 3551, RFC 5993) were never designed for the purpose of software-based reimplementation of GSM over IP - instead they were designed for non-GSM applications with completely different requirements - yet the GSM-over-IP industry quietly adopted them while 3GPP stood by and did nothing. By the time 3GPP got around to standardizing AoverIP, it was too little too late, and the only thing they did for voice user plane was a codification of already existing industry practices (namely the use of RFC 3551 and 5993), without doing anything to fix the flaws inherent in that approach, effectively giving their seal of approval to the slew of functional regressions relative to TDM-GSM TRAU-UL frame format.

Themyscira Wireless, a small GSM retronetworking collective operating near USA-Mexico border, decided to take the matter into our own hands and fix this architectural bug in IP-based GSM. We produced our own series of specifications written in the same style as 3GPP specs for GSM, promulgated under the authority of the Presiding Sisterhood of the Women's Republic of Themyscira, that define enhanced RTP transport formats for use in IP-based GSM RAN and the procedures for invoking the use of these enhanced RTP formats. The following sections list all currently defined specs.

TW-TS-001¶

Enhanced RTP transport of FR and EFR codec frames in an IP-based GSM RAN

Specification document

This spec defines an extended RTP payload format that serves as an enhancement over RFC 3551 formats for FR and EFR. Compared to the basic format of the latter spec, the extended format prepends an extra header octet, called TRAU-like Extension Header (TEH) - this extra header octet carries metadata flags that semantically correspond to GSM 08.60 TRAU-UL.

The idea of prepending an extra header octet to the existing standard payload format was inspired by the relation between TS 101 318 and RFC 5993 formats for HR codec.

TW-TS-002¶

Enhanced RTP transport of HRv1 codec frames in an IP-based GSM RAN

Specification document

This spec relates to TW-TS-001 the way GSM 08.61 relates to GSM 08.60 - it is the half-rate counterpart. The approach taken here is that RFC 5993 format is extended with additional frame types, restoring functionality equivalent to TRAU-UL frames of GSM 08.61 (particularly the 8 kbit/s variant used in TFO); some out-of-band flags are also inserted into bit positions that were previously reserved.

TW-TS-003¶

BSSMAP extension for selection of enhanced RTP transport formats

Specification document

This spec defines an extension IE that can be added to the ASSIGNMENT REQUEST message in BSSMAP to request the use of TW-TS-001 and/or TW-TS-002: a request from the CN that wishes to use these RTP extensions to Osmocom BSS.

TW-TM-004¶

Description of RSL_IE_OSMO_RTP_EXTENSIONS defined in Osmocom Abis

Document link

This document is a Technical Memorandum (TM) and does not carry the normative power of a Themyscira Wireless Technical Specification (TW-TS). It came about as follows:

• Because RTP extensions of TW-TS-001 and TW-TS-002 need to originate at the BTS, signaling extension on BSSMAP between the CN and the BSS (TW-TS-003) was not sufficient - a signaling extension was also needed in Abis RSL.
• Unlike AoIP, the flavor of Abis used in Osmocom is essentially an Osmocom-owned private interface.
• Having a TW-TS for an interface that is owned and maintained by Osmocom rather than Themyscira would not make good standards process. However, because Themyscira currently has better technical writing and documentation resources than Osmocom, the documentation method that ended up being chosen was to produce an informal Technical Memorandum as TW-TM-004.