Tunneling Protocol Structures for UMB to HRPD Interworking Linhai He Peerapol Tinnakornsrisuphap February 2008 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.

UMB to HRPD handoff (i.e., tunneling of HRPD packets over IP while AT is on UMB)

3 Background To support delay-sensitive applications (e.g., VoIP) when the AT hands off from UMB to HRPD, the AT should pre- setup HRPD session, PPP session and TFT installation Assuming the AT has a single radio transmitter, then it has to perform HRPD pre-setup while on UMB For UMB to HRPD handoff, the AT communicates with HRPD AN over IP. Therefore, a specification which defines how HRPD packets are communicated over IP is needed.

4 Goals Clean and un-ambiguous interaction between “tunnel transport” and upper-layer protocols Minimize impacts to protocols that do not need to be aware of the tunnel or of the physical medium that messages traverse

5 High level design (1) Define new HRPD connection layer, MAC and PHY protocol subtypes to support tunneling –Most of them do not perform specific functions except providing interface with upper layers (session layer and above) so that tunneling operation is transparent to upper layers –Once AT decides to pre-negotiate the HRPD and PPP sessions, all of the HRPD default protocols above Connection Layer are initialized –Protocols at and below Connection Layer are initialized with new subtypes (e.g., Tunnel Airlink Management protocol) This avoids having to define new protocol types and allows protocols above connection layer to remain untouched Otherwise, at least the following protocols above connection layer will be affected: Address Management Protocol, SLP, SNP, Packet Applications, Session Configuration –The new protocol subtypes are simply providing a payload for UDP/IP transport (L3 tunnel). They are being specified as part of HRPD protocol stacks for clarity of interaction with the upper layers and for transparency of the tunneling operation to upper layers Main driver for connection layer is in Tunnel Airlink Management Protocol –Greatly simplify interactions between protocols in connection layer –Main functionality is to setup and maintain IP tunnel In case of HRPD RAN-lite, the new protocols subtypes will run between AT and HRPD RAN-lite, hence there is no change to deployed HRPD ANs. Deployed HRPD ANs will only need to support current HRPD protocols over-the-air. UMB to HRPD handoff interactions with deployed HRPD ANs are only through A13 or A16 interfaces

6 High level design (2) AT needs to negotiate over-the-air HRPD personality (through the tunnel) for use after handoff –This personality will be configured to be the next personality after handoff –No need to commit new personality right away after configuration is done Session configuration just stored negotiated over-the-air personality Tunnel traffic channel does not have idle time out – No session commit until handoff occurs To use the negotiated over-the-air personality after handoff to HRPD –TunnelConnectionClose is sent together with TrafficChannelAssignment to trigger new personality to take effect TrafficChannelAssignment will be generated using over-the-air HRPD personality –If idle session transfer occurs, the “current personality” transferred to other ANs in A13 will be the over-the-air personality

7 HRPD Protocol Stack with New Subtypes

8 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 request UATI or commit session configuration) to avoid change to upper layers protocol –Initiate over-the-air handoff to HRPD Tunnel Overhead Messages Protocol –Provide overhead parameters to HRPD stack through UMB Tunnel Access/Traffic/Control Channel MAC Protocols –Provide appropriate 3GPP2 specific-headers to tunneled packets (e.g., ATI) Null Physical Layer Protocol –Does nothing –Null Physical Layer protocol payload is sent to UDP/IP transport These protocols do not contain real air-interface procedures –Therefore, it could be developed either in TSG-C or TSG-A

9 Call Flows between AT & AN

10 Tunnel Management Protocol State Diagrams at AT at AN

11 Recommendation - Collaborate with TSG-C on the new HRPD protocol subtypes for UMB-HRPD interworking - Since these protocols do not contain real air-interface procedures, therefore, it could be developed either in TSG-C or TSG-A