1. Analysis of Backhaul Utilization for Network evolution architecture Peerapol Tinnakornsrisuphap (peerapol@qualcomm.com)peerapol@qualcomm.com Jun Wang (jwang@qualcomm.com)jwang@qualcomm.com Qualcomm Inc. December 4 th, 2006 Notice: QUALCOMM Incorporated 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. 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 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 QUALCOMM Incorporated other than provided in the copyright statement above.

2. Outline -Backhaul utilization analysis -DO rev A architecture -AG-BS when Header Compression/Ciphering is at the central node (AG) -AG-BS when Header Compression/Ciphering is at the edge (BS) -Why the BS should have access to IP in the evolved architecture to reduce backhaul utilization? -Conclusions

3. Current DOrA architecture PDSN BTS IP Core Network BSC BTS 3GPP2 A10/A11 High Bandwidth Simple A10-based Flow Control Low Bandwidth Proprietary Interface Tight Flow Control Frequent Handoffs BSC Infrequent Handoffs

4. Backhaul utilization for DOrA PDSN BTS IP Core Network BSC BTS 3GPP2 A10/A11 High Bandwidth Simple A10-based Flow Control Low Bandwidth Proprietary Interface Tight Flow Control Frequent Handoffs BSC Infrequent Handoffs Data Due to tight flow control between BSC-BTS, backhaul utilization is kept minimal because of complex proprietary interface *This is possible because BSC and BTS are from the same vendor During BTS handoff, only small fraction of data needs to traverse the backhaul twice (due to queue transfer or RLP multicast) Data

5. Proposed evolution architecture LMA BS IP Core Network AG BS High Bandwidth IETF-based protocol 3GPP2 Standardized Interface Low Bandwidth Likely No Tight Flow Control (Otherwise very complex) Frequent Handoffs AG Infrequent Handoffs Big question is where should HC/UDC be located?

6. Backhaul utilization: HC/UDC at the AG LMA BS IP Core Network AG BS High Bandwidth IETF-based protocol 3GPP2 Standardized Interface Low Bandwidth Likely No Tight Flow Control (Otherwise very complex) Frequent Handoffs AG Infrequent Handoffs Data If there is no tight flow control between AG and BS*, a large amount of data needs to be transferred between BSs frequently due to inter-BS handoff *Specifications should allow for AG-BS inter- operability between different vendors so simplicity of the AG-BS interface is necessary This amount of data is comparable regardless of HC/Ciphering location, so there is no significant backhaul saving [see next slides] Data

7. Backhaul saving due to HC? Backhaul should be provisioned to handle both best-effort traffic and real-time traffic such as VoIP Example: DO rev A Best Effort (BE) Traffic BE bandwidth : Up to 3.1 Mbps –IPv4 Overhead size when RoHC at AG –Outer IPv4 header (20 bytes) + GRE header with sequence number and A10 flow control (20 bytes) + Compressed Inner IPv4/TCP header (3-40 bytes) = 43-80 bytes Overhead size when RoHC at BS –Outer IPv4 header (20 bytes) + Inner IPv4 header (20 bytes) + TCP header (20 bytes) = 60 bytes Typical MTU = 1500 bytes –Max Bandwidth saving = 1.0 %, Worst case = -1.2%

8. Backhaul saving due to HC? (cont’d) Example: DO rev A Best Effort Traffic (cont’d) –IPv6 Overhead size when RoHC is at AG –Outer IPv6 header (40 bytes) + GRE header with sequence number and A10 flow control (20 bytes) + Compressed Inner IPv6/TCP header (3-60 bytes) = 63-120 bytes Overhead size when RoHC is at BS –Outer IPv6 header (40 bytes) + Inner IPv6 header (40 bytes) + TCP header (20 bytes) = 100 bytes Typical MTU = 1500 bytes –Max Bandwidth saving = 2.2%, Worst case = -1.2 % Conclusion: Header compression does not provide significant backhaul saving for BE traffic because of the large payload size

9. Backhaul saving due to HC? (cont’d) Example: DO rev A VoIP Assume VoIP capacity is 60 users ~ 480 kbps (8 kbps * 60) –Reduction in over-the-air capacity is due to delay-sensitive nature of traffic –Backhaul Header overhead per user when voice activity factor is f (0 < f < 1) With RoHC in AG: (20+12+4)*8/20msec*f = 14.4 * f kbps / user With RoHC in BS: (20+40)*8/20msec*f = 24 * f kbps / user Difference of only ~10 * f kbps/user –Even for max number of VoIP users with full header and f = 1, still require much less backhaul bandwidth than BE capacity! Header compression on the backhaul is not necessary as there is plenty of backhaul capacity to accommodate the VoIP traffic Also, having max number of simultaneous VoIP calls is rare but any FTP user can take up the whole BE capacity –When BE mixture increases, saving due to RoHC decreases because of larger average payload size Conclusion: Header compression does not lead to backhaul saving for VoIP traffic as the backhaul already needs to be provisioned for a much larger BE capacity

10. Analysis of Backhaul Utilization when HC/Ciphering is at AG -If AG-BS interface is kept simple (e.g., no flow control) -Backhaul utilization is at best comparable to when HC/Ciphering is at BS as shown in previous slides -However, if the BS has visibility to IP packets, then there are ways to reduce amount of buffer at the BS (see next slides) as this is similar to when a router manages congestion in the Internet -If AG-BS interface is complex (e.g., with tight flow control) -AG-BS interface functionalities similar to DOrA BSC-BTS interface -Since the link to BS has limited bandwidth, this flow control mechanism needs to be highly optimized per traffic type -It is very difficult to achieve inter-vendor interoperability on such complex interface -With a complex AG-BS interface, the standardization of AG-BS interface will take much longer and many interoperability problems may arise during deployment

11. Congestion control if HC/Ciphering is at the edge -Recall that any buffered data at the BS needs to be transferred during BS- BS handoff -Once the queue of the BS starts building up, BS can use IP Active Queue Management mechanism (e.g., RFC 2309) and Explicit Congestion Notification (RFC 3168) to minimize the size of the buffer in the BS -This is a well-studied problem and the BS can use any mechanisms available to Internet router -Hence the amount of buffer to be transferred to the new BS during handoff is small and backhaul utilization is reduced -When HC/Ciphering is already done at AG, this is not possible as the BS has no visibility to IP packets

12. Example: TCP AGBSAT AGBSAT Queued HC/Ciphered data IP AGBSAT IP BS applies ECN marking when queue is large which leads to TCP back off TCP cannot detect any congestion Most of data in TCP window is buffered in BS During handoff, a large amount of data needs to be transferred to the new BS Small buffered data implies less data to transfer between BS and also lower backhaul utilization (i) when BS has no visibility to user IP packets (ii) when BS has visibility to user IP packets To TCP this is just one link with very long delay

13. Further considerations -Not only TCP but many IP-based applications (e.g., streaming services) can react to Explicit Congestion Notification -IP routers today have mechanisms to deal with large volumes of non-TCP traffic as well -IETF protocols are designed to react when the bottleneck routers are congested -By applying Header Compression/User Data Ciphering at the AG, these protocols cannot react to the real bottleneck in the system -BS may also perform cross-layer optimization to manage congestion based on radio condition of the users -Ciphering at the edge prevents spurious packets from traversing the backhaul links on the reverse-link

14. Conclusions -By performing HC/Ciphering at the BS, the BS can manage congestion at the real bottleneck of the system -Leads to smaller buffer, better backhaul utilization and smaller jitter during handoff -Mechanism is based on IETF standards and not 3GPP2 proprietary -Even when the BS does not manage congestion, backhaul requirement between AG-BS is comparable regardless of whether the header compression is in the AG or the BS -But performing HC/UDC at the BS has several benefits as discussed in contribution X31-20061204-016 HC and UDC Location LU_NT_QCOM.ppt -The interface between AG-BS is also simple if HC/Ciphering is at the BS -Faster time-to-market -Fewer inter-operability issues -Cross-layer optimization (e.g., channel-aware congestion control) is only possible when the BS has visibility to IP packets