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 (
voice.in ---E---> gsm ---D---> voice.out
The goal here is to:
- Pass the compact
gsmcodec over the radio link
voice.inas well as possible with
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.outover the network, and it arrives in the home base that treats it like a binary stream. Since
gsm.outcannot be sent directly, it is necessary to go through
voiceand hope that
gsm.outwill be equal, or close enough to
- The base station transmits
gsm.inover 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
- 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?
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:
Eschas the value 0x1b
Badis an empty list