chen-afec-01.txt

Internet DRAFT - draft-chen-afec

draft-chen-afec

Last Version:	draft-chen-afec-01.txt	Tracker Entry
Date:	`23-Mar-2007`
Disposition:	expired
Previous Versions:	draft-chen-afec-00.txt (diff) - 16-Sep-2006

Internet Draft Zhikui Chen
Document: draft-chen-afec-01.txt Universitaet Stuttgart
Expires: September 2007

An Adaptive FEC to Protect RoHC and UDP-Lite Vital Video Data

Status of this Memo

By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

This document generally describes how to use an Adaptive Forward
Error Correction (AFEC) algorithm to efficiently protect the
compressed header vital data as well as UDP-Lite’s vital data for
data transport in the radio-link layer of an error-prone wireless
connection. Augmented with RoHC and UDP-Lite, for video
transmissions over wireless channels in a heterogeneous wired-
wireless environment, the erroneous packet payloads can be useful
and the applications better able to cope with lost packets (native
UDP case), by adopting some of the erasure and error resilient
modes in the latest video codecs, such as H.264. The context
transfer in the inter/intra handover is also covered.

Zhikui Chen Expires – September 2007 [Page 1]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

Three examples are described, which are UMTS, Bluetooth and WLAN.
In example of WLAN, a concept of MAC-Lite is introduced, which
consists of two parts of nonsensitive and sensitive to bit errors.

Table of Contents

1. Introduction..................................................2
2. Terminology...................................................4
2.1 Acronyms..................................................6
3. Adaptive FEC Algorithm........................................7
3.1 General Encoding Algorithm................................7
3.2 Unicast...................................................7
3.3 Multicast and broadcast...................................8
4. AFEC Payload and its PDU Encapsulation........................8
4.1 AFEC Payload Format.......................................8
4.2 Vital Data Protection.....................................9
4.3 AFEC Payload Encapsulation...............................10
5. Setting up the Transport Protocol, AFEC and RoHC.............10
6. Erroneous SDU Delivery across Network Layers.................11
7. Context Transfer during Handover.............................12
8. Examples of UMTS, Blurtooth and WLAN.........................12
8.1 UMTS.....................................................12
8.2 Bluetooth................................................14
8.3 WLAN.....................................................16
9. Security considerations......................................18
10. References..................................................18
Author's Address................................................19
Intellectual Property Statement.................................19

1. Introduction

The main challenges for the next generation of real-time wireless
communication environments, e.g., IP multicast and broadcast, is
the provisioning of user-centric and customizable QoS services with
end-to-end guarantees. The next generation networks will include a
diversity of wireless technologies for the network access, also
known as open wireless architecture. Further, due to the likely
business models in emerging wireless systems (3G/B3G) in which the
end-user’s costs are proportional to the transmitted data volume
and also due to limited bandwidth and transmission power,
compression efficiency is the main target for wireless video and
multimedia applications. The latest video coding [1] technology
provides such a possibility for all wireless applications including
Multimedia Messaging Services (MMS), Packet-switched Streaming
Services (PSS) as well as video-conversational applications.

Zhikui Chen Expires – September 2007 [Page 2]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

The most important characteristic of wireless links is its lossy
behaviour, where a bit error rate (BER) as high as 1e-3 must be
accepted in order to keep the radio resources efficiently utilized.
In severe operating situations, the BER can be as high as 1e-2. An
additional problem is that the residual BER is nontrivial, i.e.,
the lower layers can sometimes deliver frames containing undetected
errors. For reducing bit errors and bandwidth, the IETF has
developed a robust RTP/UDP/IP header compression scheme [2]. A
viable header compression scheme for wireless links must be able to
handle losses on the link between the compression and decompression
point as well as any losses before the compression point.

[2] provides three compression modes, U-mode (unidirectional
mode), O-mode (bidirectional optimistic mode) and R-mode
(bidirectional reliable mode). In U-mode, packets are sent in one
direction only. The periodic refreshes are used to protect
compressed headers against bit errors. O-mode uses a feedback
channel to send error recovery requests and (optionally)
acknowledgments of significant context updates. It reduces the
number of damaged headers delivered to the upper layers due to
residual errors or context invalidation. R-mode more intensively
uses the feedback channel and stricter logic at both the compressor
and decompressor to prevent loss of context synchronization between
compressor and decompressor.

Two problems arise: one is that bit errors cause loss of or damage
to individual headers and this further affects later arriving
compressed headers, and the other is that the frequent usage of
feedback can utilise more network resources and generate extra
delays, which is fatal for real-time communications.

Some header impairments can cause context invalidation. Damage
propagation and undetected residual errors both contribute to the
number of damaged headers delivered to upper layers. In a noise and
error-prone wireless channel, assuming a BER of 1e-3 and a
compressed RTP/UDP-Lite/IP header size of 8 bytes, this would mean
that for every 100 packets at least 6 would be damaged. U-mode has
to refresh the compressed header using the uncompressed header with
at least a 6% frequency at the packet level, so that header
compression efficiency will decrease at least 5%. On the other
hand, due to randomicity of bit errors, periodic refreshes can not
prevent error propagation and propagation losses caused by damaged
compressed headers. Also, the damaged packet has still to be
delivered to the upper layer or discarded at the current layer. For
O-mode and R-mode, they have to send at least 6 feedback packets to
the compressor. O-mode can prevent error propagation and
propagation loss, but the impaired packet is still delivered to the

Zhikui Chen Expires – September 2007 [Page 3]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

upper layer or discarded at the current layer. R-mode more
frequently uses a feedback channel. High feedback rates will
consume more network resources and generate large delays. This will
cause further packet losses. Of the other aspects, the frequent
usage of the feedback channel will consume precious radio
resources. This infringes the aims of header compression or
compression efficiency.

Therefore, maximal header compression efficiency expects to reduce
refresh packets in U-mode and feedback packets in O-mode and R-
mode. Using less redundancy to protect the compressed header is
possible and can significantly improve end-to-end multimedia
quality.

Meanwhile, the bit errors in the UDP-Lite’s vital data will cause
checksum failures and damaged-packet discards. At higher BERs such
as 1e-3 and 1e-2, bit errors in the vital data will generate a
large number of packet discards. For maximal benefit, the vital
data must also be protected against bit errors.

Additionally, in the cases of Multicast and Digital Video Broadcast
(DVB), even including unicast, retransmission of the corrupted SDUs
in L2 and use of frequent feedbacks are impossible during real-time
communications.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.

Bit Error Rate, BER

Cellular radio links can have a high BER. In this document
BER is usually given as a probability, but one also needs to
consider the error distribution as bit errors are not
independent.

Cellular links

Wireless links between mobile terminals and base stations.

Damage propagation

Delivery of incorrect decompressed headers, due to loss of or
damage to previous header(s) or feedback.

Zhikui Chen Expires – September 2007 [Page 4]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

Loss propagation

Loss of headers, due to loss of or damage to previous
header(s) or feedback.

Error detection

Detection of errors. If error detection is not perfect, there
will be residual errors.

Error propagation

Damage propagation or loss propagation.

Header compression profile

A header compression profile is a specification of how to
compress the headers of a certain kind of packet stream over
a certain kind of link. Compression profiles provide the
details of the header compression framework introduced in
this document. The profile concept makes use of profile
identifiers to separate different profiles which are used
when setting up the compression scheme.
All variations and parameters of the header compression
scheme that are not part of the context state are handled by
different profile identifiers.

Packet

Generally, a unit of transmission and reception (protocol
data unit). Specifically, when contrasted with "frame", the
packet compressed and then decompressed by ROHC. Also called
an"uncompressed packet".

Packet Stream

A sequence of packets where the field values and change
patterns of field values are such that the headers can be
compressed using the same context.

Pre-HC links

The Pre-HC links are all links that a packet has traversed
before the header compression point. If we consider a path
with cellular links as first and last hops, the Pre-HC links
for the compressor at the last link are the first cellular
link plus the wired links in between.

Zhikui Chen Expires – September 2007 [Page 5]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

Residual error

An error introduced during transmission and not detected by
the lower-layer error detection schemes.

Robustness

The performance of a header compression scheme can be
described with three parameters: compression efficiency,
robustness, and compression transparency. A robust scheme
tolerates loss and residual errors on the link over which
header compression takes place without losing additional
packets or introducing additional errors in decompressed
headers.

Spectrum efficiency

Radio resources are limited and expensive. Therefore they
must be used efficiently to make the system economically
feasible. In cellular systems, this is achieved by
maximizing the number of users served within each cell, while
the quality of the provided services is kept at an acceptable
level. A consequence of efficient spectrum use is a high rate
of errors (frame loss and residual bit errors), even after
channel coding with error correction.

Media Payload

The raw, un-protected user data that are transmitted from the
sender.

Media Header

The compressed RTP/UDP-Lite/IP header for the packet
containing the media payload.

Media packet

The combination of a media payload and media header is called
a media packet.

2.1 Acronyms

This section lists most acronyms used.

UDP-Lite Lightweight User Datagram Protocol
O-mode Bidirectional Optimistic mode.

Zhikui Chen Expires – September 2007 [Page 6]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

PPP Point-to-Point Protocol.
R-mode Bidirectional Reliable mode.
ROHC RObust Header Compression.
RTP Real-Time Protocol - RFC 1889.
U-mode Unidirectional mode.
FEC Forward Error Correction - RFC 3452.
AFEC Adaptive FEC.
MT Mobile Terminal or Moving Terminal.
PCDP Packet Convergence Data Protocol.
QoS Quality of Service.
QoSM QoS Manager.
QoSB QoS Broker.
AFEC Adaptive FEC.
EFR The encoding FEC rate.
FBER The RoHC feedback BER from the MT or QoSM hints.
PBER The maximal value of all SDUs for the current PDCP PDU.
RBER The BER of the current received SDU.
SDU Service Data Unit.
PDU Protocol Data Unit.
WLAN Wireless LAN

3. Adaptive FEC Algorithm

3.1 General Encoding Algorithm

For a general FEC algorithm, two of the three parameters: FEC
encoding rate, original data length and redundancy data length,
decide a GRS code. Generally, the first two parameters decide the
third. In a self-adaptive FEC algorithm system, FEC encoding rate
is decided by the BER on the receiver side as well as the
previously used encoding rate. A generalized Reed-Solomon (GRS)
algorithm is proposed in [11].

3.2 Unicast

In case of uincast, the adaptive error control scheme for UDP-Lite
and RoHC vital data in the PDCP sublayer in WCDMA for B3G/4G is
designed according to the bit error rate from the RLC in the
receiver, which has a feedback channel or upload channel. At the
sender, the initial FEC encoding rate, EFR, (an integer as a
percentage, with a maximum value less than 127%) is set to 10% (and
is configurable during session establishment). From the second
packet, the FEC rate is the maximal value of the previous FEC rate
and the BER at the receiver (RBER), as delivered by the sender.

At the receiver, there are three BERs. The first is the sender
encoded value, EFR, which is encapsulated in the AFEC packet, the
second is the PBER (the maximal value of all SDUs of the current

Zhikui Chen Expires – September 2007 [Page 7]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

PDCP PDU as measured by the physical layer), and the third is that
computed from the FEC decoding process. Thus, the receiver receives
the BER, in terms of RBER, as the maximal value of the above three.
If the current RBER is less than the previous RBER, it will not be
transferred to the sender. Otherwise, the RBER will be delivered to
sender.

There are several ways to transfer the RBER from the receiver to
the sender. Firstly, RoHC can generate a feedback to transfer RBER
to the sender. Secondly, the QoS management system can deliver RBER
to the sender. In this case, the RBER is first delivered to a QoS
client (which normally is the current mobile terminal), and then
the RBER is delivered to the QoS broker (which manages and controls
the communication quality) and then to the QoS manager (generally
the QoS manager is an access router, i.e., the sender in a wired-
wireless communication environment).

3.3 Multicast and broadcast

In case of multicast and broadcast, there is no upload channel to
delivery RBER from the receiver, whilst one sender maps multiple
receivers. The FEC encoding rate, is generated dynamically in
accordance with the current network traffic load and the wireless
channel state. For example, in IEEE802.11, the queue length of the
access point can provide an indication of the current network
traffic load and the packet retransmission time can indicate the
wireless channel status. In FEC algorithm, it is better to avoid
causing network congestion, so in the first case, when queue length
is short which means network load is low and more FEC encoding rate
can be allocated. For the later case, when the wireless is in good
status, its retransmission time is short, and then the FEC encoding
rate can be lower.

Informative note: AFEC is proposed to reduce error propagation
and feedback channel usage in the RoHC, in order to further
decrease the packet loss due to residual bit errors and limited
retransmissions at the physical layer; a maximal 127% EFR value
is acceptable.

4. AFEC Payload and its PDU Encapsulation

4.1 AFEC Payload Format

The payload format as described here combines the original packet
fields and the protected parity code as produced by the protected
compressed header, UDP-Lite vital data or both packet fields of an

Zhikui Chen Expires – September 2007 [Page 8]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

RTP/UDP-Lite (UDP)/IP packet as shown below: The FEC encoding rate
field EFR, (1 bit to specify redundancy length, 7 bits to store EFR
value), redundant data length (1 or 2 bytes) and redundant data are
encapsulated at the front of the compressed header data. The
receiver reads, in order, the FEC redundancy length specification
bit, FEC encoding rate, redundancy code length, redundancy data and
the original protected information, as shown in Figure 1.

Where:
L bit: the parity code length, either 1 or 2 bytes. If L is 0,
the FEC Length occupies one byte; if L is 1, the FEC Length
occupies 2 bytes.
EFR: 7 bits to define the FEC encoding rate, the minimum value is
0 indicating no FEC. The maximum value is 127, representing the
maximum FEC encoding rate of 1.27. I.e., if the original data is
100 bytes, then encoded redundancy is 127 bytes.
FEC Length: 1 or 2 bytes, to store the encoded redundancy length.
FEC code: Redundancy code (parity code) with FEC length bytes.
RoHC: The compressed packet header data, RoHC data.
Coverage: The UDP-Lite checksummed data area.
UDP-Lite non-vital data: The UDP-Lite data that is not
checksummed.

At the server side, the protection is performed at access before
packet generation (e.g. Ethernet, PPP over Ethernet, or other
wireless links such as Bluetooth BNEP or WCDMA PDCP (UMTS)). The
terminal will decode the received protected media packet after the
Ethernet header and/or PPP header have been removed.

4.2 Vital Data Protection

The protection operation involves computing the parity (XOR) across
the RoHC packet fields and the UDP-Lite vital data, which needs to
be protected. The recovery procedures allow terminals to correct
the damaged RoHC and the UDP-Lite’s vital data. Three schemes of
vital data protection are proposed as below:

Zhikui Chen Expires – September 2007 [Page 9]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

. Vital Data Coverage of UDP-Lite

The recovery bit string is generated from the vital data of
UDP-Lite. In some advanced video codecs, the encoded video
data in a packet is divided into two parts, a vital and a non-
vital part; such as header and non-header parts. The vital
part, checksum protected, can then be specified by the
application in conformance with the data partitioning
strategy, and the different levels of importance of the
different segments within the packet according to their
different error resiliencies; the usage of CABAC or CAVLC in
H264 would lead to a longer or shorter coverage respectively.
E.g., in our tests, ‘partition A’ packets of the I, P or B
frames in the three partitions are checksummed whilst
‘partition B & C’ packets are only partially checksummed. The
decoding procedure at the terminal only recovers the required
bytes inside UDP-LITE’s vital data.

. RoHC Protection

The recovery bit string is generated by the RoHC header field.
The terminal only recovers the damaged bytes inside the RoHC
header field.

. Both RoHC and UDP-LITE Vital Data Protection

The recovery bit string is generated from both the RoHC header
field and UDP-Lite’s vital data. The decoding procedure at the
terminal recovers the damaged bytes inside both the RoHC
header field and UDP-Lite’s vital data.

4.3 AFEC Payload Encapsulation

The AFEC payload data is encapsulated into a Radio Link Layer
packet, which depends upon the specific network technology. Two
examples using UMTS and Bluetooth encapsulation are described in
section 8.1 and 8.2.

5. Setting up the Transport Protocol, AFEC and RoHC

Upon session establishment, an offer/answer Session Description
Protocol, SDP [9], is used to describe user end-to-end
configurations including application-specific multimedia QoS such
as the multimedia codec’s error resilient mode, a transport
protocol such as RTP, UDP or UDP-Lite, bandwidth/multimedia
encoding rate, RoHC/AFEC functionalities (e.g., in SDP description:

Zhikui Chen Expires – September 2007 [Page 10]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

m=application UDP-Lite, RoHC x, AFEC y,…; here x describes the RoHC
profile, if x is non-zero, otherwise this is not RoHC or RoHC will
not be activated; y represents the initial EFR value, if it is zero,
meaning that the AFEC will not be used), erroneous SDU treatment
request (whether the erroneous SDU is delivered to the upper layer
or dropped, e.g., in 3GPP, as described in section 6) and MAC
retransmission limits, etc.

Additionally, RoHC/AFEC configurations also can be accomplished by
the network connection set-up, such as for Bluetooth (see section
8.2). Those distributed parts of the application may choose the
mutually supportable configurations, which become actual
configurations for the application.

6. Erroneous SDU Delivery across Network Layers

The delivery of erroneous SDUs determines whether error detection
shall be used and if so, whether SDUs with an error in a subflow
shall be delivered or not. I.e., to ignore the bit-errors at the
Media Access Control (MAC) layer, which is not corrected by the
physical layer due to residual bit errors and limited
retransmissions, the corrupted packets are relayed to the higher
network layer.

For example, in 3GPP, its QoS architecture provides some
functionality to deliver erroneous SDUs [13]. There are three
configurations: yes, no and ‘-‘. If the configuration is set to
‘yes’, this implies that error detection is to be employed and that
erroneous SDUs are to be delivered together with an error
indication. If ‘no’, this implies that error detection is to be
employed and that erroneous SDUs are to be discarded. Finally, if
‘-‘, this implies that SDUs are to be delivered without using error
detection. For the case of variable protection, different subflows
have different settings. When error detection configurations of a
subflow are set to ‘no’, the erroneous SDU is discarded
irrespective of the setting in other subflows. For an SDU with
multiple subflows with the ‘yes’ setting, there may be one error
indication per subflow, or, if there is only one error indication
per SDU, it indicates that an error was detected in at least one of
these subflows. More examples are described in section 8.1 and 8.2.

At the network layer, there are no error checksums or erroneous PDU
processing. The packet, whether correct or corrupted, will be
relayed to the transport layer.

The transport layer enables the UDP-Lite checksum, which is a
partial data checksum. When bit errors are located inside vital-

Zhikui Chen Expires – September 2007 [Page 11]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

data, the packet will be dropped by UDP-Lite. Otherwise, the packet
will be passed to the application.

7. Context Transfer during Handover

Context transfer is a technology to support the efficient handover
and interoperable solutions for mobile services supported by the
Internet access network [6] and to support the integration of
different wireless networks in the Internet infrastructure based on
interoperable services. In other words, the aim of context transfer
is to re-establish the services in the case of handovers
efficiently without requiring the mobile host to explicitly perform
all protocol flows for those services from scratch. The context
transfer protocol [7] is based on messages to initiate and
authorize context transfer as well as messages transferring
contexts prior to, during and after handovers.

At a minimum, a context transfer can be used to replicate the
configuration information needed to establish the respective
protocols and services. In this draft, the RoHC and AFEC
configurations are transferred to the new access router during
handover.

Also, context transfers provide the capabilities to replicate state
information, allowing state protocols and services at a new node to
be activated along the new path with less delay and less signalling
overhead. In the case of RoHC and AFEC during handover, all RoHC
and AFEC state information should be transferred to the new node,
such as AFEC encoding rate, BER, RoHC compression profile and its
state variables, which will be used to decode the incoming RoHC
headers.

8. Examples of UMTS, Blurtooth and WLAN

In each example, parameters configuration, AFEC data encapsulation
and erroneous SDU delivery across network layers are separately
described in details.

8.1 UMTS

. Configuration Set-Up

An offer/answer Session Description Protocol, SDP [9], is used
to describe the user request specifications. The Session
Initiation Protocol, SIP[10], is used to carry the SDP

Zhikui Chen Expires – September 2007 [Page 12]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

encapsulated user specifications to the called MT or the
server.

The UDP-Lite usage information can also be configured using
SDP at both caller and callee. When the sender is requested to
use UDP-Lite, a socket interface “setsockopt” is activated to
deliver UDP-Lite protocol and multimedia UDP-Lite coverage to
the kernel space. UDP-Lite coverage is required to be
abstracted by a multimedia encoder.

. Data Encapsulation

In the EFR byte described in section 0, if L=0, the redundancy
length field occupies 1 byte, i.e., the parity code length is
less than 256 bytes; if L=1, the redundancy length is larger
than 255 bytes. Therefore, the data, to be encapsulated into
PDCP packet, is ordered EFR byte (L bit, encoding EFR bits),
redundancy length byte(s), parity code bytes, RoHC data, and
multimedia payload. The AFEC algorithm is described in section
3.

The protected compressed data is encapsulated into PDCP as RFC
3095 data. A PDCP PID (Packet Identifier) specifies the RoHC
data which is protected (see Figure 2), where n is the number
of PID values already assigned to other protocol packet types
[4].

+-----+--------------+--------------------------------+
| PID | Optimization | Packet type |
+--------------------+--------------------------------+
| n+1 | RFC3095 | RFC3095 packet format |
+--------------------+--------------------------------+
|n+2 | RFC3095 | RFC3095 packet format with FEC |
+-----+--------------+--------------------------------+
Figure 2: Mapping of Values for RFC Header Compression
Protocol

. Erroneous SDU Delivery

This could be configured by the application control, as
described in section 5. In the upper sublayer, the received
erroneous SDUs will be reassembled into a PDCP PDU. Then, the
corrupted packet will be delivered to the RoHC/AFEC sublayer;
bit errors in the vital data of a received PDU will be
corrected if possible. The recovered PDUs or PDUs without
errors will recover its protocol overhead via RoHC

Zhikui Chen Expires – September 2007 [Page 13]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

decompression. If there is still a bit error in the decoded
overhead, the decoded packet will be discarded and a feedback
packet will be sent to the RoHC encoder to ask it to send a
refresh frame and to increase the EFR value.

If the decode overhead is correct, the packet will be
delivered to the transport layer via the IP layer as there are
no error checksums in the IP layer.

The transport layer enables the UDP-Lite checksum, which is a
partial data checksum. When bit errors are located inside
vital data, the packets will be dropped by UDP-Lite. Otherwise,
the packet will be passed onto the application.

The application decoder will deal with the received erroneous
packets using various error concealment techniques.
Furthermore, a context-based error detection and resilience
approach, which deals with bit errors within erroneous packets,
could be used to decode the erroneous packets[15].

8.2 Bluetooth

. Configuration Set-Up

As for UMTS, RoHC/AFEC can be configured using SIP/SDP. On the
other hand, it can also be configured during wireless
connection establishment. For example, in a Bluetooth
connection set-up, a Bluetooth user profile “pand“ tool can
transfer the user’s RoHC and AFEC configurations to the radio-
link layer at both the MT and AR ends; for more details see
[11].

If the RoHC or AFEC configuration value is set to 0, this
means that there is no RoHC or AFEC module implemented. The
RoHC configuration value corresponds to header compression
profiles. AFEC configuration value corresponds to FEC encoding
rate, whose maximum value is 127%, see section 4.

. Data Encapsulation

Bluetooth Network Encapsulation Protocol (BNEP) encapsulates
packets from various networking protocols, which are
transported directly over the Bluetooth Logical Link Control
and Adaptation Layer Protocol (L2CAP). BNEP removes and
replaces the Ethernet header with the BNEP header. Finally,
both the BNEP header and the Ethernet payload are encapsulated
by L2CAP and are sent over the Bluetooth media, see [5].

Zhikui Chen Expires – September 2007 [Page 14]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

A general BNEP Ethernet packet type header format is shown in
th
Figure 3. Here the 8 bit of the first byte of a BNEP packet
is used to describe whether or not it has an extension header.
If its value is 0, then there is no extension header,
otherwise it has an extension header.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BNEP Type |0| Destination Address (Bytes 0-2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address (Bytes 3-5) |Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Bytes 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Address | Networking Protocol Type=0x800|Payload…… |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: BNEP General Ethernet Packet Type Header [5].

If AFEC is used to protect the vital data of both RoHC and
UDP-Lite, a BNEP extension header is used, which is described
in [5]. There are three extension types to encapsulate the
protected data in the BNEP packet format, as follows:

A. Only AFEC. BNEP has an extension for AFEC to protect
uncompressed protocol headers and critical data, such as
RTP, UDP-Lite/UDP, IP headers and UDP-Lite critical data -
th
see Figure 4. Extension Type is defined as 0x01. The 8
bit is used to state if an extension header exists.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BNEP Type |1| Destination Address (Bytes 0-2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address (Bytes 3-5) |Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Bytes 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Address | Networking Protocol Type=0x800|Extension Typ|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload of AFEC as descried in Figure 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: BNEP General Ethernet Packet Type Header [5].

Zhikui Chen Expires – September 2007 [Page 15]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

B. Only RoHC. BNEP has an extension for RoHC to protect the
compressed protocol headers (RoHC data). Extension Type is
defined as 0x02. The encapsulated packet has the same
format as in Figure 4.

C. Both RoHC and AFEC. BNEP has an extension for AFEC and RoHC
to protect the compressed protocol headers (RoHC data).
Extension Type is defined as 0x03. The encapsulated packet
has the same format as in Figure 4.

. Erroneous SDU Delivery

With Bluetooth, there are two ways to deal with erroneous
SDUs. One is in the Baseband, and the other is provided by
L2CAP [8].
In the Baseband, there are seven types of packets that could
be used to deliver data from the upper layer to its peer. They
are DM1, DH1, DM3, DH3, DM5, DH5 and AUX1. Except for AUX1,
all have 16 bit CRCs generated over the payload. Thus, AUX1
can be used to deliver data that does not require CRC
protection. Although other packet types provide CRC
protection, it is possible for errored packets to pass the CRC
checksum operation and, due to a residual bit error, are still
delivered to the upper layers.

An entity, namely, flush timeout, defined for the ARQ
retransmission time, can be configured to some value, for
which the default is infinite to re-transmit until physical
link loss occurs, just like a “reliable channel”. It is
possible to produce an incomplete PDU and deliver it to the IP
layer.

L2CAP provides an enhanced error detection and retransmission
capability to reduce the probability of undetected errors
being passed up to the application and to recover from the
loss of portions of the user data when the Baseband Layer
performs a flush on the ACL-U. In other words, if the delivery
of erroneous L2CAP PDUs is enabled, the upper layer could
receive the corrupted or incomplete L2CAP PDUs, as explained
in [8].

8.3 WLAN

In considering IEEE802.11 MAC, a MAC-Lite scenario is proposed, in
which a packet from the upper layer is divided into two parts, a
bit-error sensitive and a non-sensitive part. The sensitive part

Zhikui Chen Expires – September 2007 [Page 16]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

will be checked using a Frame Check Sequence (FCS), as defined in
802.11. The first two of the above mentioned three MAC features
will be used for the bit-error sensitive MAC part. For a failed FCS
frame, retransmission will be necessary. For non-sensitive parts,
FCS is disabled and a value of zero is assigned. When the receiver
receives a MAC SDU, its FCS will be checked and if its value is
non-zero; the received part is a bit-error sensitive part.
Otherwise, if its value is zero, the received part is non-sensitive,
and a positive ACK will be directly returned to the sender. In this
case, a retransmission is not required, even if it is corrupted.

At the receiver, if both sensitive and non-sensitive parts are
received within the retry limit of the sensitive part, the two
parts will be reassembled and delivered to the upper layer. There
are three schemes to deal with the sensitive part. The first
scenario, namely, MAC-Lite1, is described as follows: The sensitive
part is correctly received with or without retransmission, the non-
sensitive is also received which may be erroneous. The reassembled
packet may be corrupted. The second scenario, namely MAC-Lite2,
retains the received sensitive part after the limited
retransmission, even if it is corrupted, and the two parts are
reassembled and delivered to the upper layer. i.e., the reassembled
packet is erroneous. The third case is to discard the two parts,
after the retry limit, the sensitive part is not correctly received,
i.e., the original entire frame will be dropped.

Simultaneously, according to the MAC protocol, each part can be
further divided into required MAC SDUs. For the MAC-Lite1 scenario,
when the sensitive part is fragmented, only if all the fragments
are successfully received, the original packet can be reconstructed.
Otherwise, even if a fragment is not received after the retry limit,
all fragments will be discarded. Furthermore, the corresponding
non-sensitive fragment will also be discarded. For the MAC-Lite2
scenario, after the retry limit, all fragments of the sensitive
part, whether correct or corrupted, are reassembled. If the non-
sensitive part is fragmented, the FCS of each fragment will be
disabled. Then, all received fragments will be simply reassembled
into the non-sensitive part.

Thus, the reassembled upper layer packet may be erroneous in both
MAC-Lite1 and MAC-Lite2. For the MAC-Litre1, the possible bit-
errors are located in the non-sensitive part. For MAC-Lite2, the
possible bit-errors are located in both parts. Of course, there may
be one or more residual bit errors in the sensitive part. Under a
given number of retransmissions (retry limit), the corrupted SDU
may be recovered. After a given number of retransmissions, the
third SDU is still corrupted, which can possibly be corrected using
proposed AFEC. Anyway, the corrupted SDU, which is non-sensitive,

Zhikui Chen Expires – September 2007 [Page 17]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

will not be retransmitted. The application can deal with it. For
futher details, please refer to literature [16].

At session establishment, an offer/answer Session Description
Protocol, SDP [9], is used to describe these user end-to-end
configurations. Signalling Initial Protocol (SIP) is used to carry
the SDP data. When the server receives the terminal requests,
feedback will be returned to the terminal as to whether the defined
services are accepted or not. If the defined services are not
accepted, the terminal is required to redefine its services, until
a successful QoS negotiation has been reached. Those distributed
parts of the application may choose the mutually supportable
configurations, which then become actual configurations for the
application.

9. Security considerations

The security considerations are the same as in RFC 3452[14].

10. References

[1] T. Wiegand (ed.), “Final Committee Draft: Editor’s Proposed
Revisions,” Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T
VCEG, JVT-F100, February 2003.
[2] C. Bormann, C. Burmeister, M. Degermark, et al, Robust header
compression RoHC),” IETF, RFC 3095, July 2001.
[3] L-A. Larzon, M. Degermark, S. Pink, et al, “The Lightweight User
Datagram Protocol (UDP-Lite)”, IETF RFC 3828, July 2004.
[4] Packet Data Convergence Protocol (PDCP) specification, 3GPP
Technical specification 25.323, 2003-v6.
[5] Bluetooth Core Specification 1.2, Feb. 2003.
[6] J. Kempf (ed), Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network,
RFC3374, Sept.,2002.
[7] J. Loughney (ed), Context Transfer Protocol (CXTP),
RFC4067,July 2005.
[8] Bluetooth Core Specification 1.2, Feb. 2003
[9] J. Rosenberg, H. Schulzrinne, An Offer/Answer Model with the
Session Description Protocol (SDP), RFC3264, June 2002.
[10] J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF
RFC 3261, June, 2002.
[11] Z. Chen, P. Christ, Improving the Radio Link Layer QoS
Performance for Bluetooth Real-time Video Communications,
WTS2005.
[12] J. Rosenberg, H. Schulzrinne, An Offer/Answer Model with the
Session Description Protocol (SDP), RFC3264, June 2002.

Zhikui Chen Expires – September 2007 [Page 18]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

[13] 3GPP TS 23.107, “Quality of Service (QoS) concept and
architecture”, v6.30, June, 2005.
[14] Luby,M., et al, RFC 3452, 3GPP TS 23.107, “Forward Error
Correction (FEC) Building Block”, Dec., 2002.
[15] Z. Chen, Y. tang, P. Christ and Y. Qiu, H264 Based Video
Transmission in Cross-layer Wireless Communication Systems,
WWC2006, USA, May, 2006.
[16] Z. Chen, Y. tang, J. Jaehnert, Analysis and Application of a
QoS Scheme for WLAN Real-Time Video Communications, WMC2006,
Germany, July, 2006.

Author's Address

Zhikui Chen
Universitaet Stuttgart
Allmandring 30, 70550 Phone: +49-711-68565871
Stuttgart, Germany Email: zchen@rus.uni-stuttgart.de

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.

Zhikui Chen Expires – September 2007 [Page 19]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
March 2007

Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Zhikui Chen Expires – September 2007 [Page 20]