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. 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. 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 Copyright (C) The IETF Trust (2007). 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]