Themyscira Wireless Technical Specification TW-TS-002 Version 1.1.0 Enhanced RTP transport of HRv1 codec frames in an IP-based GSM RAN 0. Foreword This Technical Specification (TS) has been produced under the authority of the Presiding Sisterhood (government) of the Women's Republic of Themyscira as part of Themyscira Wireless technical initiative. Author: Mother Mychaela N. Falconia, High Priestess of Telecommunications As an official publication of Themyscira government, this document is not subject to copyright. 1. Scope The enhanced RTP payload format defined in this TS is applicable only to GSM-HR codec, and is intended for use only within IP-based GSM RAN, not in general- purpose IP networks or VoIP applications. More specifically, the applicability scope of this TS is the network segment extending from an IP-based BTS, or a converter from T1/E1 Abis to IP-based RAN, to the network edge transcoder, or from one IP-based BTS to another in the case of TrFO. 2. References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. [1] IETF RFC 3550, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: "RTP: A Transport Protocol for Real-Time Applications". [2] IETF RFC 3551, H. Schulzrinne, S. Casner: "RTP Profile for Audio and Video Conferences with Minimal Control". [3] ETSI TS 101 318: "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Using GSM speech codecs within ITU-T Recommendation H.323". [4] IETF RFC 5993, X. Duan, S. Wang, M. Westerlund, K. Hellwig, T. Johansson: "RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)". [5] 3GPP TS 46.020: "Half rate speech; Half rate speech transcoding". [6] 3GPP TS 46.041: "Half rate speech; Discontinuous Transmission (DTX) for half rate speech traffic channels". [7] 3GPP TS 48.061: "In-band control of remote transcoders and rate adaptors for half rate traffic channels". [8] 3GPP TS 28.062: "Inband Tandem Free Operation (TFO) of speech codecs". [9] TW-TS-001: "Enhanced RTP transport of FR and EFR codec frames in an IP-based GSM RAN". [10] TW-TS-003: "BSSMAP extension for selection of enhanced RTP transport formats". [11] 3GPP TS 48.103: "Base Station System - Media GateWay (BSS-MGW) interface; User Plane transport mechanism". [12] 3GPP TS 46.021: "Half rate speech; Substitution and muting of lost frames for half rate speech traffic channels". [13] 3GPP TS 46.022: "Half rate speech; Comfort noise aspects for half rate speech traffic channels". [14] 3GPP TS 45.003: "GSM/EDGE Channel coding". [15] 3GPP TS 46.006: "Half rate speech; ANSI-C code for the GSM half rate speech codec". 3. Definitions, conventions and abbreviations 3.1. Definitions For the purposes of the present document, the following terms and definitions apply: 3GPP-5993 payload: an RFC 5993 payload that obeys the constraints set on the use of RFC 5993 in AoIP interface. super-5993 payload: RTP payload format that is a superset of RFC 5993 as defined in chapter 5 of the present Technical Specification. octet: a group of 8 bits that functions as an indivisible elementary data unit in the context of RTP payload formats. RTP leg: an established path for RTP packet flow from a given sending entity to a given receiving entity. ToC octet: the first octet of every RFC 5993 payload as used in the context of AoIP interface. 3.2. Conventions Because the present document does not specify or refer to any kind of bit- oriented serial interface, the smallest elementary data unit of concern to the present TS is an 8-bit byte, also known as an octet. In this context the notion of bit order within an octet is meaningless, thus no bit numbering convention is used. However, a need exists to identify and refer to specific bits in an octet for the purpose of specifying encoding. The convention adopted for this TS is that individual bits within an octet shall be identified with hexadecimal masks, using the C programming language notation for hexadecimal numbers. From the most significant bit to the least significant bit in an octet, from left to right, these hexadecimal masks are: +----+----+----+----+----+----+----+----+ |0x80|0x40|0x20|0x10|0x08|0x04|0x02|0x01| +----+----+----+----+----+----+----+----+ A group of adjacent bits can be identified and referred to by combining the hexadecimal masks of individual bits with the bitwise OR function: for example, the 4 most significant bits of an octet may be collectively referred to by hexadecimal mask 0xF0. 3.3. Abbreviations For the purposes of the present document, the following abbreviations apply: BFI Bad Frame Indicator BSS Base Station System BTS Base Transceiver Station CN Core Network DL Downlink DTX Discontinuous Transmission GSM Global System for Mobile telecommunications HR Half Rate speech codec MGW Media GateWay RAN Radio Access Network RTP Real-time Transport Protocol SID SIlence Descriptor TAF Time Alignment Flag TC Transcoder TDM Time Division Multiplexing TFO Tandem-Free Operation TRAU Transcoder and Rate Adaptor Unit TrFO Transcoder-Free Operation UFI Unreliable Frame Indicator UL Uplink 4. Problem being solved The same problems that are caused by industry standard RTP payload formats for FR and EFR codecs, namely inability to indicate BFI along with data bits and inability to transport TAF, described in detail in [9], exist just the same for HR codec, and hence a solution similar to TW-TS-001 is likewise needed for HR. Furthermore, HR codec presents two additional complications which don't exist in FR & EFR, two additional aspects where the existing industry standard RTP payload formats are deficient: ternary SID indication and UFI flag. 4.1. Ternary SID indication in HR codec The HR version of ternary SID flag (GSM 06.41 section 6.1.1) poses more difficulty than its counterpart in FR and EFR. The respective DTX specs for FR and EFR define their version of ternary SID flag with strict bit counting rules, such that if this flag is lost in transport, it can be trivially recomputed downstream from frame payload bits. However, the same approach is not possible for HR: * No exact bit counting rule is prescribed, instead the choice of thresholds (an engineering trade-off) is left to the discretion of BTS manufacturers. * Because of mode-dependent (voiced vs unvoiced) bit reordering used in HR, the only practical way to implement the SID detector per the spirit of GSM 06.41 section 6.1.1 is to tightly couple it to the channel decoder block (reference [14], section 3.2) _before_ the "canonical" output in the bit order of GSM 06.20 Annex B, emitting the ternary SID flag as an out-of-band output alongside with decoded payload bits. The implication for RTP transport within IP-based RAN is that the ternary SID flag of GSM 06.41 needs to be carried as an out-of-band addendum to the regular 112-bit payload, and there needs to be a way to communicate all 3 possible states of this flag. However, neither of the two existing industry standard RTP payload formats for GSM-HR (neither TS 101 318 nor RFC 5993) is capable of indicating the invalid SID state, which will occur when the received frame is too corrupted to be accepted as a valid SID, yet the decision thresholds indicate that the MS more likely transmitted a SID than a speech frame. 4.2. UFI flag UFI is an additional flag, present only in GSM-HR but not in FR or EFR, that is passed from the channel decoder to the speech decoder, alongside with BFI, SID and TAF. The absence of this flag from industry standard RTP payload formats creates the same problem as the absence of the remaining flags that are common with FR and EFR: the flag is present in the Abis UL output of traditional T1/E1 BTSes, it is potentially useful to the speech decoder in the CN transcoder, it should be emitted in TS 28.062 TFO frames toward the outside world, but RTP transport imposes an obstacle. 5. TRAU-UL-like extensions to RFC 5993 format The two pre-existing industry standard RTP payload formats for GSM-HR are ETSI TS 101 318 and RFC 5993. Given that RFC 5993 is the format specified in 3GPP TS 48.103 for use on AoIP interface, and given that the ToC octet of RFC 5993 provides a natural place to add non-standard extensions, the latter format has been chosen as the basis for the present TS. 5.1. Common rules from TS 48.103 3GPP TS 48.103 specifies (indirectly by way of TS 26.102, which is otherwise an AMR spec) that the following rules shall be obeyed when transporting GSM-HR codec frames across AoIP interface in RFC 5993 format: * Each RTP packet carries exactly one 20 ms speech or SID frame; * Additional capabilities specified in RFC 5993, such as the ability to send multiple redundant copies of each frame, shall not be used. With these constraints, each 3GPP-5993 payload consists of exactly 15 octets: one ToC octet with F bit cleared, followed by 14 octets of raw GSM 06.20 Annex B payload. The ToC octet at the head of each 3GPP-5993 payload has the following format (reproduced from RFC 5993 Figure 3): +----+----+----+----+----+----+----+----+ Hex mask |0x80| 0x70 |0x08|0x04|0x02|0x01| +----+----+----+----+----+----+----+----+ Meaning | F | FT | R | R | R | R | +----+----+----+----+----+----+----+----+ Bit F shall always be cleared when RFC 5993 is used under the constraints set by 3GPP for AoIP interface, FT is the Frame Type field, and the 4 bits labeled R are reserved. 5.2. Additional frame types for TRAU-UL-like RTP transport RFC 5993 defines only 3 valid values for the 3-bit FT field: 0 = Good speech frame, ToC followed by 14 octets of payload 2 = Good SID frame, ToC followed by 14 octets of payload 7 = No_Data frame, ToC followed by 0 octets of payload The present TS defines two additional frame types: 1 = Invalid SID frame, ToC followed by 0 octets of payload 6 = Bad speech frame (BFI with data), ToC followed by 14 octets of payload Note that invalid SID frames (FT=1) are transported without frame payload bits, same as FT=7 No_Data frames. This design decision is justified by the fact that when a received traffic frame is deemed to be invalid SID, its bit content is never used for anything per GSM 06.41 and related GSM-HR codec specs. On the other hand, the mechanism for transporting BFI-with-data (FT=6) is useful because the bad frame handler in the reference C code [15] makes use of certain parameters from bad speech frames under certain conditions. 5.3. Additional flags passed in previously reserved bits The 4 previously reserved "R" bits of ToC octet are hereby redefined as follows: +----+----+----+----+----+----+----+----+ Hex mask |0x80| 0x70 |0x08|0x04|0x02|0x01| +----+----+----+----+----+----+----+----+ Meaning | F | FT |DTXd| R |UFI |TAF | +----+----+----+----+----+----+----+----+ The 3 new flag bits are defined as follows: DTXd: strictly identical with 16 kbit/s TRAU-UL frame bit C17 or 8 kbit/s TRAU-UL frame bit C9; UFI: strictly identical with same-named flag of GSM 06.41; TAF: strictly identical with same-named flag of GSM 06.41. 6. Enhanced RTP transport in the radio uplink direction When the local BSS is configured to use GSM-HR codec per the present TS, the following sections list the required behavior from each component. 6.1. Requirements for UL output from native IP BTS When configured to operate per the present TS, the BTS shall emit an RTP packet for every 20 ms window, whether or not a good traffic frame was received. The following RTP output shall be emitted based on the received uplink: a) If nothing at all was received (not enough bursts received to attempt running the channel decoder), or if the traffic frame position was stolen for FACCH, emit a No_Data frame (FT=7); b) If the SID detector (tightly coupled to the channel decoder) classifies the received traffic frame as a valid SID frame (per GSM 06.41 section 6.1.1), emit the valid SID as FT=2; c) If the channel decoder and its coupled SID detector classify the received traffic frame as a good speech frame (as defined in GSM 06.41), emit this frame as FT=0; d) If the SID detector classifies the received traffic frame as invalid SID (the determination is that the MS most likely transmitted SID rather than speech, but this SID was not received in a usable manner), emit a ToC-only RTP payload with FT=1; e) In all other cases (a traffic frame was channel-decoded, but it is bad and not an accepted SID frame per GSM 06.41), emit the bad bits with FT=6. If the channel decoder implementation has a UFI output, set UFI bit (mask 0x02) in the ToC octet accordingly, otherwise set this bit to 0 in RTP output. The TAF bit (mask 0x01) in the ToC octet shall always be set correctly based on the TDMA frame number to which the emitted RTP packet corresponds. 6.2. Requirements for UL conversion from T1/E1 Abis A converter from T1/E1 Abis to the enhanced RTP transport format of the present TS shall operate as follows, depending on the TRAU-UL frame format used on the Abis interface. 6.2.1. Conversion from 16 kbit/s TRAU-UL frames to super-5993 The frame type conversion algorithm shall follow this C pseudocode: if (TRAU_UL_frame_is_valid_and_well_formed) { if (BFI == 0 && SID == 0) FT = 0; else if (BFI == 0 && SID == 2) FT = 2; else if (BFI == 1 && SID == 0) FT = 6; else FT = 1; } else FT = 7; The variables in the above pseudocode are as follows: BFI input: TRAU-UL frame bit C12; SID input: TRAU-UL frame bits C13 and C14; FT output: the value to be sent in the FT field of ToC octet In all cases, DTXd, UFI and TAF bits in the ToC octet to be emitted in RTP shall be taken directly from the corresponding bits of the TRAU-UL frame. 6.2.2. Conversion from 8 kbit/s TRAU-UL frames to super-5993 FT and TAF in the super-5993 output shall be set based on TRAU-UL frame bits XC1 through XC4, as follows: XC1 XC2 XC3 XC4 Output ----------------------------- 0 0 0 0 FT=0 TAF=0 0 0 0 1 FT=2 TAF=0 0 1 0 0 FT=1 TAF=0 0 1 0 1 FT=1 TAF=1 0 1 1 0 FT=6 TAF=0 0 1 1 1 FT=6 TAF=1 ----------------------------- all others FT=7 TAF=0 (invalid per [7]) In all cases, UFI bit shall be copied directly from XC5 and DTXd bit shall be copied directly from C9. 6.2.3. Common rules for both TRAU-UL frame formats If the FT arrived at by the logic of section 6.2.1 or 6.2.2 is 0, 2 or 6, the 112 bits of frame payload shall be taken from the TRAU-UL frame and passed on in RTP. If the FT is 1 or 7, these D bits from the TRAU-UL frame shall be discarded. If the TRAU-UL frame fails CRC-3 verification, then FT=0 and FT=6 shall be transformed into FT=7, and FT=2 shall be transformed into FT=1. The D bits shall be discarded in this case. 6.3. Requirements for UL conversion to TFO output If the CN transcoder (MGW) implements in-band TFO per TS 28.062, it will need to convert the UL frame stream from super-5993 payloads received via RTP to 8 kbit/s TRAU-UL frames to be inserted into the lsb of the output PCM sample stream. This conversion shall be performed as detailed in the following sections. 6.3.1. Derivation of extended control bits in TFO output frames Extended control bits XC1 through XC5 shall be generated following this C pseudocode: XC1 = 0; switch (FT) { case 0: XC2 = 0; XC3 = 0; XC4 = 0; break; case 1: XC2 = 1; XC3 = 0; XC4 = TAF; break; case 2: XC2 = 0; XC3 = 0; XC4 = 1; break; case 6: case 7: XC2 = 1; XC3 = 1; XC4 = TAF; break; } XC5 = UFI; The variables in the above pseudocode are as follows: FT input: FT field of received super-5993 ToC octet TAF input: TAF bit of received super-5993 ToC octet UFI input: UFI bit of received super-5993 ToC octet XC1 through XC5 output: bits to be set in the TFO frame being generated 6.3.2. Filling of Dn and CRC bits in TFO output frames For FT=0, FT=2 and FT=6 RTP input, Dn bits shall be filled from the received RTP payload and CRC-3 shall be computed correctly. For FT=1 (invalid SID) and FT=7 (No_Data) RTP input, Dn bits in the TFO output frame shall be filled with a pattern of all 0 bits. The current recommendation is that CRC-3 bits should be emitted correctly; the alternative option of transmitting inverted CRC is for further study. 7. Enhanced RTP transport in the radio downlink direction The RTP stream going toward a BTS in the DL direction may originate from one of 3 possible sources, detailed in the following sections. 7.1. TrFO connection between two call legs If the UL output from call leg A is directly connected to the DL input of call leg B, the DL-handling RTP receiver in the native IP BTS or in the converter to T1/E1 Abis shall accept and gracefully handle all possibilities that can occur in the UL output stream per sections 6.1 and 6.2. 7.2. Free-running speech encoder output If the CN transcoder is operating with a free-running speech encoder (not in TFO), this encoder shall operate in one of two modes: a) If DTXd is not implemented or disabled by network policy, the encoder shall emit a good speech frame (FT=0) in every 20 ms frame position and send it to the downlink. b) If DTXd is implemented and enabled by network policy, the encoder shall emit either a good speech frame (FT=0) or a SID frame (FT=2) in every 20 ms frame position, and send it to the downlink. A free-running speech encoder shall never generate any other frame types; furthermore, UFI and TAF bits in the output of this encoder shall always be set to 0. Therefore, the output of a free-running speech encoder is compliant with regular RFC 5993 without using any of the extensions of the present TS. 7.3. Conversion from incoming TFO frames to local DL If the CN transcoder has established TFO with a distant partner and is receiving TFO frames from the latter, it shall convert these received TFO frames to super-5993 payloads for the local DL per sections 6.2.2 and 6.2.3. 8. Use of enhanced RTP transport at the AoIP interface 3GPP TS 48.103 specifies the use of RFC 5993 payload format for GSM-HR at the AoIP interface, hence network implementors who choose to follow the present TS instead have to explicitly deviate from 3GPP norms in this regard. In order to support both 3GPP and Themyscira options in the same Free Software implementations and to facilitate the possibility of Themyscira option being mainlined, a BSSMAP extension has been defined, a non-standard information element that can be added to ASSIGNMENT REQUEST messages to request the use of TW-TS-001 and TW-TS-002 payload formats instead of the standard ones stipulated by TS 48.103. This BSSMAP extension is defined in TW-TS-003. The payload type numbers defined in TS 48.103 Table 5.4.2.2.1 remain the same whether or not enhanced payload formats are used, including the use of payload type 111 for GSM-HR and the other two payload types defined in TW-TS-001. No distinct payload types are needed because the super-5993 payload format of the present TS is a practically compatible superset of RFC 5993: many super-5993 payloads (those in which FT is 0, 2 or 7, while UFI and TAF equal 0) are also valid per standard RFC 5993, and when extensions of the present TS do get used, they will likely be harmlessly ignored (new frame types discarded, new flag bits ignored) by existing implementations that only care about standard RFC 5993. In any given session (RTP leg), a sender can use extensions of the present TS once it knows that the receiver supports them; MGW and BSS support for these extension is communicated via BSSMAP as defined in TW-TS-003. 9. Use of enhanced RTP transport at the Abis-IP interface Unlike AoIP, there are no 3GPP specifications for Abis over IP - hence all existing Abis-IP interfaces are vendor-specific. Themyscira Wireless specifications are intended for use in Osmocom-based GSM networks, hence the relevant Abis-IP interface is that of Osmocom. The envisioned implementation is that OsmoBSC shall decode and act upon the BSSMAP extension IE defined in TW-TS-003 and shall pass the instruction to use TW-TS-001 and TW-TS-002 payload formats to OsmoBTS over RSL, using an Osmocom-specific mechanism. The latter mechanism is not yet defined and remains to be worked out in Osmocom community. Annex A (informative): Specification change history Version 1.1.0: initial publication for review by Osmocom community.