1. 1 A13 Proxy for supporting HRPD Handout from femto AP to macro AN Peerapol Tinnakornsrisuphap (peerapol@qualcomm.com)peerapol@qualcomm.com David Ott (dott@qualcomm.com)dott@qualcomm.com Qualcomm Inc. February 16 th, 2009 Notice ©2009. 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 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. 2 Why A13 Proxy? For HRPD idle handout (from Femto AP to macro AN), macro AN needs to be able to retrieve HRPD session from femto AP using A13 interface –IP address of session controller is obtained from of the AT –While is 32 bits long, however, current macro implementation typically only uses ColorCode to identify the IP address of the source AN that holds the session –With a large number of femtos under a macro AN coverage, the current implementation in macro AN does not scale without making changes to macro AN There are three alternatives for achieving this 1.Standardize UATI mapping to IP address for Femto 2.Use DNS mechanism to register UATI->IP address of Femto 3.Create A13 Proxy The 1 st and 2 nd alternatives require changes to macro AN and was discussed in contribution A20-20081027-009r0 UATI-IP address mapping The third alternative creates new 3GPP2 specific entity but does not require change on macro AN This contribution provides analysis whether A13 Proxy can be supported without any changes to A13 interface and whether any new interface is needed

3. 3 A13 Proxy Concept Macro ANA13 Proxy FGW FAP1 (AT’s session) FAP2FAP3 5. A13 Session Information Request AT 3. AT accesses with UATI assigned by FAP1 4. Macro AN maps AT’s ColorCode to A13 Proxy’s IP address 6. A13 Proxy resolves identity of FAP based on UATI128 A13 proxy is a logical entity which may be collocated with FGW AT 1. AT has session with FAP1 2. AT performs idle handoff to macro AN 7. A13 Proxy forwards A13 message to FAP1

4. 4 What do A13 Proxy need to do on each A13 message? –A13-Session Information Request –A13-Session Information Response –A13-Session Information Confirm –A13-Session Information Reject –A13-Release Resource Request –A13-Release Resource Response –*A13-Paging Request / Ack –*A13-Keep Alive Request/Response –*A13-Paging Delivered / Ack –*A13-1x Air Interface Signaling * These messages need special treatment from other A13 messages

5. 5 A13 Messages Routing (Stateful) Macro ANA13 ProxyFAP FAP IP determined based on UATI128 in A13 message SRC IP and UDP port need to be stored from earlier A13 message FAP IP determined based on UATI128 * Note that content of A13 messages are unchanged when relayed through proxy UDP/IP header Payload A13-Session Information Request UDP/IP header Payload A13-Session Information Request 1. 2. 3. UDP/IP header Payload A13-Session Information Response UDP/IP header Payload A13-Session Information Response UDP/IP header Payload A13-Session Information Confirm UDP/IP header Payload A13-Session Information Confirm

6. 6 A13 Messages Routing (Stateless) Macro ANA13 ProxyFAP FAP IP determined based on UATI128 in A13 message * Note that content of A13 messages are unchanged when relayed through proxy UDP/IP header Payload A13-Session Information Request UDP/IP header Payload A13-Session Information Request 1. 2. 3. UDP/IP header Payload A13-Session Information Response UDP/IP header Payload A13-Session Information Confirm Assume Macro AN does not discard the response message that the source IP/Port does not match the destination IP/Port of the request message

7. 7 Messages with Special Treatments –A13-Paging Request / Ack Request may need to be delivered to all Femtos under the Proxy that use the same ColorCode Ack needs to be generated from Proxy (can be immediate) –A13-Keep Alive Request/Response Should be routed based on LCM_UATI in AT_ID instead on UATI field –A13-Paging Delivered / Ack For 1x Cross Paging –A13-1x Air Interface Signaling Correlation ID field swapped with UATI

8. 8 How does A13 Proxy map UATI to IP? Method 1: Registration from FAP –FAP is provided with the range of UATI and IP(s) of A13 Proxy from FMS –FAP registers with A13 Proxy when power-up –Require new IOS interface between A13 Proxy and FAP Method 2: Provisioned by FMS –FAP is provided with the range of UATI from FMS –FMS configures A13 Proxy on range of UATI -> IP of FAP whenever a new FAP comes on-line –Require new interface between FMS and A13 Proxy Method 3: Static configuration across FAP, FMS, and A13 Proxy Method 1 and 2 require new interfaces whereas method 3 do not require any new interface

9. 9 Using Static Configuration for A13 Proxy New interface is not required at A13 Proxy assuming operators have the following static configurations in the A13 Proxy and FAP –Both FAP and A13 proxy are configured on which part of the UATI contains portion of FAP IP address –The IP prefix of FAP address that are not contained in UATI are either uniform across FAPs under the same A13 proxy or known to A13 Proxy Example, if the FAP’s IPsec address is, it may assign as of an AT on the FAP, where –x maps to IP address of A13 Proxy (used at macro AN) –a.b identifies part of the FAP IP address Note that all FAPs under this A13 proxy need to have same upper 16 bits address, e.g., This also implies 2^16 femtos can be served under this logical A13 proxy –c identifies the AT on the FAP Note that this means there are 256 unique session identifiers available on the FAP –The number of bits allocated for a,b, and c are flexible depending on configurations

10. 10 Recommendations Since it is possible to implement and deploy A13 Proxy to support HRPD idle hand-out without an additional interface or modifications to A13 interface, we propose the following in A.S0024-0 –Add the A13 Proxy in the FAP reference architecture –Revise A13 Hand-out call flow to show macro AN sends A13 message to A13 Proxy instead of FAP –Add informative statement in A13 Procedure that based on UATI the AN may send A13 messages to A13 Proxy instead of FAP If required, additional interfaces to support more flexible UATI configuration may be introduced in later release