Title: Placement of ROHC, Authenticator and Requirements for a robust Mobility Management Scheme Abstract: This contribution proposes a new architectural network element called an Access Gateway (AG). Source:Kuntal Chowdhury, Kevin Cramer, Date:January 8, 2007 Recommendation:Review and adopt the recommendations. Notice Starent Networks 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. Starent Networks 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 contributor 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 contributor. Starent Networks 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 contributor other than provided in the copyright statement above.

ROHC Used for IP/UDP/RTP/ESP header compression Requires visibility into all the way up to the application layer (RTP is in application layer) – hence requires DPI capability Requires a relatively stable location for consistent performance Resource intensive operation –needs policy decision for best network resource utilization

ROHC Policy, Subscription Based ROHC with DPI eBTS S-RNC AG/ ROHC eBTS WiFi-AP Other Access Type BS AAA AT AAA/User profile AT PCRF Policy Application Check: User Profile Check: Policy for IP flow Perform DPI and ROHC

ROHC Least Impact Access Technology Handoffs eBTS S-RNC AG/ ROHC eBTS WiFi-AP Other Access Type BS AAA AT AAA/User profile AT PCRF Policy Application Constant ROHC state across access technology HOs

Authenticator Device and User Auth at the AG Home Agent eBTS S-RNC AG/ Authenticator eBTS WiFi-AP Other Access Type BS AAA AT DER or EAPoRADIUS EAPo Signaling Channel AT

Authenticator in the AG Common Authentication Policy Enforcement across various access technologies –Auth –Re-Auth –Relocation –Key derivation, distribution, and caching Authenticator placement at a secure location Authentication transactions in c-pane –No need to establish bearer before authentication Fewer number of AAA SA provisioning points in the network

Mobility Management Scope of L2MM and L3MM Home Agent eBTS AG/PMIP Client/FA eBTS AT eBTS AG/PMIP Client/FA L3MM: PMIP L2MM: R-P G-GR4 WiMAX SAE S2a

L2 MM Protocol Characteristics L2MM (eBTS- eBTS) protocol should perform: –eBTS – AG c-plane functions: Pre-auth Signaling transport Establishment and modification of bearers (tunnels) Charging policy provisioning and Charging info transport back to the AG (if eBTS does charging) Radio QoS policy provisioning Security policy provisioning ( e.g. key distribution and update)

L2 MM Protocol Requirements L2MM protocol should be robust, ideally with three-way handshake capability –Avoids ghost sessions (note: mobile IP has no ack) –No unnecessary restriction on extensions (e.g. current restriction of NVSE size) –No unnecessary message formatting burden (e.g. FA/HA/HoA/CoA fields in mobile IP based protocols) It should be capable of handling high transaction volume for rapid bearer tunnel movement It should be capable of combining multiple functions i.e. tunnel management, QoS policy provisioning etc. A possible candidate can be improved version of R-P or a similar protocol that meets these fundamental requirements

Inter eBTS Interface Used for L2 context transfer for inter eBTS handoffs Also, used for Anchoring and bearer transport if anchoring is needed at an eBTS Existing interface specs (e.g. A13, A16) should be enhanced and used for this interface

L3 MM Protocol Characteristics L3MM (AG- HA) protocol should perform: –AG-HA c-plane functions: Tunnel establishment and occasional refresh L3 Anchoring and L3 MM using PMIP (v4 or v6) Shared or per user SA –mostly preconfigured for shared SA

L3 MM Protocol Requirements L3 Mobility Management: –L3 Anchoring (e.g. home link for routing purposes) –Tunnel setup –Inter AG mobility management via PMIP Moderate to low c-plane transaction volume per user session Interworking with other SDOs over this interface: 3GPP SAE and WiMAX both will use PMIP for interworking

Inter AG Interface AG – AG interface is an important aspect of L3 MM Some fundamental requirements of this interface are: –Intra technology handoff (3GPP2 specific) –Inter technology handoff S2a: 3GPP SAE R4: WiMAX –Must support context transfer of relevant user session states