1. HRPD Connection Layer Protocols for Inter-technology Handoff March 31 st, 2008 Peerapol Tinnakornsrisuphap (peerapol@qualcomm.com)peerapol@qualcomm.com Qualcomm Notice ©2008. All rights reserved. The contributors 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. The contributors 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 the contributors 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 the contributors. The contributors 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 the contributors other than provided in the copyright statement above. The contributors may hold one or more patents or copyrights that cover information contained in this contribution. A license will be made available to applicants under reasonable terms and conditions that are demonstrably free of any unfair discrimination. The contributors reserves the right to use all material submitted in this contribution for its own purposes, including republication and distribution to others.

2. Overview of the approach (Revised from C22-20080218-002_QC_HPRD packet tunneling for UMB to HRPD handoff.ppt) Define new subtypes of existing Connection Layer protocols when the AT connects to HRPD AN over the tunnel –Emulate connection state at the AT and AN Zero impact to protocols outside of connection layer –When AT operates on other technologies and pre-setup is needed, then the HRPD protocol is initialized with default subtypes except on connection layer where the tunnel subtypes are needed Over-the-air personality is negotiated through the tunnel Personality switch (+ commit) of the over-the-air personality during handoff –Revised based on the received comments from February meeting (more details later): Personality switch with new ALMP subtype may cause delay issue New MAC and PHY subtypes needed?

3. Benefits of the approach No modifications to the interfaces between connection layer and other layers No changes to protocols outside of connection layer Tunneling protocols and procedures remain the same regardless of the over-the-air personality All current features above connection layers (e.g., personality switch) are supported –Note that personality switch during handoff does not cause additional interruption AN-lite is supported – i.e., does not require all HRPD ANs to understand new subtypes Does not require the AT to decode over-the-air HRPD overhead information before handoff –But also supports inter-technology handoff to HRPD where the source technology does not advertise HRPD information –Specification does not depend on the source technology

4. Example: Current HRPD protocols Default Air-Link Management Default Idle State SNP Default Packet Application Default Session Configuration 1. ALMP.OpenConnection command 2. IdleState.OpenConnection command 3. IdleState.ConnectionOpened indication Connection Layer Above Connection Layer

5. The proposed approach Tunnel Air-Link Management Tunnel Idle State SNP Default Packet Application Default Session Configuration 1. ALMP.OpenConnection command 2. IdleState.GenerateIndication (ConnectionOpened) command 3. IdleState.ConnectionOpened indication Connection Layer Above Connection Layer All protocols above connection layers are unaware of the tunnel – all of their current features are supported Tunnel Idle State is just a simple Command->Indication translator

6. Comments: Personality switch with new ALMP subtype may cause delay If the subtypes of Air-Link Management Protocol are different during Personality Switch+Handoff, then the Default Air-Link Management Protocol will start from Initialization State –The Default Air-Link Management Protocol would need the Initialization State protocol to acquire FL pilot and receive Sync message on Control Channel before NetworkAcquired indication can be generated Possible remedy –Use Default Initialization State protocol over the tunnel with the enhancement for Generating NetworkAcquired indication from Tunnel ALMP –Also enhanced the Initialization State protocol to return NetworkAcquired indication immediately after Activate command if timing is known Similar requirement is already in UMB air-interface spec

7. Comments: New MAC and PHY subtypes needed? Answer is no –Previous proposal proposed new MAC and PHY subtypes for packet encapsulation into the underlying tunnel but it is not needed We define the new PCP subtype performing the same function (i.e., interfacing with the underlying tunnel), then we do not need new MAC and PHY subtypes –This will also allow the AT to read over-the-air HRPD Control Channel, if needed

8. Revised Proposed HRPD Protocols

9. Overview of new protocols Tunnel Airlink Management Protocol –Setup tunnel between AT and AN (Refer to TSG-X PDS procedure on IPsec establishment and DNS lookup for UMB-HRPD handoff) –Emulate connection state to upper layers protocol (e.g., to trigger UATI request or commit session configuration) to avoid change to upper layers protocol –Initiate over-the-air handoff to HRPD Tunnel Overhead Messages Protocol –If over-the-air overhead parameters are read, provide them to HRPD stacks This part is identical to existing Overhead Messages Protocol –Any overhead information (e.g., subnet) advertised from neighbor technology (e.g., over UMB Neighbor Technology Record) supersedes the over-the-air information Tunnel Packet Consolidation Protocol –Provide appropriate 3GPP2 specific-headers to tunneled packets (e.g., ATI) in addition to current PCP functionalities –On the reverse-link : Protocol payload is sent to transport layer (e.g., L2 packet or UDP/IP) –On the forward-link : Protocol payload either from over-the-air Control Channel or the tunnel Default Initialization State Protocol –Contain all functionalities of current Initialization state protocol –Plus: Define InitializationState.GenerateIndication(NetworkAcquired) command to generate InitializationState.NetworkAcquired indication –Also enhanced the Initialization State protocol to return NetworkAcquired indication immediately after Activate command if timing is known

10. Call Flows between AT & AN