Themyscira Wireless Technical Specification TW-TS-002 Version 1.2.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". [16] TW-TM-004: "Description of RSL_IE_OSMO_RTP_EXTENSIONS defined in Osmocom Abis". 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 or 14 octets of payload 6 = Bad speech frame (BFI with data), ToC followed by 14 octets of payload Note that invalid SID frames (FT=1) can be transported in two forms: either with or without frame payload bits. The original version of the present TS required FT=1 frames to have no payload bits; the present updated version allows both options as detailed in section 5.4. 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|ISV |UFI |TAF | +----+----+----+----+----+----+----+----+ The 4 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; Invalid_SID_Verbose (ISV): defined in section 5.4; UFI: strictly identical with same-named flag of GSM 06.41; TAF: strictly identical with same-named flag of GSM 06.41. ISV bit is valid only for FT=1; for all other frame types, this bit is reserved and shall be set to 0. 5.4. Provision or omission of frame payload bits for invalid SID Per GSM 06.41 and related GSM-HR codec specs, when a received traffic frame is deemed to be invalid SID, its bit content is never used for anything; on the basis of this fact, the original version of the present TS stipulated that invalid SID (FT=1) frames shall be transported with all payload bits stripped, in ToC-only short form just like FT=7 defined in RFC 5993. However, later experience with implementation reveals two shortcomings of this scheme: * Streams of RTP packets are often captured and examined for debugging. Given that the SID detector for HR codec is non-trivial compared to its FR and EFR counterparts, it is desirable to be able to capture the Abis UL output from a BTS, look at both the channel-decoded payload bits and the assigned SID classification, and observe the action of the SID detector block. However, having the payload bits removed when the classification decision was invalid-SID defeats this form of debugging. * If the UL frame stream is to be first transported in RTP, then emitted in TFO frames per TS 28.062, every frame has to have some payload bit content, no exceptions. If no payload bit content exists at all because nothing was received or the traffic frame position was stolen for FACCH, then the network element that implements TFO has no choice but to synthesize its own artificial filler (see section 6.3.2) - but if the payload bit content does exist at the source but is lost to limitations of RTP transport format, then that format is deficient. In light of these considerations, both forms are now allowed: a network element that emits GSM-HR codec frames in RTP per the present TS can encode an invalid SID frame with payload bits included if such bits exist, or without payload if none is available. The two formats are distinguished by ToC octet bit 0x04 (hex mask), which was previously reserved but is now redefined as Invalid_SID_Verbose (ISV). ISV bit is defined only for FT=1 and is reserved otherwise. When FT=1 and ISV=1, frame payload bits are included and the full super-5993 payload is 15 octets long; when FT=1 and ISV=0, frame payload bits are omitted and the full super-5993 payload is 1 octet long. This bit was set to 0 by implementations written according to the previous version of this TS, hence backward compatibility is maintained. 5.5. Provision or omission of frame payload bits for unusable frames A traffic frame that is classified as an unusable frame per GSM 06.41 can be represented in RTP per the present TS as either No_Data (FT=7) or BFI-with-data (FT=6). The mechanism for transporting BFI-with-data is needed for two reasons: * The same considerations that were examined in section 5.4 for invalid SID frames also apply to unusable frames; * The bad frame handler in the reference C code [15] makes use of certain parameters from bad speech frames under certain conditions. 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 this frame as FT=1 with ISV=1, with payload bits included; d*) Implementations that were done according to the earlier version of the present TS are allowed to emit invalid SID (FT=1) in the short (ToC only) form with ISV=0 instead; 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 7 because the TRAU-UL frame is deemed to be invalid, these D bits from the deemed-invalid TRAU-UL frame shall be discarded. If the FT arrived at by the logic of section 6.2.1 or 6.2.2 is 1 (invalid SID), new implementations should emit the FT=1 frame with ISV=1 and payload bits included. However, older implementations that were done according to the earlier version of the present TS are allowed to emit the short (ToC only) form with ISV=0 instead. 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, as well as FT=1 RTP input with ISV=1, Dn bits shall be filled from the received RTP payload and CRC-3 shall be computed correctly. For FT=1 ISV=0 (invalid SID without payload bits) and FT=7 (No_Data) RTP input, the choice of filler for Dn bits in the TFO output frame is at the discretion of implementors; setting all Dn bits to 0 is an acceptable choice. 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 extensions 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 described in TW-TM-004 [16]. Annex A (informative): Specification change history Version 1.1.0: initial publication for review by Osmocom community. Version 1.2.0: * add the option of including frame payload bits when transporting invalid SID frames: new section 5.4, changes throughout the spec wherever invalid SID frames are involved. * change in section 6.3.2, conversion from RTP to TFO frame output, dummy fill in the case of No_Data or short-form invalid SID input: instead of making all-0 fill pattern mandatory, leave the choice of fill pattern to the discretion of implementors. * small change in document organization: description of BFI-with-data (FT=6) transport and the rationale for it moved to new section 5.5. * add reference to TW-TM-004 for Osmocom Abis-IP.