Internet Draft Zhikui Chen
Document: draft-chen-afec-00.txt Universitaet Stuttgart
Expires:
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 Expires - [Page 1]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................4
2.1 Acronyms..................................................6
3. Adaptive FEC Algorithm........................................7
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.................10
7. Context Transfer during Handover.............................11
8. Examples of UMTS and Blurtooth...............................12
8.1 UMTS.....................................................12
8.2 Bluetooth................................................13
9. Security considerations......................................16
10. References..................................................16
Author's Address.............................................17
Intellectual Property Statement..............................17
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.
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
Zhikui Chen Expires - [Page 2]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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
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.
Zhikui Chen Expires - [Page 3]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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.
Loss propagation
Loss of headers, due to loss of or damage to previous
header(s) or feedback.
Error detection
Zhikui Chen Expires - [Page 4]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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.
Residual error
An error introduced during transmission and not detected by
the lower-layer error detection schemes.
Robustness
Zhikui Chen Expires - [Page 5]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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.
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.
Zhikui Chen Expires - [Page 6]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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.
3. Adaptive FEC Algorithm
An 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. For the FEC
algorithm, a generalized Reed-Solomon (GRS) algorithm is proposed
in [11]. 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.
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
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
Zhikui Chen Expires - [Page 7]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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).
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
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| EFR |FEC Length (1 or 2 bytes) | FEC code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|… FEC code | ... RoHC ... | Coverage ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|… Coverage | Non-vital of UDP-Lite … |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Protected RoHC Packet Format
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.
Zhikui Chen Expires - [Page 8]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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:
. 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
Zhikui Chen Expires - [Page 9]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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:
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
Zhikui Chen Expires - [Page 10]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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-
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
Zhikui Chen Expires - [Page 11]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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 and Blurtooth
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
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].
Zhikui Chen Expires - [Page 12]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
+-----+--------------+--------------------------------+
| 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
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
Zhikui Chen Expires - [Page 13]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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].
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
Zhikui Chen Expires - [Page 14]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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].
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
Zhikui Chen Expires - [Page 15]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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].
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 - [Page 16]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
[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.
Author's Address
Zhikui Chen
Universitaet Stuttgart
Allmandring 30, 70550 Phone: +49-711-68565871
Stuttgart, Germany Email: zchen@rus.uni-stuttgart.de
Intellectual Property Statement
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.
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.
Disclaimer of Validity
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 AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
Zhikui Chen Expires - [Page 17]
An Adaptive FEC to Protect RoHC and UDP-Lite Video Vital Data
September 2006
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhikui Chen Expires - [Page 18]