Subject: Variable error coding for 3G wireless

From: "Simon Barber" <[email-masked]>
Date: Fri, 15 Dec 2000 23:59:31 -0800

Hi,

A quick go at getting some of my ideas down. Comments wanted.

Simon.

IP over medium loss channels.

Thrid generation wireless networks will be widespread, and give IP a new
challenge. To date pretty much all L2 transports which IP has run over have
given IP a low bit error rate channel. Where they havn't (typically
wireless) L2 techniques such as FEC and retransmission have been used to
simulate a reliable channel. The reson for this is that the main traffic
type has been TCP - the most used IP transport to date. TCP uses packet loss
to detect congestion, and hence a L2 that drops more than a tiny fraction of
packets causes throughput to drop drastically (note: how does TCP behave
when it receives corrupt packets?). To prevent this happening FEC can be
used. FEC adds redundancy to the data bits on the channel, to allow recovery
of corrupt data. The problem is that to make the channel reliable enough for
TCP, a lot of FEC bits must be added. This makes the channel very
inefficient for data that does not need this level of reliability. A second
technique used is retransmission. This is often used in conjunction with
FEC. ACK or NACK packets are transmitted at L2 to guarantee reliablility of
the IP data. This adds latency that is unacceptable for real-time traffic
(such as voice).

2nd generation digital cellular systems do an excellent job of using a very
scarse resource (radio spectrum) to transmit voice. To achieve the levels of
efficiency required for financially viable operation of these networks (the
spectrum is expensive) - many specialised techniques are used. Now that 3rd
generation digital cellular systems are being developed a big question is
how can the efficiency of 2G cellular voice be combined with the IP network,
ideally in an end-to-end model.

In 2nd gen cellular selective FEC is an important part of the spectral
efficiency. Within a frame from a voice codec transmitted over the air
certain bits are protected with more FEC than other bits - in accordance
with how important those bits are for the decoding of the voice without
artifacts. This technique could also be usefully applied to other data
types, MPEG video for example.

I propose a new IP layer packet header option, to label the importance of
various parts of a packet.

The option could be added by any IP endpoint or by a router (by
stateful(perhaps) inspection of the data in the packet).

The option would list what level of protection should be given to various
parts of the packet. For example for voice data, compressed with the GSM-EFR
codec, the packet headers would be listed as requiring a high level of
protection,  and the GSM data would be listed as requiring protection of
varying levels, just as 2G cellular applies it today.

This technique will increase the size of the packet, but over the critical,
efficiency sensitive links (such as 3G wireless) header compression will all
but completely remove this overhead. The resulting data will be able to
closely approach 2G cellular's efficiency for voice data, and the technique
is general for other data types.

Just as real-time data can be protected by this technique, TCP data could be
protected as well. TCP packets could be marked as requiring a particular
class of reliability. L2 could then use whatever technique necessary to
provide this.

It would be important that the way the importance of various packet parts is
expressed be generic, and not given in terms of specific FEC codes, etc.
This will allow future use of this information on different medium loss
channels.

Issues:

1) The TOS bits already have a 'low loss' marker. This could provide the
necessary distinction for TCP protection, without a new header. I don't know
the current state of these bits.
2) Will the header compression techniques compress IP options?
3) Will there be interactions with existing IP stacks due to the presence of
a new option?
4) Some data types need several (a small number) of different patterns of
protection for different packets - header compression would need to be chang
ed to cope with a small number of different possibilities for the new option
data.
5) How would apps detect when they should add this new option (when there is
a lossy channel) and when not to do so?

Features:
The IP packet payload remains unchanged by the protection information - this
is very good for the end-to-end model. An existing application using GSM
voice over RTP over IP would remain backwards compatible and essentially
unchanged.

Use:

There are 2 ways the new header would be added to IP packets.
1) a new IOCTL in the sockets API would allow setting of error protection.
2) packet inspection and addition by routers.

Simon Barber