1. Source: Qualcomm Incorporated Contact: Ravindra Patwardhan, Jun Wang, George Cherian June 21 2010 Page 1 xHRPD Header Removal Support Notice © 2010. All rights reserved. Qualcomm Incorporated grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner ’ s name any Organizational Partner ’ s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner ’ s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner ’ s standards publication. Qualcomm Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner ’ s standard which incorporates this contribution. This document has been prepared by the Qualcomm Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Qualcomm Incorporated. Qualcomm Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the Qualcomm Incorporated other than provided in the copyright statement above.

2. Why Header Compression in xHRPD? Spectrum Efficiency: xHRPD air interface has limited bandwidth Especially important for applications with frequent and small packets, e.g VoIP. IPv4+UDP+RTP Header overhead = 40 bytes IPv6+UDP+RTP Header overhead = 60 bytes Make applications more robust against bit errors: The large size of the IP header makes packet loss due to air- link bit error more probable. Minimize delays: Applications may suffer from the additional transfer delay induced by the large IP header.

3. Field Classification: IPv4 total length IP fragment offset IP_ID VersionIHLtype-of-service TTL ProtocolIP checksum IP source address IP destination address normally constant redundant (link layer) Frequent change fragments force increment++ 081624 Flag

4. Field Classification: IPv6 Flow Label Hop Limit Payload Length VersionPriority IP source address (16 Octets) IP destination address (16 Octets) normally constant redundant (link layer) Frequent change fragments force increment++ 081624 Next Header Type

5. Field Classification : UDP destination portsource port UDP checksumUDP length constant redundant (link layer) always transmitted (if used) 081624

6. Field Classification : RTP RTP sequence numberV timestamp synchronization source (SSRC) PXCC Mpayload type contributing source (CSRC) CC = 0-15 constanttransmitted upon change (rare) redundant for EVRC/SMV payload increment ++ 081624

7. Design Overview Design applies to both HRPD and eHRPD On Reverse link, reuse the concept of cdma1x Header Removal Design (SO60) as much as possible: Phase I: The header removal performed between MS and (e)AN MS removes Air-Interface/RTP/UDP/IP headers Air-Interface/RTP/UDP/IP headers are recovered at the (e)AN Transparent to the PDSN/HSGW Phase II: The header removal performed between MS and PDSN/HSGW MS removes Air-Interface/RTP/UDP/IP headers Air-Interface headers are recovered at the (e)AN RTP/UDP/IP headers are recovered at the PDSN/HSGW The AN may need to provide link layer information to assist IP headers recovered at the PDSN/HSGW On Forward link: Uses ROHC U mode because: AT can not distinguish between packet loss and no packets received. There is limited bandwidth to send the feedback on reverse link Current ROHC design can be reused ROHC U mode Compressor is located either in (e)AN or PDSN/HSGW Page 7

8. Phase I Header Removal Options (Reverse Link) Page 8

9. Header Removal Protocol Stack Reverse Link (Header Removal Between MS and AN) Page 9

10. Header Compression Protocol Context Setup (ICI): Initializes the de-compressor context in the AN HRU in AT sends ICI message to AN HRU in AN sends ICI Ack to AT User Bearer HRU: HRU in AT removes headers (Compressor function) HRU in AN adds a header to each received codec frame (Decompressor function) HRL: HRL in AT makes sure in-order delivery of data frames over the air link every 20 ms HRL in the AN detects silent frame or packet losse over the wireless link and then indicates it to HRU in the AN 2 new Higher-Layer Protocol IDs defined for Flow Protocol 0x09 – Zero Header Compression (Initial Context) 0x10 – Zero Header Compression (Bearer) Page 10

11. How to Reconstruct VoIP headers? The HRU (Decompressor module) in the AN reconstructs the VoIP header based on: The static information of the Air-Interface/ RTP/UDP/IP header sent by the HRU (ICI) in the AT during the context setup Reconstruct header information: Air Interface header is reconstructed using context information provided by AT. RTP sequence number is reconstructed using link layer-assistance from the RLP layer. The HRL in RNC provides indication for good packet and packet received in error during the voice conversation. HRU increments the sequence number for every new packet (both good and error packets) received, with the initial RTP sequence number obtained from the Initial Context Setup. The HRU uses the error indication to increment the RTP sequence number, but no packet is sent to the higher layer. IP-ID is filled with the same value as the RTP sequence number. (Since the payload size of VoIP packets generated by the vocoder fits exactly into one physical layer packet, there is no IP fragmentation done on a VoIP packet and the IP-ID field can be set to any unique value for each packet.) RTP Time stamp: The HRL provides the HRU the CDMA timestamp (in units of 12 slots or 20 ms) for every new packet received. The HRU uses this information to compute the RTP timestamp. The RTP timestamp increases by 160 (8 K samples/sec * 20 ms) for consecutive packets. Page 11

12. Compressor State Machine Page 12 Context Update mode Optimistic Compression mode Reliable Compression mode Send ‘n’ ICI packets Timeout waiting for ACK ACK received for ICI packet Send compressed packets New Context / Reset State

13. Decompressor State Machine Page 13 Null Context mode Received a ICI packet / Initialize context and Send ACK Decompression mode Received ICI packet / Store Context and Send ACK Received compressed packet / Decompress it

14. Call Flow (Reverse Link) Page 14

15. ICI details FieldLengthComment MessageID8 RLPLinkFlowNumber8 SourceIPv4Address32IPv6 will use different ICI message (Plan to bring to the next revision) DestinationIPv4Address32 SourceUDPPortAddress16 DestinationUDPPortAddress16 RTPSequenceNumber16 PayloadType7 Reserved1 Page 15

16. Air Interface Header Reconstruction Page 16 Header How AN sets the Header MAC Trailer (2 bits)Set to indicate Format A connection layer packet Connection header (0 bits)No header for Format A packet Stream Layer (2 bits)Stream ID (Set to default value of EMPA) RLP header (14 bits)LinkFlowNumber (5 bits) = from ICI Route (1 bit) = Always 0 SEQ (6 bits) = Always 0 when CRC passed FirstDataUnit (1 bit) – Always 1 LastDataUnit(1 bit) – Always 1

17. Recommendations Review and adopt the concept Create a separate document for xHRPD header removal either in TSG-C or in TSG-X for Phase I Decide which TSG will be a primary working group Regardless it should be a joint effort of both TSGs Phase II design will follow up if operator requests it Page 17