1. ABSTRACT: This contribution raises several issues with locating ROHC at the BS. TITLE: Observations on ROHC Location TSG-X WG31 RECOMMENDATION: Review and adopt Samsung Electronics grant 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. Samsung Electronics are 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 Samsung Electronics 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 Samsung Electronics. Samsung Electronics specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Samsung Electronics other than provided in the copyright statement above. X31-20070125-xxx-r1 DATE: February 8, 2007 SOURCE: Kyungjoo Grace Suh, Bill Semper, B.S. Bae, Veronika Kondratieva, Naehyun Lim, Daegyun Kim Tel. +82-31-279-5123 Mobile +82-16-9530-5123 joo.suh@samsung.com Notice

2. 2 Overview  Samsung’s Rational for ROHC Placement in AGW  Concerns about ROHC in the BS ROHC Header Adjustment during Fast Cell Selection Backhaul performance analysis Header Compression Recovery from Lower Layers  Conclusions

3. 3 Samsung’s Position  Samsung feels that ROHC belongs in the AGW: Operators very likely to deploy UMB are requesting ROHC functionality in the AGW Allowing ROHC in the AGW may allow for smoother migration to UMB from present networks.  We can accept the compromise of allowing the standard to allow ROHC in the eBS or AGW optionally  We do not agree with “not talking about ROHC” in the standard This would prohibit ROHC in the AGW, but allow ROHC to be implemented in the BS  We do not agree that ROHC in the eBS has been shown conclusively to be much better in terms of performance than ROHC in the AGW

4. 4 Merits of ROHC in AG  Better support for mobility No ROHC context forwarding Or less air interface overhead due to ROHC reset  Less backhaul overhead  No need to signal full IP filter (for QoS) to eBS eBS does not need to perform deep packet inspection.

5. 5 Concern ROHC @ BS : ROHC Header Adjustment in Cell Selection  Each eBS contains its own ROCH compressor; AT maintains separate context for each ROHC compressor instance is established when sector at eBS is added to Active Set When compressor instance is established, reference value v_ref_c is established for RTP Sequence Number compression –Usually based on last compressed RTP Sequence value Similar process for the RTP Timestamp –Compressor establishes sliding window using T_j (scaled Timestamp value) and a_j (arrival time of last packet) Compressor also compresses offset between RTP Sequence Number and IPv4 Identifier field.

6. 6 Concern ROHC @ BS : ROHC Header Adjustment in Cell Selection (cont.)  Issue: 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. ROHC uses these values to send the minimum least order bits that will allow the decompressor to properly interpret the compressed value RTP Sequence Number and Timestamp may have progressed well beyond the sliding window while the AT was being served by another eBS “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

7. 7 Concern ROHC @ BS : ROHC Header Adjustment in Cell Selection (cont.)  Concerns: Having to “adjust” the RTP headers on each cell switch (possibly) will add extra overhead to the air interface, versus having a centralized compressor where this problem will not occur Maintaining ROHC compressors in the eBS for every AT that includes one of the eBS’s sectors in its Active Set will add complexity to the eBS Maintaining separate ROHC decompressors in the AT will add to AT complexity

8. 8 Concern ROHC @ BS : ROHC Performance Analysis  Contribution X31-20070108-012 ALU ROHC Placement in the Evolved 3GPP2 RAN Architecture claimed poor performance with ROHC in the AGW when packets are lost over the air Based on RTT time of approximately 210ms, approximately 10 voice frames lost Our analysis shows that the RTT between edge of network and GTW is closer to 50ms 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 Delay difference is closer to 20-25ms, not 210ms  We do not believe that centrally locating ROHC will drastically increase outages at the AT due to lost packets

9. 9 Concern ROHC @ BS : ROHC Performance Analysis (cont.)  Contribution X31-20061204-025 QC AG-BS Backhaul Analysis implies that locating ROHC in the AGW provides little or no savings in backhaul capacity Analysis assumes that centrally locating ROHC compressor in AGW will require GRE tunnels to the eBS The savings of the compression are offset by the added GRE headers Distributed ROHC in the eBS does not use GRE, so the overhead is assumed to be almost equal However, contribution X31-20070108-025 QCOM UMB IOS Mobility Design assumes “Anchor AN” will use GRE tunnels to forward data to “Serving FL AN”  We are not clear if the distributed proposal requires GRE tunnels or not Analysis is too simplistic, does not take into account full RAN backhaul and realistic traffic patterns

10. 10 Concern ROHC @ BS : ROHC Header Recovery from RLP/MAC  RTP Sequence recovery from RLP Contribution X31-20070108-012 ALU ROHC Placement in the Evolved 3GPP2 RAN Architecture states that RTP Sequence Numbers may be recovered from RLP sequence numbers using “local repair” Details of how this can be done were not provided We suspect that this will require tight coupling between RTP sequence numbers and RLP sequence numbers, i.e. a one-to- one correspondence This will require the eBS to send compressed packets in a specific order, to maintain the RTP-RLP correlation 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 provide some savings in some situations (reverse link)

11. 11 Concern ROHC @ BS : ROHC Header Recovery from RLP/MAC (cont.)  RTP Timestamp recovery from MAC Contribution X31-20070108-012 ALU ROHC Placement in the Evolved 3GPP2 RAN Architecture states that RTP Timestamp may be recovered from MAC transmitting/receiving timing information Details of how this can be done were not provided Again, this 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

12. 12 Conclusions The primary case for placing ROHC in the eBS seems to be based on performance and backhaul savings We do not believe that significant performance improvement and savings have been conclusively shown More importantly, RAN performance and backhaul utilization are very complicated areas, which depend upon many variables that are beyond the scope of the standard We doubt that this architectural decision can be justified by simple analysis Samsung feels that we should listen to our customers and provide them the solutions they are asking for