Codec Freedom -- Specifications -- Connection Profiles - Cellular GSM

In cellular networks that lack support for the G2 protocol CSD, there may be an alternative approach by modifying the GSM codec itself. This is definately more difficult than the CSD path, and could be a very interesting assignment for a student research project.

See also: Cellular CSD connections

Turning GSM upside-down

The normal use of GSM aims to map voice to voice throug encode (E) and decode (D) phases:

voice.in ---E---> gsm ---D---> voice.out

The goal here is to:

• Pass the compact gsm codec over the radio link
• Approach voice.in as well as possible with voice.out

However, if we want to treat GSM as a connection that transports binary data, we need to think differently:

gsm.in ---D---> voice ---E---> gsm.out

Note that the decode phase comes before the encode phase, the opposite of the normal strategy.

• The mobile phone transmits gsm.out over the network, and it arrives in the home base that treats it like a binary stream. Since gsm.out cannot be sent directly, it is necessary to go through voice and hope that gsm.out will be equal, or close enough to gsm.in
• The base station transmits gsm.in over the network, and it arrives in the mobile phone that does not provide it in the clear, but decodes it to voice, which in turn can be mapped to gsm.out.
• In short, the mobile phone contains a software version of the GSM codec, and hopes to achieve the opposite of the hardware-concealed version of the codec.

The situation becomes even more complex when we want to use bit insertion, because then we need to modify the GSM stream after voice is inserted.

The general picture may look like this, where dashed lines indicate portions that may or may not be desired:

Uncertainties / Research Questions

The GSM codec is a confusing whole. It is proprietary, and covered with patents. There also appear to be multiple versions.

The advantageous property of the upside-down approach is that the software version inverts the effects of the hardware in the same device, so an optimal coupling can be constructed.

Questions related to platforms, and their GSM-codec enforcement:

• (on what platforms) can the GSM codec be bypassed, and GSM treated as a binary channel, like CSD
• (on what platforms) can the GSM codec be inverted on the platform itself, and used to construct the desired combinations of coding and decoding; and is the hardware capable of doing this more than once per GSM frame cycle?
• Is it possible to "look back" at tranmitted data?

Questions due to inverting the encoding and decoding order:

• (under what conditions) will GSM reproduce the GSM stream when it passes through voice? For instance, is there an "average" value for the voice parameters that makes more algorithms round off
• what is the best combination for bit insertion; are more passes through encoding / decoded required, and would that impact the quality?
• What is required to make an optimal match of the decoder and encoder combination?
• In which places is the decoder, encoder sequence least sensitive to bit insertion?
• Can the opposite-order combination of decoder,encoder be trained to form an optimal match?

Questions related to GSM bit insertion:

• Which bits in the GSM codec are least audible for bit insertion purposes?
• Which bits in the GSM codec are good for bit insertion with certain delivery?

Connection Profile

TODO: Anything below is open for discussion.

GSM provides a bit-insertion platform at best; but at some point, it should be possible to switch it to a bit transport channel, much like CSD. It would then provide an error-corrected service at (presumably) 13 kb/s. Note that error correction is at the level of audio safety, not data safety.

It should nonetheless be possible to construct a packet mode, even if this would require retransmissions in case of failure.

For packet mode, the following profile defines the behaviour of a suitable escaping discipline:

• Esc has the value 0x1b
• Bad is an empty list
• MaxCode is 250
• Fillup is false.