1. 1 Title: Arguments for ROHC Placement in the BS - Clarifications Abstract: This contribution discusses and clarifies statements and arguments made with respect to placement of ROHC in the eBS. Source: Qinqing Zhang, qinqing@alcatel-lucent.comqinqing@alcatel-lucent.com Violeta Cakulev, cakulev@alcatel-lucent.comcakulev@alcatel-lucent.com Frank Alfano, falfano@alcatel-lucent.comfalfano@alcatel-lucent.com Date: February 12, 2007 Recommendation: Review and discuss Notice Alcatel-Lucent grants a free, irrevocable license to 3GPP2 and its Organization 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 portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Sprint Nextel 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 contributor 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 the contributor. Sprint Nextel 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 contributor other than provided in the copyright statement above.

2. 2 Background  Discuss statements made in X31-2007-0208-XXX-r1- Samsung-ROHC.ppt  Provide additional clarifications

3. 3 References [1] X31-20070108-012 ALU ROHC Placement in the Evolved 3GPP2 RAN Architecture [2] X31-2007-0208-XXX-r1-Samsung-ROHC.ppt [3] IETF RFC 3095 (July 2001): “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed” [4] draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt (March 2007): RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite

4. 4 ROHC Header Adjustment in Cell Selection Section titled ROHC Header Adjustment in Cell Selection in reference [2] pg. 6 makes following statements The values used to establish the sliding windows for RTP Sequence Number and RTP Timestamp will become stale if the AT does not return to the eBS soon  “ Off the shelf ” ROHC will need to reset these values by dropping back to a lower order state – thus sending full fields for several frames until the decompressor and compressor agree on the proper values again  We think this could add extra overhead each time a cell is switched Comment  RFC 3095 compliant ROHC will NOT need to drop back to a lower order state, hence will NOT need to send full fields for several frames. Instead, a few bytes larger header will need to be transmitted  A few bytes larger header does not necessarily add extra overhead to the air interface Note: It is not clear how “off the shelf” ROHC is defined. We assumed what was meant is RFC 3095 compliant ROHC

5. 5 ROHC Performance Analysis (1/2) Section titled ROHC Performance Analysis in reference [2] pg. 8 makes following statements  Analysis should be based on difference in delay time between when decompressor notices problem and time compressor receives feedback – one way delay between eBS and AGW Comment  ROHC performance analysis needs to be based on RTT between compressor and decompressor  When decoding failure happens, ROHC decompressor sends NACK to compressor for resynchronization and waits for IR-DYN packet [3]  This represents RTT from decompressor to compressor, and NOT one way delay as decompressor needs to receive IR-DYN packet from compressor  Decompressor and compressor are not at eBS and AGW they are at AT and eBS (or AGW)  RTT from AT to AGW (i.e. AT-AGW-AT) is on average 210ms

6. 6 ROHC Performance Analysis (2/2) Section titled ROHC Performance Analysis in reference [2] pg. 8 makes following statement  We do not believe that centrally locating ROHC will drastically increase outages at the AT due to lost packets Comment  Simulation analysis [1] showed that in the presence of out-of-order delivery:  Large number of mobile to mobile calls (87%) experienced at least one ROHC decompression failure for ROHC in AGW –Simulation parameters: p=4  None of mobile to mobile calls experienced ROHC decompression failure for ROHC in eBS –Simulation parameters: p=4, local repair  No claims about drastically increased outages were made in [1]

7. 7 ROHC Header Recovery from RLP Section titled ROHC Header Recovery from RLP/MAC in reference [2] pg. 10 makes following statements  Details of how this ( “ local repair ” ) can be done were not provided  We suspect that this ( “ local repair ” ) will require tight coupling between RTP sequence numbers and RLP sequence numbers, i.e. a one-to-one correspondence  This may be difficult to do, since the eBS is receiving packets on an IP network and in sequence delivery of RTP/UDP/IP packets is not guaranteed  Seems to violate the “ off the shelf ROHC ” assumption  May require short term buffering at the eBS of incoming packets to maintain RLP- RTP correlation Comment  RTP Sequence Number may be recovered from RLP SN  In general, how to recover RTP sequence number is an implementation issue  It requires mapping between RTP sequence numbers and RLP sequence numbers  This mapping does not require in-sequence delivery  This mapping does not violate RFC 3095 –RFC 3095 leaves to implementation how to recover RTP sequence number  No buffering is needed for the purpose of maintaining this mapping –Decompressor decompresses and delivers packets in order it receives them

8. 8 ROHC Header Recovery from MAC Section titled ROHC Header Recovery from RLP/MAC in reference [2] pg. 11 makes following statements :  Again, this ( “ local repair ” ) seems to imply a tight correlation between RTP Timestamps/packet arrival times and MAC packet transmissions  Only possible if ROHC is in the BTS/eBS, but seems to break layers severely  This may break if packets arrive out of order – since MAC timing is being used, buffering is probably no help  Also seems to break the “ off the shelf ROHC ” rule – not clear how this information can be used to update standard ROHC algorithm Comment  RTP Timestamp may be recovered from MAC transmitting/ receiving timing information  Inter-layer exchange across the protocol stack for the purpose to optimize performance is called cross layer optimization  Does not break layers  In general, how to recover RTP Timestamp is an implementation issue  It requires mapping between RTP Timestamp and MAC packet transmissions  This mapping does not requires in-sequence delivery  This mapping does not violate RFC 3095  No buffering is needed for the purpose of maintaining this mapping  Indeed, possible only if ROHC is in the eBS

9. 9 Conclusions ROHC performance analysis needs to be based on RTT between compressor (e.g. eBS) and decompressor (e.g. AT) There is tradeoff between the robustness against reordering and the robustness against consecutive packet losses Link assisted ROHC implementation vastly improves ROHC performance in the presence of out-of-order delivery  Termed as “local repair”  “Local repair” does not assume re-sequencing packets at the RLP layer