• 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, kchowdhury@starentnetworks.comKevin Cramer, kcramer@starentnetworks.com

• 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 eBTS

WiFi-AP

Other Access Type BS

AAA

AT

AAA/User profile

AT

AT

PCRF

Policy Application

Check: User Profile Check: Policy for IP flowPerform DPI and ROHC

ROHC Least Impact Access Technology Handoffs

eBTS

S-RNC

AG/ ROHC

eBTS eBTS

WiFi-AP

Other Access Type BS

AAA

AT

AAA/User profile

AT

AT

PCRF

Policy Application

Constant ROHC state across access

technology HOs

AuthenticatorDevice and User Auth at the AG

HomeAgent

eBTS

S-RNC

AG/ Authenticator

eBTS eBTS

WiFi-AP

Other Access Type BS

AAA

AT

DER or EAPoRADIUS

EAPo Signaling Channel

AT

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 ManagementScope of L2MM and L3MM

HomeAgent

eBTS

AG/PMIP Client/FA

eBTS eBTS

AT

eBTS eBTS eBTS

AG/PMIP Client/FA

AG/PMIP Client/FA

AG/PMIP Client/FA

L3MM: PMIP

L2MM: R-P

G-G R4

WiMAXSAE

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