More about GSM voice codecs

[Mychaela Falconia]

Hello FC community,

Today I dug around a little bit and figured out how to tell from the
trace output of a TI-based GSM firmware (either one of ours or one of
the pre-existing proprietary versions) which voice codec is being
selected by the network.  As a quick refresher, the MS (mobile station)
advertises to the network which codecs it supports, the network makes
the selection of which one will be used, the MS is told which codec
has been selected by the network during the call setup process, and at
that point the MS has to obey.  For debugging purposes, we would like
to be able to see which codec has been selected.

My quick investigation has revealed that the codec selection (also
known as the TCH mode) can be seen in the CAS_R trace output line from
L1.  Look for a pair of lines like the following in the rvtdump or
rvinterf output:

L1: 
+ CAS_R 39330 0 298 1 0 0 1 11 0 0 -1 0 1 0 1 0 0 0 95 12 17 25  2  3  3

It is actually a single L1 trace packet, but our tools display it as
two lines because the target sends a CRLF at the beginning of the
string.  Formatting quirk aside, look at the 8th number after the
CAS_R keyword - 11 in the example above.  This number is the codec or
TCH mode selection, and the meaning of the numbers is defined in
l1_const.h - look for the group of #defines beginning with
SIG_ONLY_MODE.  The mode numbers which correspond to voice codecs (as
opposed to CSD or signaling-only channels) are:

1: original FR codec
2: original HR (half-rate) codec, probably not used any more as users
   hated the poor voice quality
8: EFR (Enhanced Full Rate)
10: AMR on a half-rate TCH
11: AMR on a full-rate TCH

Armed with this knowledge, I have grepped through my extensive
collection of rvtdump/rvinterf logs from various sessions with various
firmwares, and made the following observations:

* Given a mobile station that supports all codecs, the network in my
  neck of the woods (USA-occupied Incalia, Operator 310260) seems to
  always select AMR, either full-rate or half-rate (see below).  If
  the MS does not support AMR but does support EFR, then EFR gets
  selected.  (Firmware hacks aside, there was a generation of GSM
  chips and hence phones made with those chips which supported EFR but
  not AMR; the original Calypso C05 - predating the Calypso C035 we
  are working with - is one of those non-AMR-capable GSM chips, but it
  does support EFR.)  The plain FR codec gets selected only as the
  last resort when the MS says that it supports nothing else.  It does
  work, but I suspect that I may well be the only user on this GSM
  operator's network who occasionally connects a mobile which
  advertises support for FR only. :-)

* I thought that half-rate traffic channels (squeezing two different
  users into one timeslot) were a feature of the GSM specs which is no
  longer used in the real world (I read that users complained about
  the quality being unacceptable), but I was quite surprised when I
  saw that this same Operator 310260's network does assign such
  half-rate traffic channels to my test calls from time to time.  The
  catch, however, is that it uses AMR in half-rate mode when it does
  this, as opposed to the original HR codec - it was the latter that
  drew the ire of users, from what I've read.  Apparently AMR in HR
  mode must be really good, as I never noticed any quality degradation
  with my not-too-discerning ears.

* If a network uses AMR-HR but not plain HR, as Operator 310260's
  network seems to do, then its ability to assign a half-rate TCH to a
  call is contingent upon the MS supporting AMR.  Thus if a mobile
  station advertises support for FR only or FR+EFR, then the network
  only has two choices: either grant a full-rate TCH or refuse to
  connect the call.  Thankfully, I have yet to see the latter behaviour.

* The behaviour of our gcc-built gsm-fw with our current half-broken L1
  for each codec option seems to be as follows:

FR: seems to work OK, the current code advertises support for FR only
    by default.
HR: untested
EFR: DSP blows up with errors
AMR-FR: no fireworks, but only noise is heard in the earpiece speaker
	instead of downlink audio
AMR-HR: blows up like EFR

Although one could argue that we could just live with only using the
original FR codec, I do not particularly feel like building higher-
level functionality on top of a known-buggy version of L1 which is
known to be inferior to our TCS211 golden reference.  Therefore, my
plan on the software track remains the same as before: reconstruct the
TCS211 version of L1 fully, to the point where we'll be able to
completely replace our current half-broken L1 with it, before
proceeding in any other direction.

Happy hacking,
Mychaela