Analysis of Backhaul Utilization for Network evolution architecture

Peerapol Tinnakornsrisuphap (peerapol@qualcomm.com)

Jun Wang (jwang@qualcomm.com) Qualcomm Inc.

December 4th, 2006Notice: 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.

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

Current DOrA architecture

PDSN

BTS

IP Core Network

BSC

BTS

3GPP2 A10/A11High BandwidthSimple A10-based Flow Control

Low BandwidthProprietary InterfaceTight Flow Control

Low BandwidthProprietary InterfaceTight Flow Control

Frequent Handoffs

BSCInfrequentHandoffs

Backhaul utilization for DOrA

PDSN

BTS

IP Core Network

BSC

BTS

3GPP2 A10/A11High BandwidthSimple A10-based Flow Control

Low BandwidthProprietary InterfaceTight Flow Control

Low BandwidthProprietary InterfaceTight Flow Control

Frequent Handoffs

BSCInfrequentHandoffs

Data

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

Data

Proposed evolution architecture

LMA

BS

IP Core Network

AG

BS

High BandwidthIETF-based protocol

3GPP2 Standardized InterfaceLow BandwidthLikely No Tight Flow Control(Otherwise very complex)

Frequent Handoffs

AGInfrequentHandoffs

Big question is where should HC/UDC be located?

Backhaul utilization: HC/UDC at the AG

LMA

BS

IP Core Network

AG

BS

High BandwidthIETF-based protocol

3GPP2 Standardized InterfaceLow BandwidthLikely No Tight Flow Control(Otherwise very complex)

Frequent Handoffs

AGInfrequentHandoffs

Data

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

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%

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

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

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

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

Example: TCP

AG BS AT

AG BS AT

Queued HC/Ciphered dataQueued HC/Ciphered dataIPIPIPIP

IPIP IPIPIPIPIPIPIPIPIPIP

AG BS AT

IPIP IPIPIPIP

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

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

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