1. 3GPP2-P00-20000821-005 San Francisco, CA 1 Alternatives to LIMIT Raymond HsuNish AbrolQualcomm Inc. 858-651-3623858-65105113 rhsu@qualcomm.comnabrol@qualcomm.com The contributor 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 portions of the contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner's standards publication. The contributor must also be willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions, as appropriate. Notice

2. 3GPP2-P00-20000821-005 San Francisco, CA 2 Introduction Release B supports low-interruption handoff for IP-based multimedia services (e.g. VoIP). Lucent proposed LIMIT to achieve the low-interruption handoff requirement. But, LIMIT increases complexity and cost in MS with two PPP/RLPs. It is reasonable to assume that most handoff scenarios will be intra-PDSN handoff. Low-interruption handoff can be achieved by using one of the two intra-PDSN handoff options presented herein. During the handoff, the MS only needs one PPP/RLP. It is recommended that inter-PDSN handoff with low- interruption is for further study.

3. 3GPP2-P00-20000821-005 San Francisco, CA 3 MS Issues in LIMIT Lucent’s LIMIT proposal requires the MS to support two PPP links over two RLP instances, in order to achieve low- interruption handoff. Two PPP/RLPs complicate MS implementation. Two PPP/RLPs is problematic for relay-model: –Microsoft does not support multiple PPP in Windows. –When handset receives byte streams from laptop, how does the handset know which RLP to use? –When laptop receives PPP frames, how does the laptop know to which PPP link the frames belong? This requires two physical channels between TE2 and MT2. But commonly used interfaces (e.g. RS-232) does not support it. –Since the laptop-handset interface has not been standardized, there could be interoperability problems.

4. 3GPP2-P00-20000821-005 San Francisco, CA 4 Handoff within a Metropolitan Area In a metropolitan area (e.g. LA), it is reasonable to assume that PDSNs and PCFs of the same carrier are “reachable” with each others via routers. –The IP-based R-P interface enables this full connectivity among PDSNs and PCFs. –It is unlikely a carrier would deploy “islands” of PDSN/PCF in the same metropolitan region. If the above assumption is valid, an active MS will have an anchor PDSN as long as the MS is within the same metropolitan area. In this case, intra-PDSN handoff (when MS changes PCF) may occur, but inter-PDSN handoff will not occur.

5. 3GPP2-P00-20000821-005 San Francisco, CA 5 Intra-PDSN Handoff Options Low-interruption performance can be achieved for intra-PDSN handoff, while keeping the MS simple and low cost. –PPP negotiation and Mobile IP registration are not needed. –Over-the-air handoff is fast. –Only one PPP/RLP is required during the handoff to minimize MS complexity and cost. Option 1 is the inter-PCF hard handoff as described in Section 2.15.5.10 of 3G-IOS Version 4.0. Option 2 is the inter-PCF tunnel method similar to LIMIT. –MS is served by PCF1. Assume that BSC and PCF are integrated. »The data path before the handoff is MS PCF1 PDSN. –MS moves to PCF2. PCF1 establishes a tunnel to PCF2 before the MS is handoff from PCF1 to PCF2. »The data path during the handoff is MS PCF2 PCF1 PDSN. –PCF2 establishes an A10 connection with PDSN and releases the tunnel to PCF1. »The data path after the handoff is MS PCF2 PDSN. Which option yield better low-interruption performance?

6. 3GPP2-P00-20000821-005 San Francisco, CA 6 Option 1: Inter-PCF Hard Handoff PDSN BS/PCF1 BS/PCF2 MS Path before handoff Path after handoff

7. 3GPP2-P00-20000821-005 San Francisco, CA 7 PDSN BS/PCF1 BS/PCF2 MS Path before handoff Path during handoff Path after handoff Option 2: Inter-PCF Tunnel

8. 3GPP2-P00-20000821-005 San Francisco, CA 8 Handoff between Metropolitan Areas For example, a user is on a VoIP call while driving from one city to another city, say from San Diego to Los Angeles. At some point, the user will cross over the metropolitan area boundary. The two areas may or may not belong to the same carrier. If the two areas belong to the same carrier, the VoIP call needs to be maintained. –Two areas can be connected via routers. »If the connectivity is via Internet, security association is required between the routers. »If the connectivity is direct (without traversing through the Internet), security association is not required between the routers. –A network entity (e.g. PCF or PDSN) in one area is reachable by any network entities in another area. »There is no need to establish security association between PCF in one area and PDSN in another area because the connectivity between the two areas are already secured via IPSec or direct private line. –The low interruption handoff can be achieved by using one of the intra-PDSN handoff options described earlier. There is no need to connect two far-away metropolitan areas.

9. 3GPP2-P00-20000821-005 San Francisco, CA 9 Handoff between Metropolitan Areas If the two metropolitan areas belong to different carriers without roaming agreement, the VoIP call across the area boundary will be dropped. If the two metropolitan areas belong to different carriers with roaming agreement, the VoIP call may be maintained. –Two carriers can be connected via routers. »If the connectivity is via Internet, security association is required between the routers. »If the connectivity is direct (without traversing through the Internet), security association is not required between the routers. –A network entity (e.g. PCF or PDSN) in one carrier is reachable by any network entities in another carrier. –The low interruption handoff can be achieved by using one of the intra-PDSN handoff options described earlier. –If for any reasons the two carriers are not connected, then the VoIP call across the carrier boundary will be dropped. However, the MS may originate a new VoIP call since the two carriers have roaming agreement.

10. 3GPP2-P00-20000821-005 San Francisco, CA 10 Handoff between Metropolitan Areas PDSN PCF PDSN Routers PDSN PCF PDSN HA MS Path before handoff Path during handoff Path after handoff

11. 3GPP2-P00-20000821-005 San Francisco, CA 11 Conclusion Low-interruption handoff performance for VoIP services can be achieved by using one of the two intra-PDSN handoff options presented herein. During the handoff, the MS only needs one PPP/RLP. Most handoff scenarios will be intra-PDSN handoff. –Within a metropolitan area, PCFs and PDSNs of the same carrier are connected via the carrier’s IP network, so that the PCFs and PDSNs are reachable by each others. –If two metropolitan areas belong to the same carrier, it is reasonable to assume that the metropolitan two area networks will be connected securely, so that PCF in one area is reachable by PDSN in another area. –If two metropolitan areas belong to different carriers with roaming agreement, the two area networks may be connected. If they are connected securely, PCF in one area is reachable by PDSN in another area.

12. 3GPP2-P00-20000821-005 San Francisco, CA 12 Conclusion Achieving low-interruption performance via intra-PDSN handoff does not rely on IETF and hence is within the Release B target date. Achieving low-interruption performance via inter-PDSN handoff (e.g. Mobile-IP fast handoff, or PDSN context transfer, etc.) relies on IETF and hence is better off for further study in the next release (All-IP?). The goal is to achieve low-interruption handoff performance without increasing the MS complexity and cost.