1

HRPD Fast Handoff

Jun Wang and Raymond HsuQualcomm Inc

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

Issues with Current Proposals• Current Proposal:

– Single Binding for both proxy MIP and client MIP• Issues:

– Packet Routing: • If MIPv6 is used (or MIPv4 CCoA is used), the MS node assumes it has COA1

(from the PDSN 1), but the PDSN 2 has sent BU to the HA to bind HoA with CoA 2. Therefore, the PDSN2 has to reset the outer header for every packet to CoA 1 and then pass them to the MS (otherwise, the MS will discard the packets.)

– Registration Replay Protection: • For MIPv4, if nonce is used (we use Timestamp), the MIP client needs to use

identification value which is received from the previous RRP to set up next RRQ. How does the two different RRQ/RRP (one from the AT and one from the PDSN) coordinate each other? It implies the PDSN needs to do some special things to all RRQ/RRP sent between AT and HA. It also implies context transfer is needed for identification value between PDSNs.

• For MIPv6, similarly, the sequence number has to be greater than the value setup by the previous BU/BA. In this case how can the AT and PDSN coordinate the sequence number?

3

Alternative Proposals• Option 1: Add logical LMA in the architecture to make two independent bindings

(One is binding AT’s COA to HoA which is between AT and HA; One is binding PDSN’s IP address to AT’s CoA which is between PDSN and HA.)

– For proxy MIP, per node based security association should be used– Need another tunnel between PDSN and HA– With P-P tunneling (P-P Tunneling is needed if MBB is not performed)

• Option 2: Just use P-P tunnel same as today’s 1X P-P tunnel design.– For simple IP, when IP address is changes, SIP session is gone

• Option 3: For Simple IP, PMIP is used and for MIP client P-P Tunneling is used– Has to use different binding for simple IP and mobile IP– The PDSN needs to examine packets to decide whether should establish P-P

tunneling:• Will delay for P-P Tunneling setup since it is triggered by packets• The first packet has to come from the MS; otherwise there is no P-P tunneling can be set up

– For simultaneous S.IP and MIP, the PDSN will perform differently– It Is not a good approach

• Suggestion: – Ether Option 1 or Option 2.

4

Current ProposalMS Source-AN Target-AN Serving-

AGW HATarget-AGW AAA

BU/BA (CoA-0, HoA, MN-HA AE) a

MS is Active b

HO necessary, inter AN signaling

A11-reg-req(pre-setup) w/ Serving-AGWadddress, flow mapping info

c

d

HO_Request(TLVs(Context_IDs,Mapping info, GRE

Keys)

HO_Response(TLVs{Contexts})

f

e

BU (CoA-1, HoA)MN-HA AE

BA

h

g

HO occurs

A11-reg-req (lifetime=0)

i

j

k

GRE tunnel

P-P tunnel deleted

SwitchTunnel

LCP: CHAP/PAP, IPv6CP/IPCP/ DHCP (address config = HoA) Auth/Authz

5

Proposal for MIPv6 (Option 1)MS Source-AN Target-AN Serving-

PDSN HATarget-PDSN AAA

2. BU/BA (CCoA-0, HoA, MN-HA AE)

a

4. MS is Active

b

5. HO necessary, inter AN signaling

6. A11-reg-req(pre-setup) w/ Serving-AGW adddress, flow mapping info

c

d

7. HO_Request (TLVs(Context_IDs,Mapping info, GRE

Keys)

8. HO_Response (TLVs{Contexts})

f

e

h

g

7' HO occurs

10' A11-reg-req (lifetime=0)i

j

k

10. Switch Tunnel

1. LCP: CHAP/PAP, IPv6CP/IPCP/ DHCP (address config = HoA) 1. Auth/Authz

3. Binding Update (S-PDSN, CCoA-0)

9. Binding Update (T-PDSN, CCoA-0)

GRE Tunnel

Data

DataGRE Tunnel

release

6

MIPv6 Operations (Option 1)

• The HA maintains the following two separate bindings:– CCoA-0 with HoA received from the AT– PDSN’s IP address with CCoA-0 received from the PDSN

• If the HA receives packets from CN with destination of HoA:– The HA first binds HoA to CCoA-0– The HA then binds CCoA-0 to PDSN’s IP address– The HA then sends packets to PDSN with PDSN-HA tunneling

• If the PDSN receives packets from HA via PDSN-HA tunneling:– The PDSN removes the PDSN-HA tunneling and sends MIPv6

packets to the AT (CCoA0)

7

Proposal for MIPv4 (Option 1)MS Source-AN Target-AN Serving-

PDSN HATarget-PDSN AAA

4. MS is Active

5. HO necessary, inter AN signaling

6. A11-reg-req(pre-setup) w/ Serving-AGW adddress, flow mapping info

7. HO_Request (TLVs(Context_IDs,Mapping info, GRE

Keys)

8. HO_Response (TLVs{Contexts})

7' HO occurs

10' A11-reg-req (lifetime=0)

i10. Switch

Tunnel

1. LCP: CHAP/PAP, IPv6CP/IPCP/ DHCP 1. Auth/Authz

3. Binding Update (S-PDSN, HoA)

9. Binding Update (T-PDSN, HoA)

GRE Tunnel

Data

DataGRE Tunnel

release

2.5. snooping RRP for HoA

3. Binding Update (S-PDSN, HoA)

2.1 RRQ (CoA-0, NAI,HoA(0.0.0.0) 2.2 RRQ sent over a Preconfigured PDSN-HA tunnel)

2.3 . Map NAI with Tunnel2.4 RRP sent over the tunnel

2.6 RRP (CoA0, HoA)

2.0 FA (CoA-0)

8

MIPv4 Operations (1) (Option 1)• The HA maintains the following two separate bindings:

– Binding CoA-0 (shared by all ATs) with HoA received from the AT– Binding PDSN’s IP address with AT’s HoA received from the PDSN

• The HA includes logical entities of AT’s HA, FA, PMIP HA. • If the HA receives packets from the CN with destination of HoA:

– The HA first performs the AT’s HA function, i.e., tunneling the packets to the internal FA according to the binding of HoA to CoA-0.

– The HA next performs the internal FA function, i.e., removing the HA-FA tunnel header and sending the packets to the internal PMIP HA.

– The HA finally performs the PMIP HA function, i.e., tunneling the packets to the PDSN according to the binding of HoA to PDSN’s address.

• If the PDSN receives packets from the HA via HA-PDSN tunneling:– The PDSN removes the HA-PDSN tunneling and sends IP packets to

the AT

9

MIPv4 Operation (2) (Option 1)

PDSN PMIP HA FA AT’s HA

HA

Src=CN IP Add

Dest=AT HoA

Src=HA IP Add

Dest=FA CoA

Src=CN IP Add

Dest=AT HoA

Binds HoA with CoA

Src=CN IP Add

Dest=AT HoA

Binds HoA with PDSN Add

Src=CN IP Add

Dest=AT HoA

Src=HA IP Add

Dest=PDSN Add

AT

Src=CN IP Add

Dest=AT HoA

10

Other Open Issues (1)• How does the AT know the new PDSN IP address so that it

may update TFT after handoff?– In IPCP, we suggest to use multicast IP address to replace PDSN IP

address – The PDSN will use Multicast IP address to receive RSVP-like

message• How to handle that the T-PDSN fails to establish the

context?– Add Ack message from T-PDSN to S-PDSN after context

established?– When the S-PDSN start to send raw IP packet? After Context

transfer or after receiving Ack?– We suggest to make compressed packet to be always sent from S-

PDSN until P-P is torn down• If Proxy MIP is used:

– The key for proxy MIP should be per node specific.

11

Other Open Issues (2)

• The need for delaying context transfer at S-AGW? – We don’t see the need for it.

• How does the HA distinguish PMIP and regular MIP? ( SPI v.s NAI)– If Option 1 is used, we can use PDSN’ s NAI to distinguish

• Accounting: Does the S-PDSN send Accounting-Stop and the T-PDSN send Accounting-Start as soon as the context is transferred?– We should close UDR in S-PDSN and create a new UDR in T-PDSN

when the P-P is torn down. – Whether we need a correlation call ID (for call continuation indication

used for duration based accounting) needs to be further discussed.