1 a13 proxy for supporting hrpd handout from femto ap to macro an peerapol tinnakornsrisuphap...

1

A13 Proxy for supporting HRPD Handout from femto AP to macro AN

Peerapol Tinnakornsrisuphap ([email protected])David Ott ([email protected])

Qualcomm Inc.February 16th, 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.

mailto:[email protected]

mailto:[email protected]

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 <ColorCode:UATI24> of the AT– While <ColorCode:UATI24> 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 this1. Standardize UATI mapping to IP address for Femto2. Use DNS mechanism to register UATI->IP address of Femto3. Create A13 Proxy

• The 1st and 2nd 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

A13 Proxy Concept

Macro AN A13 Proxy

FGW

FAP1(AT’s session)

FAP2 FAP3

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 forwardsA13 message to FAP1

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

A13 Messages Routing (Stateful)

Macro AN A13 Proxy FAP

FAP IP determined based on UATI128in 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 <SRC IP, SRC UDP Port><A13 Proxy IP, A13 Port>

Payload

A13-Session Information Request

UDP/IP header <A13 Proxy IP, Port X>

<FAP IP, A13 Port>

Payload


1.

2.

3.

UDP/IP header <FAP IP, A13 Port>

<A13 Proxy IP, Port X>

Payload

A13-Session Information Response

UDP/IP header <A13 Proxy IP, A13 Port><SRC IP, SRC UDP Port>

Payload



Payload

A13-Session Information Confirm

UDP/IP header <A13 Proxy IP, Port X>

<FAP IP, A13 Port>

Payload


6

A13 Messages Routing (Stateless)

Macro AN A13 Proxy FAP

FAP IP determined based on UATI128in A13 message

* Note that content of A13 messages are unchanged when relayed through proxy


Payload


UDP/IP header<SRC IP, SRC UDP Port>

<FAP IP, A13 Port>

Payload


1.

2.

3.

UDP/IP header <FAP IP, A13 Port>

<SRC IP, SRC UDP Port>

Payload


UDP/IP header <SRC IP, SRC UDP Port>

<FAP IP, A13 Port>

Payload


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

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

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

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 <u.v.a.b>, it may assign <x:a.b.c> as <ColorCode:UATI24> 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., <u.v.*>

• 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

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

1 a13 proxy for supporting hrpd handout from femto ap to macro an peerapol tinnakornsrisuphap...

Documents