Network Working Group Ghyslain Pelletier, Ericsson INTERNET-DRAFT Sweden Expires: January, 2002 July 20, 2001 Link-Layer Assisted ROHC Over CDMA2000 Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document defines implementation specifications and guidelines for the Link-Layer Assisted ROHC profile [LLAROHC] over CDMA2000 cellular links. The purpose of this document is to apply this profile for efficient, transparent and robust header compression while using the CDMA2000 link layer characteristics optimally. Its objective is to remain flexible with regards to robustness, complexity and spectral efficiency considerations. In addition to [LLAROHC] it defines logic, parameters and procedures for the use of header-free packets over CDMA2000 links. Pelletier [Page 1] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 Table of contents 1. Introduction.................................................... 2. Terminology..................................................... 3. Overview of the link-layer assisted profile over CDMA2000 links. 3.1. CDMA2000 system overview..................................... 3.1.1. CDMA2000 architecture overview....................... 3.1.2. CDMA2000 link layer characteristics.................. 3.1.3. Typical CDMA2000 voice encoder rates................. 3.2. Functionality provided by the link layer to LLAROHC......... 4. Link-Layer Assisted ROHC over CDMA2000 links..................... 4.1. Operating assumptions....................................... 4.2. Architecture overview....................................... 4.3. Initialization.............................................. 4.3.1. Header compression setup.. ........................... 4.3.2. Agreement on optimistic approach...................... 4.3.3. Context IDentifiers (CID) ............................ 4.3.4. Packet sizes.......................................... 4.3.5. Padding............................................... 4.3.6. Fast Context Initialization........................... 4.4. LLA MAC logic at the compressor side........................ 4.4.1. Reception of packets from the LLAROHC RTP compressor.. 4.4.2. Sending the NHP packet................................ 4.4.3. Sending the RHP packet................................ 4.4.4. Sending a CCP or a CSP packet......................... 4.4.5. Assembling the packet for delivery.................... 4.4.6. Handling packets larger than MAX_SIZE_ALLOWED......... 4.4.7. Handling of ROHC segmented packets.................... 4.4.8. False sequence detection for NHP packets.............. 4.4.9. Delayed packet reception.............................. 4.4.10.Congestion handling................................... 4.5. LLA MAC logic at the decompressor side...................... 5. Implementation Guidelines....................................... 5.1. Periodic context validation and speech bursts .............. 5.2. Handling the non-octet aligned physical frame format........ 6. Security considerations......................................... 7. Acknowledgements................................................ 8. References...................................................... 9. Author's addresses.............................................. Pelletier [Page 2] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 1. Introduction Header compression is a technique to compress and transparently decompress the header information of a packet on a per-hop basis. Several efforts have been made to improve efficiency over bottleneck wired links [VJHC, IPHC] as well as over low bandwidth wireless links with high error rates [ROHC]. Existing air interfaces such as GSM and IS-95 will be used in all-IP networks, adding new implications to the header compression issue. These air interfaces are less flexible with radio bearers optimized for specific payload sizes. This means that not even a single octet of header can be added without using the next higher fixed packet size of the link and this is obviously very costly. For the already deployed speech vocoders, the spectrum efficiency over these links will thus be low compared to the existing circuit switched solutions. For deployment reasons, it is important to also achieve efficiency with these already existing vocoders and air interfaces, such as GSM and IS-95, with minimal effects on spectral efficiency. To this purpose was the Link-Layer Assisted ROHC profile (LLAROHC) proposed. [LLAROHC], extending the ROHC RTP profile, allows the sending of header-free packets when the link layer can provide in-order delivery, packet loss detection and packet type identification. It puts additional requirements on the lower layer to allow the decompressor to infer some of the information needed to maintain robust and transparent header compression. This is possible because of the nature of the synchronized radio bearer. LLAROHC also specifies interfaces between the ROHC component towards the lower layer at both ends of the transmission link. Finally, it describes methods to compress headers so that during most of the normal operation only header-free packets are transmitted over the air interface. These header-free packet account for most of the traffic. The Link-Layer Assisted ROHC profile does not provide link layer specifications. The purpose of this document is to specify how to implement the LLAROHC profile over CDMA2000 links. Pelletier [Page 3] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 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. BER Bit Error Rate BSC Base Station Controller CCP Context Check Packet as defined in [LLAROHC] CRC Cyclic Redundancy Check CSP Context Synchronization Packet, as defined in [LLAROHC] HC Header Compressor HD Header Decompressor LCP PPP Link Control Protocol (defined in RFC 1661) LLA MAC LLAROHC adaptation to the CDMA2000 MAC layer LLAROHC Link Layer Assisted ROHC profile MAC Media Access Control MSB Most Significant Bit MN Mobile Node NHP No Header Packet NCP PPP Network Control Protocol (defined in RFC 1661) PDSN Packet Data Serving Node PDU Protocol Data Unit PL Physical Link PPP Point-to-Point Protocol (RFC1661) RHP ROHC Header Packet (either a CCP or a RRP packet) ROHC RObust Header Compression RRP ROHC RTP Packet as defined in [ROHC, profile 1] VoIP End-to-end Voice over IP ROHC RTP ROHC RTP in this document refers to the IP/UDP/RTP profile as defined in [ROHC]. Pelletier [Page 4] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 3. Overview of the Link-Layer Assisted profile over CDMA2000 links The Link-Layer Assisted ROHC profile is a generic scheme applicable to any link providing the necessary functionality for the use of header-free packets in an efficient, transparent and robust way as described in [LLAROHC]. This document specifies how to implement this scheme over CDMA2000 links according to the LLAROHC profile. The following sections introduce the relevant architectural and operational characteristics of the CDMA2000 system before providing an overview of the general ideas behind implementation specifications and guidelines for use of LLAROHC in the system. 3.1. CDMA2000 system overview This section provides a simplified overview of the CDMA2000 system and its characteristics relevant to header compression. 3.1.1 CDMA2000 architecture overview Figure 1 shows the protocol stack view of the IP traffic path in the CDMA2000 system with a LLAROHC header compression implementation. MN BSC PDSN +-------------+ +-----+ | RTP | | RTP | +-------------+ +-----+ | UDP | | UDP | +-------------+ +---------------------+ +-----+ | IP | | IP | | IP | +-------------+ +--------------++-----+ +-----+ | ROHC RTP | | ROHC RTP || | | | +-------------+ +--------------+| | | | | LLAROHC | | LLAROHC || | | | +-------------+ +--------------+| | | | | LLACDMA2K | | LLACDMA2K ||LINK | |LINK | +-------------+ +---------------+ +--------------+| | | | | PPP| NO PPP | | RELAY | | PPP| NO PPP ||LAYER| |LAYER| +-------------+ +----------++---+ +--------------+| | | | | LLA MAC | | LLA MAC ||GRE| | GRE || | | | +-------------+ +----------++---+ +--------------+| | | | | MAC | | MAC ||IP | | IP || | | | +-------------+ +----------++---+ +--------------++-----+ +-----+ | AIR LINK |==| AIR LINK ||PL |==|PHYSICAL LINK || PL |==| PL | +-------------+ +----------++---+ +--------------++-----+ +-----+ Fig.1: Stack view of IP traffic path in CDMA2000 system with LLAROHC As shown in the figure, within a CDMA2000 system it cannot be assumed that the ROHC RTP implementation will be physically co-located with the synchronous radio bearer implementation, i.e. it must be assumed Pelletier [Page 5] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 that the base station is remote from the ROHC RTP compressor. This has significant implications on the introduction of a header compression system that makes specific use of the properties of the synchronized bearer. The module implemented close to the synchronous bearer will be referred to as the LLA MAC, i.e. the LLAROHC to CDMA2000 MAC layer adaptation module. LLACDMA2K represents the additional functionality required within the LLAROHC RTP implementation, while the LLA MAC contains most of the functionality specific to the LLAROHC implementation for CDMA2000. 3.1.2. CDMA2000 link layer characteristics The channel used in CDMA2000 for circuit-switched voice traffic is characterized by: - No link layer retransmissions - High priority channel - BER (1%) - Fixed frame sizes (16, 40, 80 and 171 bits) - Synchronized channel, 20ms time intervals The most relevant characteristics to the design of the LLAROHC profile over CDMA2000 are the fixed frame sizes together with the synchronized and non-retransmitting nature of the physical channel. 3.1.3 Typical CDMA2000 voice encoder rates Typical CDMA2000 voice encoders have been designed to transmit small payloads during most of the speech connection. The following table present the typical payload sizes generated: Rate Activity % Payload size (bits) Full 20 171 Half 20 80 Quarter 10 40 Eighth 50 16 Table 1: Frame size distribution for a typical vocoder in CDMA2000 From the table, the most frequent transition introduced by the need to send extra octets will likely happen between the eight rate (from 16 bits payload) and the quarter rate (to 40 bits payload). Noteworthy for the LLAROHC for CDMA2000 implementation is that the rate of the encoders matches the frame rate, or PDU sizes, at the physical level. Pelletier [Page 6] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 3.2. Functionality provided by the link layer to LLAROHC [LLAROHC] states the functionality to be provided by the link layer to the LLAROHC implementation to allow packet type identification, replacement of the sequence number and replacement of the CRC. Packet type identification may be provided through the use of a leading sequence which consist of already existing ROHC padding. Although this approach implies some additional overhead, the need for a leading sequence is constrained to the RRP packet type, which is deemed to be used very seldom in comparison to the NHP traffic during a typical VoIP connection. Furthermore, there is currently no other identified alternate mechanism within the CDMA2000 system to provide this functionality. The sequence number is replaced by packet loss detection at the MAC layer under the ROHC decompressor through the interface specified in [LLAROHC section 4.2.2]. This is done by using explicit detection of damaged packets over the physical medium from the link layer and through the use of the CCP packet as an indication of packet loss before the compressor. The CRC functionality is replaced by this same packet loss detection coupled with the fact that no errors can damage a header which is not sent for the case where header-free packets are used. However, to detect also unexpected errors, periodical context checks should also be performed. 4. Link-Layer Assisted ROHC over CDMA2000 links This section describe the implementation specifications to support the LLAROHC profile in the CDMA2000 system. 4.1. Operating assumptions CDMA2000 systems have special characteristics from which we derive the following assumptions, in addition to those described in [ROHC] and [LLAROHC]. Reordering If present, it is assumed that the channel between the ROHC compressor and the LLA MAC may reorder packets (i.e., there is no assumption that the LLA MAC will receive packets in order). Note that out-of-order delivery will have an impact on the compression efficiency of the LLA ROHC profile and should be minimized. Reliability If present, the channel between the ROHC compressor and the LLA MAC Pelletier [Page 7] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 is not assumed to be reliable. Packet losses may therefore occur on this channel, but residual bit error rates should be negligible. On-time delivery is not assumed either although expected (i.e., some packets may be delayed so that they are late for transmission over the air I interface). Note that packet losses will have an impact on the compression efficiency of the LLAROHC profile and should obviously be minimized. Duplication If present, it is assumed that a channel between the ROHC compressor and the LLA MAC may duplicate packets (i.e., there is no assumption that the LLA MAC will receive only one copy of the same packet), although duplicates are expected to be handled by the channel itself. The handling of possible duplicates is left to implementations. Link layer channel The channel used to transport header compression traffic is assumed to not introduce any additional overhead, for example for reliability or for any link layer framing additional to the one already present at the physical layer. 4.2. Architecture overview Figure 2 shows the various components needed for an implementation of the LLAROHC profile in CDMA2000. It is separated into layers as defined in [ROHC RTP], [LLAROCH] and this document [this]. +---------------------+ +---------------------+ [ROHC RTP] | ROHC RTP HC | | ROHC RTP HD | +---------------------+ +---------------------+ [LLAROCH] | LLAROHC Profile | | LLAROHC Profile | +=====================+ +=====================+ [LLAROCH] | ROHC-LL | | LL-ROHC | [this] | interface | | interface | +=====================+ +=====================+ [this] | LLA MAC | | LLA MAC | | implementation | | implementation | +---------------------+ +---------------------+ | CDMA2000 MAC Layer | | CDMA2000 MAC Layer | +=====================+ +=====================+ | | +------>---- CHANNEL ---->-----+ Fig.2: Overview of the LLAROHC over CDMA2000 implementation In [LLAROCH section 4.2.1], a generic interface between the LLAROHC RTP compressor and the lower layer is specified. The CDMA2000 link layer does not currently provide all the functionality needed to fulfill this specification. New functionality, represented by the LLA Pelletier [Page 8] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 MAC, is therefore necessary and is here described in [section 4.4]. It uses the available functionality from the CDMA2000 MAC layer and may be implemented together with the LLAROHC compressor as a single entity, although this is not required and not always possible in all CDMA2000 systems. Similarly, [LLAROCH section 4.2.2] describes a generic interface between the lower layers and the LLAROHC RTP decompressor. The necessary functionality is also here described in [section 4.5]. It should be implemented together with the ROHC decompressor as a single entity to minimize complexity within a mobile terminal. 4.3. Initialization This section describes profile specific initialization steps for the LLAROHC instances. This section also specifies how parameters are set. 4.3.1 Header compression setup [PPP] may be used for the negotiation of ROHC parameters over the connection setup for header compression. Initialization of ROHC per channel parameters may be done as described in [ROHC section 5.1.1] and [ROHC PPP]. The physical establishment and release of the connection used for header compression traffic is outside the scope of this document. 4.3.2. Agreement on optimistic approach The principle behind the agreement between compressor and decompressor regarding the usage of the optimistic approach must be defined and the LLA decompressor MUST use the optimistic approach knowledge to detect possible context loss events [LLAROHC]. The compressor MUST send a fixed default value of three consecutive updates when a context change occurs. The decompressor MUST invalidate the context in the event of consecutive packet losses equal to or larger than this default value. 4.3.3. Context Identifiers (CID) The connection for LLAROHC traffic MUST be configured using SMALL CIDS and CID=0 MUST be reserved for LLAROHC traffic. This is necessary to omit the CID field in the ROHC header and still allow identification of the NHP packets. 4.3.4. Packet sizes The PREFERRED PACKET_SIZES parameter MUST be set according to the CDMA2000 link fixed frame sizes, i.e. the list provided MUST be Pelletier [Page 9] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 [16,40,80,168,176] and 176 MUST be for NHP packets only [see section 5.2]. The LARGE_PACKET_ALLOWED parameter MAY be set to true if large packets with headers are to be treated according to [section 4.4.6]. The resulting effect will be that proper context will be maintained at the decompressor to the expense of dropping the packet. The LARGE_PACKET_ALLOWED parameter MAY be set to false and packets larger than the maximum size specified using the PREFERED PACKET SIZES [LLAROHC section 5.1.1] parameter will be transmitted as segmented packets according to [section 4.4.7]. These packets will be delivered as segmented ROHC packets. 4.3.5. Padding The ALWAYS_PAD parameter MUST be set in order to request that all RHP packets be padded. A CDMA2000 LLA MAC implementation uses one or more octets as the leading sequence to identify RHP packets. Padding does not introduce new complexity since it is already part of any ROHC RTP implementation [ROHC section 5.2]. 4.3.6. Fast Context Initialization Initial establishment of the decompressor context SHOULD be performed using the CSP, as the initial packets will always be larger than MAX_SIZE_ALLOWED, according to procedure b) of [section 4.4.6]. 4.4. LLA MAC logic at the compressor side This section describes the logic to be used inside the implementation of the LLA MAC module on the compressor side. This module receives parameters from the ROHC RTP compressor as stated in [LLAROHC section 4.2.1]. It always receive an RHP with an indication of segmentation, a CCP, an RTP Sequence Number and possibly an NHP. Because the presence or absence of the NHP packet is part of the logic of the LLA MAC module, all parameters corresponding to the same packet to be transmitted MUST be ignored by the LLA MAC until they are all received reliably. How these parameters are transmitted between the compressor and the LLA MAC module is an implementation issue and is therefore outside the scope of this document. 4.4.1. Reception of packets from LLAROHC RTP header compressor The following steps MUST be performed by the LLA MAC upon reception of a packet delivery from the ROHC header compressor: a. Keep a copy of CCP and RTP SN The LLA MAC MUST always keep a copy of the received CCP with the corresponding RTP Sequence Number. Pelletier [Page 10] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 b. Decide which packet needs to be sent If the Context Check Counter is starved, an RHP packet SHOULD be sent according to [section 4.4.3], otherwise refer to section [LLAROHC Section 4.2.1]. 4.4.2. Sending the NHP packet If it was determined that the NHP packet should be sent, then the following MUST be performed: a. Check for false Leading Sequence according to [section 4.4.8] b. Assemble the packet according to [section 4.4.5] c. Decrement the Context Check Counter Note that if any of these operations determine that an RHP packet must be sent, then the subsequent operation(s) MUST NOT be performed. 4.4.3. Sending the RHP packet If it was determined that the RHP packet will be sent, then the following MUST be performed: a. Verification of RHP segmentation indicator If an indication of segmentation for the RHP packet was received, then the segmented packet is sent as described in [section 4.4.7]. Otherwise, the packet is assembled according to [section 4.4.5]. b. Reset the Context Check Counter 4.4.4. Sending a CCP or a CSP packet If it was determined that a CCP or a CSP packet will be sent, then the following MUST be performed: a. Assemble the packet This is done according to section 4.4.5. As the CCP and the CSP are both RHP packets, a leading sequence will be added during assembly to allow the LLA MAC module at the decompressor side to detect the presence of the header. Because codecs may generate valid 16 bits payload sent as NHP and because of the risk of collision with the leading sequence [section 4.4.8] or the packet type octet, this unfortunately forces a rate transition when sending a CCP packet. It is noted that CDMA2000 defines an empty frame when no speech data is available for sending. This frame is referred to as a filler frame and has a size of 16 bits, all bits set to 1. As LLAROHC requires that no extra packet be artificially inserted by Pelletier [Page 11] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 the lower layers in the header compression flow, the LLA MAC implementation will make a CCP packet available to prevent the generation of a filler frame as stated in [section 4.4.9]. b. Reset the Context Check Counter 4.4.5. Assembling the packet for delivery If the packet cannot fit is larger MAX_SIZE_ALLOWED, packets are handled as described in [section 4.4.6]. If the packet delivered is of size 168 bits, the packet must be padded to fit the physical frame size of 171 bits. In the case where the packet delivered is of size 176 bits, then it must be stripped of the last 5 padding bits to fit the physical frame of 171 bits. Otherwise the packet already matches one of the possible physical frame size and is sent directly. Section 5.2 provides additional considerations regarding the non- octet aligned nature of the CDMA2000 physical frame format. 4.4.6. Handling packets larger than MAX_SIZE_ALLOWED In the case where the calculation of the packet size to be transmitted is larger than the maximum size of a physical frame, the implementation must decide between the two following options: a. Segment the packet using ROHC segmentation This is done according to [section 4.4.7]. b. Discard the packet and send the CSP The packet for which the calculation of the size was made is discarded and a CSP is sent according to [section 4.4.4]. Recall that the CSP contains repair information by carrying a ROHC header which will maintain proper context at the decompressor, as described in [LLAROHC]. This will readily repair the context at the decompressor after a detection of packet loss is signaled from the reception of the CSP itself. These two alternatives represent a tradeoff between robustness and spectral efficiency respectively. 4.4.7. Handling of ROHC segmented packets In the case where the RHP packet is to be sent and was delivered as a segmented ROHC packet, an implementation MUST handle the resulting congestion as defined in [section 4.4.10]. Pelletier [Page 12] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 4.4.8. False sequence detection for NHP packets The false sequence problem, defined as the case where the payload to be sent as an NHP coincidentally begins with the same bit pattern as the defined leading sequence, MUST be detected since it will impair efficiency by having the decompressor treat this packet as a packet with a ROHC header. This is to prevent the payload of such a packet to be used as with a corrupted reduced version of the RTP payload. This payload would then be passed to the application. The first bits of the NHP payload MUST be examined prior to transmission. If the pattern matches the ROHC padding and therefore could be interpreted by the receiving end as a false leading sequence than the NHP MUST not be sent and an RHP MUST be sent instead. 4.4.9. Delayed packet reception In the event where no packets are received from the ROHC compressor on time for transmission, this is handled by sending the CCP packet of the previous packet sent which was kept by the LLA MAC instance. The CCP is sent according to [section 4.4.4] and will prevent the artificial insertion of new packets by the link layer. The CCP MUST be interpreted as a packet loss by the LLA MAC at the compressor side. 4.4.10. Congestion handling Packet dropping might be needed to transmit a segmented ROHC packet. The following MAY be performed: a. The first segment is assembled and transmitted according to [section 4.4.5]. b. Remaining segment(s) is transmitted over the same connection in subsequent time interval(s) according to [section 4.4.5], while the packet delivered by the ROHC compressor corresponding to this time slot is be discarded. 4.5. LLA MAC logic at the decompressor side This section describes the logic inside the implementation of the LLA MAC module at the decompressor side. This module receives the packet transmitted over the air interface from the CDMA2000 link layer and delivers the following information to the ROHC HC [LLAROHC section 4.2.2]: the packet received with an indication of the presence of a header or an indication of packet loss together with an explicit sequence number. Pelletier [Page 13] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 This explicit sequencing space corresponds to the received physical frame sequence and timing. It MUST increment for each frame interval for which a IP/UDP/RTP packet is expected. The purpose of this explicit sequencing is to infer the number of packets that were lost, if any, at the decompressor. Because the packet type and the packet arrival sequencing are part of the decompression algorithm, all parameters corresponding to the same received packet MUST be ignored by the decompressor until they are all received reliably. How these parameters are transmitted between the LLA MAC module and the decompressor is an implementation issue and is therefore outside the scope of this document. Upon reception of a packet, the LLA MAC module MUST perform the following operations: a. Determination of the presence of a header As ROHC padding is used as leading sequence, the first bits of the packet received are examined to determine if a leading sequence is present. If present, the indicator for the presence of a header MUST be set. b. Determination of packet loss The indicator of packet loss MUST be set if the packet received contains a header and the packet type is CCP or CSP, or upon explicit notification from the physical link layer that the packet was damaged. c. Delivery of the packet and other parameters to the ROHC HD This is done according to the interface specified in [LLAROHC section 4.2.2] It is considered optional to remove the padding at the LLA MAC. Delivery of the packet with or without the padding will be properly handled by the ROHC decompressor. Optionally, an implementation SHOULD combine the LLA MAC with the ROHC implementation to reduce complexity whenever possible. 5. Implementation Guidelines 5.1. Periodic context validation and speech bursts Implementations MAY delay a periodic context validation during a speech burst, i.e. during a full-rate NHP train, if it is not possible to transmit the RHP packet over the connection. There SHOULD be a maximum limit of [to be defined later] for which this validation may be delayed and the RHP SHOULD be sent as soon as possible. Pelletier [Page 14] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 5.2. Handling the non-octet aligned physical frame format As seen in table 1 [section 3.1.3], the full rate frame size of the CDMA2000 link is 171 bits. IP being octet aligned, this frame size introduces some additional considerations. This section introduces a solution to handle this characteristic in a generic manner not constrained to a specific application while being optimal for the EVRC codec. Bit 170 is defined as the decision bit. Noting that it corresponds to the reserved bit of the EVRC payload format [EVRC RTP], it is then assumed that this reserved bit is set (value=1) as its default assigned value from the EVRC standard. By considering the default assignment of the EVRC reserved bit, NHP packets may then be used even for the EVRC operating at full rate in order to increase the performance of the most common expected voice application within a CDMA2000 system. A size of 168 bits may be produced by the LLAROHC compressor from a typical CDMA2000 codec [EVRC RTP] operating at a speech rate smaller than the full rate (< 171 bits) combined with the presence of the IP/UDP/RTP compressed header. A size of 176 bits may be produced for the case of the codec operating at full rate where 5 padding bits are added to obtain octet alignment. This will only be delivered as an NHP packet by the LLAROHC compressor. For the case where the compressed packet size is equal to or larger than 168 bits, three different cases are identified: a. RRP or NHP of size 168 bits 0 1 2 3 ... 164 165 166 167 +---+---+---+---+---+---+---+---+---+ | X X X X ... X X X X | +---+---+---+---+---+---+---+---+---+ Packet Type RRP or NHP, size = 168 bits If the header compression algorithm outputs a packet of type RRP or NHP for which the size is equal to 168 bits, then the packet will be expanded using 3 padding bits to match the physical frame size. The decision bit is therefore not set. The packet is transmitted as per [section 4.4.5]. 0 1 2 3 ... 164 165 166 167 168 169 170 +---+---+---+---+---+---+---+---+---+---+---+---+ | X X X X ... X X X X | 0 0 | 0 | +---+---+---+---+---+---+---+---+---+---+---+---+ Packet Type RRP or NHP, padded to size = 171 bits, bit 170 not set Pelletier [Page 15] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 b. NHP of size 176 bits with rear padding and bit 171 is set 0 1 2 3 ... 166 167 168 169 170 171 172 173 174 175 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | X X X X ... X X X X | 1 | 0 0 0 0 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Packet Type NHP with rear padding, bit 170 is set, size = 176 bits If the header compression algorithm outputs a packet of type NHP of size equal to 176 bits AND bit 170 is set AND bits 171-175 are padding bits [EVRC RTP] then the NHP may be truncated to fit the physical frame length with the value of the decision bit remaining set. This typically corresponds to the case of the EVRC codec operating at full rate. 0 1 2 3 ... 166 167 168 169 170 +---+---+---+---+---+---+---+---+---+---+ | X X X X ... X X X X | 1 | +---+---+---+---+---+---+---+---+---+---+ Packet Type NHP, truncated to size = 171 bits, bit 170 is set c. NHP of size 176 bits, bit 171 is not set OR bits 171-175 are not rear padding 0 1 2 3 ... 166 167 168 169 170 171 172 173 174 175 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | X X X X ... X X X X | 0 | X X X X X | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Packet Type NHP not rear padded OR bit 170 not set, size = 176 bits If header compression results in a packet of type NHP of size equal to 176 bits AND the bit 170 is not set OR bits 171-175 are not padding bits, then the packet MUST be treated as a packet larger than MAX_SIZE_ALLOWED, according to [section 4.4.6]. Upon reception of a full rate frame, if the decision bit is set then it must be interpreted as the case where 5 padding bits were stripped from an original packet size of 176 bits before transmission. Otherwise 3 bits of padding were added from an original packet size of 168 bits before transmission. 6. Security considerations The security considerations of ROHC RTP [ROHC section 7] and of the Link-Layer Assisted ROHC profile [LLAROHC] also apply to this document. Pelletier [Page 16] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 7. Acknowledgements The authors would like to thank Ulises Olvera-Hernandez, Francis Lupien for their input regarding the CDMA2000 standards and Lars-Erik Jonsson, Krister Svanbro for their input regarding header compression issues. 8. References [LLAROHC] L. Jonsson, G. Pelletier, "A Link-Layer Assisted ROHC Profile for IP/UDP/RTP", July 2001, [ROHC] C. Bormann, "Robust Header Compression (ROHC)", RFC 3095, July 2001. [ROHC PPP] C. Bormann, "ROHC over PPP", March 2001, . [RTP-REQ] M. Degermark, "Requirements for IP/UDP/RTP Header Compression", RFC 3096, July 2001. [EVRC RTP] A. Li, "An RTP Payload Format for EVRC Speech",(work in progress), July 2001 . [VJHC] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", RFC 2507, February 1999. [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communications Magazine, Volume 7, number 4, pp. 20-25, August 2000. [IP] J. Postel, "Internet Protocol", RFC 791, September 1981. [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [UDP] J. Postel, "User Datagram Protocol", RFC 768, August 1980. [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. Pelletier [Page 17] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001 [TCP] J. Postel, "Transmission Control Protocol", RFC 793, September 1981. [ROCCO] L.-E. Jonsson, M. Degermark, H. Hannu, K. Svanbro, "RObust Checksum-based header COmpression (ROCCO)", Internet draft (work in progress), June 2000. 9. Author's addresses Ghyslain Pelletier Tel: +46 920 20 24 32 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 SE-971 28 Lulea Sweden EMail: ghyslain.pelletier@epl.ericsson.se This Internet-Draft expires January20, 2002 Pelletier [Page 18]