Network Architecture - Stage 3 - Annex: 3GPP2 - WiMAX ...wimaxforum.org/sites/wimaxforum.org/files/technical_document/2011/... · 28 Figure 6 - CDMA CMIP Call Flow ... [1] X.S0011-D,

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture

WiMAX® - 3GPP2 Interworking

WMF-T37-004-R015v03

WMF Approved

(2011-11-14)

WiMAX Forum Proprietary

Copyright © 2011 WiMAX Forum. All Rights Reserved.

WiMAX Forum® Network Architecture WMF-T37-004-R015v03

3GPP2 Interworking

Page - ii


Copyright Notice, Use Restrictions, Disclaimer, and Limitation of Liability. 1

2 Copyright 2011 WiMAX Forum. All rights reserved. 3 4 The WiMAX Forum® owns the copyright in this document and reserves all rights herein. This document is available for 5 download from the WiMAX Forum and may be duplicated for internal use by the WiMAX Forum members, provided that all 6 copies contain all proprietary notices and disclaimers included herein. Except for the foregoing, this document may not be 7 duplicated, in whole or in part, or distributed without the express written authorization of the WiMAX Forum. 8 9 Use of this document is subject to the disclaimers and limitations described below. Use of this document constitutes acceptance 10 of the following terms and conditions: 11 12 THIS DOCUMENT IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND. TO THE GREATEST 13 EXTENT PERMITTED BY LAW, THE WiMAX FORUM DISCLAIMS ALL EXPRESS, IMPLIED AND 14 STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF TITLE, 15 NONINFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE WiMAX 16 FORUM DOES NOT WARRANT THAT THIS DOCUMENT IS COMPLETE OR WITHOUT ERROR AND 17 DISCLAIMS ANY WARRANTIES TO THE CONTRARY. 18 19 Any products or services provided using technology described in or implemented in connection with this document may be 20 subject to various regulatory controls under the laws and regulations of various governments worldwide. The user is solely 21 responsible for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all 22 required authorizations, permits, or licenses for its products and/or services as a result of such regulations within the applicable 23 jurisdiction. 24 25 NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THE 26 APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR REGULATIONS OR THE SUITABILITY 27 OR NON-SUITABILITY OF ANY SUCH PRODUCT OR SERVICE FOR USE IN ANY JURISDICTION. 28 29 NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THE 30 SUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY 31 CERTIFICATION PROGRAM OF THE WiMAX FORUM OR ANY THIRD PARTY. 32 33 The WiMAX Forum has not investigated or made an independent determination regarding title or noninfringement of any 34 technologies that may be incorporated, described or referenced in this document. Use of this document or implementation of any 35 technologies described or referenced herein may therefore infringe undisclosed third-party patent rights or other intellectual 36 property rights. The user is solely responsible for making all assessments relating to title and noninfringement of any technology, 37 standard, or specification referenced in this document and for obtaining appropriate authorization to use such technologies, 38 technologies, standards, and specifications, including through the payment of any required license fees. 39 40 NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES OF TITLE OR NONINFRINGEMENT WITH 41 RESPECT TO ANY TECHNOLOGIES, STANDARDS OR SPECIFICATIONS REFERENCED OR INCORPORATED 42 INTO THIS DOCUMENT. 43 44 IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO THE USER OR TO A THIRD 45 PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS DOCUMENT, INCLUDING, 46 WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTY’S INTELLECTUAL 47 PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY 48 USE OF THIS DOCUMENT, THE USER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX FORUM AND ITS 49 MEMBERS RELATING TO THE USE OF THIS DOCUMENT. 50 51 The WiMAX Forum reserves the right to modify or amend this document without notice and in its sole discretion. The user is 52 solely responsible for determining whether this document has been superseded by a later version or a different document. 53 54 “WiMAX,” “Mobile WiMAX,” “Fixed WiMAX,” “WiMAX Forum,” “WiMAX Certified,” “WiMAX Forum Certified,” the 55 WiMAX Forum logo and the WiMAX Forum Certified logo are trademarks or registered trademarks of the WiMAX Forum. All 56 other trademarks are the property of their respective owners. 57

58


3GPP2 Interworking

Page - iii


TABLE OF CONTENTS 1

1. INTRODUCTION AND SCOPE ....................................................................................................................... 1 2

1.1 BACKGROUND ................................................................................................................................................ 1 3

1.2 TERMINOLOGY ............................................................................................................................................... 1 4

1.3 INTERWORKING SOLUTION MODEL AND ASSUMPTIONS ................................................................................. 2 5

1.4 SCENARIOS ..................................................................................................................................................... 3 6

1.5 CONTROL PLANE PROTOCOLS AND PROCEDURES ........................................................................................... 5 7

1.6 CLIENT MIP REQUIREMENTS ........................................................................................................................ 12 8

1.7 HA AND H-AAA REQUIREMENTS ................................................................................................................ 13 9

1.8 QOS FOR IPV4 .............................................................................................................................................. 13 10

2. WIMAX® PMIP – CDMA2000® CMIP INTERWORKING SOLUTION MODEL AND 11

ASSUMPTIONS ........................................................................................................................................................ 13 12

2.1 ASSUMPTIONS: ............................................................................................................................................. 13 13

2.2 HANDOFF CALL FLOWS AND DESCRIPTION ................................................................................................... 14 14

2.3 CONTROL PLANE PROTOCOLS AND PROCEDURES ......................................................................................... 19 15

2.4 CMIP4 SPECIFIC REQUIREMENTS ................................................................................................................. 19 16

2.5 PMIP4 SPECIFIC REQUIREMENTS ................................................................................................................. 19 17

2.6 DEVICE REQUIREMENTS ............................................................................................................................... 20 18

2.7 HA REQUIREMENTS...................................................................................................................................... 20 19

2.8 H-AAA REQUIREMENTS .............................................................................................................................. 21 20

21

TABLE OF FIGURES 22

Figure 1 - Loosely-Coupled Interworking of WiMAX® with 3GPP2 ........................................................................... 3 23

Figure 2 - MIP4 Registration by a Hybrid WiMAX® – 3GPP2 MIP Client .................................................................. 7 24

Figure 3 - Key Computation and RRQ generation by Hybrid 3GPP2 – WiMAX® MIP Client .................................... 8 25

Figure 4 - MIP4 Associated Transactions, Network Perspective .................................................................................. 9 26

Figure 5 - WiMAX® CMIP Call Flow ......................................................................................................................... 10 27

Figure 6 - CDMA CMIP Call Flow ............................................................................................................................. 11 28

29


3GPP2 Interworking

Page - v


References 1

[1] X.S0011-D, cdma2000® Wireless IP Network Standard, which can be found at 2

http://www.3gpp2.org/Public_html/specs/X.S0011-001-D_v1.0_060301.pdf 3

[2] WMF-T32-001-R015v02 , WiMAX Forum® Network Architecture- Architecture Tenets, Reference Model 4

and Reference Points, and WMF-T33-001-R015, WiMAX Forum® Network Architecture Detailed Protocols 5

and Procedures, Base Specification 6

[3] WMF-T37-003-R010v03_3GPP2-Interworking - Stage 2: Architecture Tenets, Reference Model and 7

Reference Points 8

9

http://www.3gpp2.org/Public_html/specs/X.S0011-001-D_v1.0_060301.pdf


3GPP2 Interworking

Page - 1


1. Introduction and Scope 1

In the spirit of Stage 2 [3], this section specifies the loosely coupled method of interworking between WiMAX®

2

systems and cdma2000®1 systems. This architecture is applicable to an operator that owns both access technologies 3

and provisions its users with a dual mode device (dual radios) that can connect to the core network through any one 4

of the two technologies. 5

1.1 Background 6

The 3GPP2 provides in document 3GPP2 S.R0087-A cdma2000®-Wlan Interworking the requirements for 7

interworking between cdma2000® systems and Wireless Local Area Networks (WLANs). The intent of that 8

document is to extend cdma2000® packet data and multimedia services and/or capabilities to the WLAN 9

environment, and to support inter technology handoff of data sessions or voice calls between WLAN and 10

cdma2000® 1X circuit-switched (CS) environments. 11

According to the document, potential areas of interworking between a WLAN systems and cdma2000® systems 12

may include the following: 13

Common authentication, authorization, and accounting functions to allow for a single bill for access of both 14

systems. 15

Access to common services from both the WLAN and cdma2000® systems. 16

Creation of mechanisms for selecting and switching between the WLAN and cdma2000® systems. 17

Support for mechanisms to allow session continuity as the mobile switches access between the WLAN and 18

cdma2000® systems. 19

Support for mechanisms to allow service continuity as the mobiles switches access between the WLAN and 20

cdma2000® systems (including support for multimedia services). 21

Support for handoff of voice calls between the WLAN and cdma2000® 1X CS-based systems. 22

Based on these classifications, the S.R0087-A cdma2000®-Wlan Interworking requirement document further 23

specifies five interworking scenarios: 24

Scenario 1: Common Billing and Customer Care. 25

Scenario 2: cdma2000® System based Access Control and Charging and Access to the Internet via the WLAN 26

system. 27

Scenario 3: Access to the cdma2000® Packet Data Services via the WLAN system 28

Scenario 4: Session Continuity. 29

Scenario 5: Access to cdma2000® circuit switched services and support of handoff between WLAN and 30

cdma2000® 1X CS systems. 31

1.2 Terminology 32

33

1. Dual Mode Device: A multi radio device with cdma2000® and WiMAX® chipsets that leverages both 34

cdma2000® EVDO/Rev A and WiMAX networks. This device could be a data card/USB/Handset. The 35

dual mode device is also interchangeably referred as dual mode Mobile Node (MN), Mobile Station (MS), 36

Mobile Device in the document. 37

1 1 cdma2000 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational

Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA USA) in the United States.


3GPP2 Interworking

Page - 2


2. Session Continuity (SC): Capability that enables a dual mode device (a multi radio device) to continue its 1

active data session as it changes its active network from cdma2000® technology to WiMAX and vice 2

versa. 3

1.3 Interworking Solution Model and Assumptions 4

WiMAX®

-3GPP2 interworking refers to the integration of a WiMAX access network to an existing 3GPP2 core 5

network infrastructure. Loosely coupled interworking, as specified in Stage 2 [3], is described in this section. The 6

loosely coupled architecture enables a 3GPP2 operator to use common core elements such as AAA, HA, DHCP 7

servers, provisioning and charging elements for both access technologies. 8

The loosely coupled architecture assumes a dual mode device (dual radios) and a connection manager2 that includes 9

an EAP supplicant and most importantly, a client MIP that can set up same bindings (HoA and NAI) with the 10

common HA through any of the available radio links and its associated CoA. The case of Proxy MIP to Proxy MIP 11

inter technology handover is out of scope. 12

To enable interworking between WiMAX and cdma2000®, an assumption about trust existing between the two 13

networks is made. The cdma2000® and WiMAX networks may be within the scope of a single administrative 14

domain or a trust relationship exist between the two networks when they are part of different administrative 15

domains. WiMAX Forum® Network Architecture Stage 2 and 3 [2] does not address roaming and interworking 16

among untrusted domains where devices such as PDIF may be required. 17

The following scenarios can be supported with the loosely coupled approach: 18

Scenario 1: Common Billing and Customer Care. 19

Scenario 2: cdma2000® System based Access Control and Charging and Access to the Internet via the WiMAX 20

system 21

Scenario 3: Access to the cdma2000® Packet Data Services via the WiMAX system 22

Scenario 4: Session Continuity 23

Scenario 5: Access to cdma2000 Circuit Switched Services and Support of Handoff between WiMAX and 24

cdma2000® 1X CS Systems. 25

2 Connection Manager is a software client that runs in the MS to manage radio connection(s) that the MS is capable of.


3GPP2 Interworking

Page - 3


Home Service Provider

Network

Billing

Server

Home

Agent

Home

AAA

3GPP2

Core NetworkLocal

AAA

PDSN/

FA

FA/

AR

Loosely-Coupled

Internetworking

3GPP2 Access

Network

RNC/

PCF

WiMAX

ASN-GW

Laptop with

MIP Client

WiMAX

Card

3GPP2

Card

Wireless MS or

Dual-mode MS

WiMAX Base

Station

1

Figure 1 - Loosely-Coupled Interworking of WiMAX® with 3GPP2 2

1.4 Scenarios 3

The five network access and session mobility scenarios are described in this section. It is described how each of the 4

scenarios can be implemented with the loosely coupled 3GPP2 – WiMAX® interworking architecture. In these 5

scenarios, it is assumed that the 3GPP2 system is the home system of the dual mode devices and the WiMAX 6

system is the visited system for these devices. 7

Scenario 1: Common Billing and Customer Care 8

By definition, when both access technologies are owned by the same operator, this scenario has no impact on the 9

3GPP2 or WiMAX specifications and will not be discussed further. 10

Scenario 2: Access to the Internet 11


3GPP2 Interworking

Page - 4


To provide simple Internet access, the device / user would authenticate itself to the visited WiMAX system using its 1

credentials. It would identify itself by NAI during the authentication exchange, and the realm portion of the NAI 2

would indicate the 3GPP2 home system. This would enable authentication, authorization, and accounting messages 3

to be routed to and from the 3GPP2 home system. Access to the Internet would be via the common 3GPP2 Core 4

Network. 5

Scenario 3: Access to the Home 3GPP2 Services via WiMAX® 6

In loosely-coupled approach, Scenario 3 shall be implemented through the common access to the Home Agent of the 7

3GPP2 home system. As all the 3GPP2 services can be accessed through the HA, the MS can access any of these 8

services offered by the 3GPP2 home network. 9

Scenario 4.a: Session Continuity – Make Before Break using MS with Dual Radios 10

Session continuity means the ability to continue a packet data session when handing off from a cdma2000® 11

interface to a WiMAX interface (or vice-versa). Essentially, this means keeping the IP address (Home Address in 12

Mobile IP) assigned to a MS at one point of attachment so that it can continue to send and receive packets for an 13

ongoing IP session. 14

This scenario can be implemented as client software on the MS together with the deployment of suitable mobility 15

agents in the network such as the 3GPP2 Mobile IP Home Agent. In this case, the client could re-register its current 16

point of attachment (Care-of Address) whenever it changes WiMAX AR/FA or when it switches between WiMAX 17

and cdma2000® interfaces. 18

Seamless session continuity means minimization of packet loss during a change in point of attachment. When 19

handing off between heterogeneous interface technologies, such as between cdma2000® and WiMAX, a seamless 20

handoff can be obtained simply by keeping both interfaces active for a period of time when adequate and 21

overlapping coverage is available. Thus, Mobile IP4 or other registration procedures can take place on the new 22

radio interface while packets are still being sent and received on the old radio interface. With proper management of 23

the two radio interfaces in the MS, no packets should be lost over and above the native error rate of each technology 24

type. In order to minimize packet loss during inter-technology handoff, the HA can accept packets from the previous 25

Care-of Address for a limited period of time. 26

Use of simultaneous binding is for further study. Please note that a dual mode radio device operating in a dual 27

coverage area is assumed in this specification. When dual coverage is not available, break before make algorithms 28

are used and a lengthy data session interruption should be expected. When the handover between WiMAX and 29

cdma2000® technology or vice-versa uses break-before-make type of algorithms, duration of interruption to 30

ongoing sessions is likely higher as compared to the scenario where make-before-break algorithms can be applied. 31

Scenario 4.b: Session Continuity Break Before Make 32

In the case of break before make and PMIP to CMIP scenarios, issues such as dealing with IP address retention 33

need to be addressed and will be studied in the future. In the CMIP to CMIP scenario the client will retain the IP 34

address. 35

Scenario 5: Access to cdma2000® Circuit Switched Services and Support of Handoff between 36

WiMAX® and cdma2000® 1X CS Systems. 37

The device may be able to listen for cdma2000® circuit switched services even when it is in WiMAX network 38

coverage so as to support circuit switched voice and other cdma2000® 1X based services (SMS, location requests, 39

etc.). Voice services are assumed to be supported through cdma2000® 1X circuit switched technology. If VoIP 40

based voice services are available on WiMAX, then the device can utilize that service for voice services. This 41

scenario is for future study Impetus for Loosely-Coupled Scheme. 42

1.4.1 Impetus for Loosely-Coupled Scheme 43

The loosely-coupled solution complies with the 3GPP2 S.R0087-A cdma2000®-Wlan Interworking requirements. 44

The motivation is to make available an interworking solution for an operator that owns and operates both networks. 45

In order to enable interworking between WiMAX and cdma2000® networks, this architecture leverages the 46

capabilities of cdma2000® network entities. It is a very convenient user interface and easy user management for the 47

service provider that controls and operates both access technologies. 48


3GPP2 Interworking

Page - 5


1) The WiMAX and cdma2000® networks can evolve independently. The cdma2000® network only needs to add 1

the function to allow WiMAX users’ access to its AAA infrastructure, in addition to its original functions. 2

2) The users’ MS for this interworking can be WiMAX MS, 1X or 1x EV-DO MS, or dual mode MS for WiMAX 3

and cdma2000® technology. This interworking scheme can also provide access for the WiMAX only users. 4

3) This interworking achieves unified authentication, authorization and accounting for WiMAX and cdma2000® 5

users, which is well-suited to accounting of one-user-one-account or one-user-many-accounts. 6

4) Because of unified authentication, authorization and accounting and the unified access model, it will be 7

convenient to realize the unified management for WiMAX and cdma2000® users, which will be a great 8

advantage to the service providers. 9

5) Because of the unified access server point, data service continuity can be carried through WiMAX and 10

cdma2000® networks for Simple IP’s access mode, and data service can be kept continuous in the process of 11

handoff between and across WiMAX and cdma2000® networks. 12

6) Handoff between WiMAX and cdma2000® networks is processed by Mobile IP’s access mode. This method 13

requires a common HA (Home Agent) network element and needs support for Mobile IP in the MS. 14

7) In the process of data services, the users can be provided the best services and need not concern if the access 15

network is WiMAX or cdma2000®. That is, when the user is in WiMAX service area, the access network will 16

be WiMAX, and when there is no sufficient WiMAX signal, the access network will be cdma2000® network. If 17

so provisioned, the user MAY control the type of access network and decide if hand over should be executed 18

when the user enters a WiMAX area. 19

20

1.5 Control Plane Protocols and Procedures 21

This section provides the detailed description of WiMAX®

-cdma2000® interworking. 22

1.5.1 Network Access Differentiation 23

The mobile uses an implementation-specific indication to identify the type of network it is accessing; e.g., whether it 24

is the cdma2000® network, WiMAX network, etc. 25

In the absence of, or in addition to any other assured implementation-specific indications that the mobile is 26

accessing either the WiMAX or cdma2000® network, the CMIPv4 capable MS MAY use other methods (e.g. 27

unique 3GPP2 mobility extensions or features). 28

If mobile determines that it accessed the 3GPP2 network, the mobile shall behave according to the IETF RFC 3012. 29

That is, the MS may possibly use either opaque or pre-configured value of SPI associated with authentication 30

Scenario Interworking Scenario Impact to WiMAX® –cdam2000® Interworking

1 Common Billing and Customer Care Loosely-Coupled: No impact on WiMAX and cdma2000® standards; possible to support

2 cdma2000® System based Access Control and Charging and Access to the Internet via the WiMAX system

Loosely-Coupled: No impact on WiMAX standard if independent access to both networks are supported by MS. Possible to support

3 Access to the cdma2000® Packet Data

Services via the WiMAX system

Loosely-Coupled: No impact on WiMAX standard if independent access to both networks are supported by MS. Possible to support

4 Session Continuity Loosely-Coupled: The continuity of a packet data session while switching of network connection takes places between the available access systems. Possible to support no impact.

5

Access to cdma2000® circuit switched services & support of handoff between WLAN and cdma2000® 1X CS systems

Impacts WiMAX standard, cdma2000® circuit switched services cannot be accessed from WiMAX network.

Not Supported.


3GPP2 Interworking

Page - 6


extensions. Value of SPI SHALL indicate specific security association between MS and HA (MN-HA key) and 1

algorithm used in computation of the MN-HA Authentication Extension. 2

If the mobile determines that it accessed the WiMAX network, the mobile SHALL comply with IETF RFC 3344. 3

Specifically, among other required processes, MS will generate and include the MN-HA Authentication Extension 4

in the MIP4 RReq or MIP6 BU. For this the MS will use the MN-HA key bootstrapped from the MIP-RK, which is 5

in turn computed from the EMSK, upon successful completion of EAP Access Authentication Procedures. 6

MS shall use the value of the SPI associated with current MIP4 or MIP6 security association. This value will be set 7

to SPI-CMIP4 or SPI-CMIP6 accordingly, computed from the EMSK upon successful completion of EAP-based 8

Device/User Network Access Authentication and Authorization Access Procedures. Therefore, a tight deterministic 9

association will be created between the SPI and all Mobile IP keys. 10


3GPP2 Interworking

Page - 7


1.5.1.1 MIP Registration by the MS 1

Figure 2 shows the registration process and the SPI selection, as described in WiMAX Forum® Network 2

Architecture Stage 3 Section 4.3.5.1, for use in the MIP registration by the hybrid 3GPP2-WiMAX® MIP Client. 3

The modem cards/radio in the MS indicates the specific access technology to the connectivity client. 4

Access NW

Determination

MS Supports

CMIP?

Generate

MN-HA Key,

SPI-CMIP

Send DHCP Req

NO

YES

Any other SPI

active?

SPI Avoidance

Mechanism

SPI-CMIP =

Any other

active SPI?

Generate

MN-HA-AE

Send RRQ

Select SPI for

MN-HA &

MN-AAA Auth

Extensions per

3GPP2 specs

Generate MN-

AAA-AE

3GPP2WiMAX

NO

YES

NO

YES

5

Figure 2 - MIP4 Registration by a Hybrid WiMAX® – 3GPP2 MIP Client 6


3GPP2 Interworking

Page - 8


Figure 3 shows a simplified process of computation of Mobile IP keys and Registration Requests by a MIP4 Hybrid 1

WiMAX®

-3GPP2 Client. 2

MN-AAA and

MN-HA Pre-

provisioned

Access

Technology?

MN Obtain link

type indication

Generate RRQ

Include MN-HA-AE

SPI=SPI-CMIPv4

NAI and Revocation

Support

Generate RRQ

Include:

MN-AAA-AE

MN-HA-AE

SPI

MN-FACE NAI

MN-HA &

SPI-CMIPv4

computed

from EMSK

WiMAX3GPP2

3

Figure 3 - Key Computation and RRQ generation by Hybrid 3GPP2 – WiMAX® MIP Client 4

1.5.1.2 MIP Registration Process in the WiMAX® Network 5

The following is the summary of logical steps in the process. 6

1) 3GPP2 PDSN/FA will receive the MIP_RReq that contains FA CHALLENGE extension and MN-AAA-AE. As 7

specified in X.S0011 [1], the PDSN/FA will issue the RADIUS Access Request to the H-AAA to validate the 8

MN-AAA-AE, even if the routable HA-ID is included in the MIP_RReq. Once the Access Accept is received, 9

the PDSN/FA will copy/forward the MIP_RReq to the HA. 10

2) The WiMAX FA/A_DPF in the ASN will receive the MIP_RReq that does not contain MN-AAA-AE and MN-11

FACE. The WiMAX FA/A_DPF will already have the routable HA-ID from the RADIUS Access Accept 12

received at the successful completion of the EAP Access Authentication process. If for some reason MN-AAA 13

AE is delivered to the WiMAX FA/A_DPF, the MIP_RReq will be rejected with an error code 65 14

(administratively prohibited). If for some reason MN-FACE is delivered to the WiMAX FA/A-DPF, the 15

extension will be dropped and will not be forwarded If not rejected the FA/A_DPF forwards the MIP_RReq to 16

the HA. 17

3) The HA examines the SPI associated with the MN-HA-AE against a local database of active MN-HA keys. If 18

the MN-HA key associated with SPI is present, HA validates MN-HA-AE. Otherwise, HA requests the MN-HA 19

key from the H-AAA to validate the MN-HA-AE included in the MIP_RReq. 20

4) The H-AAA has to distinguish between X.S0011 [1] and WiMAX access in order to apply correct rule for 21

deriving the MN-HA key. This is accomplished by examining the SPI associated with MN-HA-AE. 22

If SPI reported by HA is equal to SPI-CMIP4, H-AAA returns the WiMAX MN-HA key associated 23

with MIP4 to the HA. 24

If SPI reported by HA is equal to SPI-PMIP4, H-AAA returns the WiMAX MN-HA key to the HA. 25

If SPI reported by HA is equal to SPI-CMIP6, H-AAA returns the WiMAX MN-HA key associated 26

with MIP6 to the HA. 27


3GPP2 Interworking

Page - 9


If SPI reported by HA is not equal to either SPI-CMIP4, SPI-CMIP6, or SPI-PMIP4, H-AAA returns 1

the current pre-provisioned 3GPP2 MN-HA key to the HA, if allowed by local policy. 2

5) HA validates the MN-HA-AE and issues the MIP_RRep, which is then forwarded by the FA to the MN. 3

Note: Although the HA-ID should be obtained during the initial WiMAX access process, the MIP client can also 4

obtain it dynamically by setting the HA field in the MIP_RReq to either 255.255.255.255 or 0.0.0.0 (ALL-ZERO-5

ONE-ADDR). 6

Simplified flowchart in Figure 4 exemplifies processing of the MIP4 RRQ by network elements. 7

MN-AAA-AE

Valid?

Assign HA-ID

SPI Exist?

MN-HA

Available?

MN-HA-AE

Valid?

CMIP RRQ

Received

Access

determination

HA

can be dynamically selected

RRP

Reject

RADIUS AccessAccept [MN-HA;SPI]

RADIUS AccessRQ[MN-AAA; HA-ID-RQ]

RADIUS AccessAccept[HA-ID]

RRQ [MN-HA-AE]

RADIUS AccessReject

RADIUS AccessRQ[MN-HA-AE; MN-HA Request]

Y

N

Y

WiMAX

3GPP2

N

Y

N

FA AAA

8

Figure 4 - MIP4 Associated Transactions, Network Perspective 9

10


3GPP2 Interworking

Page - 10


1.5.1.3 MIP Call Flows - WiMAX® Network Access 1

(3) RRQ with MN-NAI E, MN-HA AE

(1) Foreign Agent Advertisement

(2) RRQ with MN-NAI E, MN-HA AE

No challenge - no FACE no MN-AAA

(7) RRP with MN-NAI E, MN-HA AE

(6) RRP with MN-NAI E, MN-HA AE

(4) Radius

Access Request

(5) Radius

Access

Response MN-

HA Key if

needed

MS BSASN/

FA

Home

Agent

AAA

Server

Server

2

Figure 5 - WiMAX® CMIP Call Flow 3

1) ASN/FA sends a Foreign Agent Advertisement to the Mobile. 4

2) Mobile sends a Registration Request (MIP_RReq) containing the Mobile NAI Extension (MN-NAI), and the 5

Mobile –Home Authentication Extension (MN-HA) to the ASN/FA. 6

3) ASN/FA sends MIP_RReq on to Home Agent (HA) with MN-NAI and MN-HA. 7

4) If the HA has the MN-HA shared key it validates the MN-HA-AE. Otherwise the HA sends RADIUS Access 8

Request to the AAA Server to request the MN-HA key. 9

5) The AAA returns a RADIUS Access Accept with the MN-HA key to the HA. 10

6) The HA issues a Registration Reply (MIP_RRep) with a Reply code of 0 – “registration accepted” - which is 11

sent to the ASN/FA. Also included are the MN-NAI and the MN-HA. 12

7) The ASN/FA forwards the MIP_RRep “registration accepted” with the MN-NAI and MN HA to the Mobile. 13


3GPP2 Interworking

Page - 11


1.5.1.4 MIP Call Flows – 3GPP2 Network Access 1

(7 ) RRQ with MN- NAI E, MN- HA AE

( optional MN- AAA and MN- FA CE)

(1 ) Foreign Agent Advertisement

with Agent challenge Extension

(4 ) RRQ with MN- NAI E, MN- HA AE

MN- AAA AE and MN FA CE

(11) RRP with MN- NAI E, MN- HA AE, MIN- FA CE

(10) RRP with MN- NAI E, MN- HA AE

(8 ) Radius

Access Request

(9 ) Radius Access

Response MN-HA

key if needed

(2 ) MIP Agent Solicitation

(3 ) Foreign Agent Advertisementwith Agent challenge Extension

(5 ) Radius Access Request with MN- NAI E,

MN- HA AE, MN- AAA AE and MN- FA CE

(6 ) Radius Access Accept + Attributes

MS BSASN/

FA

Home

AgentCN

AAA

Server

2

Figure 6 - CDMA CMIP Call Flow 3

1) PDSN/FA sends a Foreign Agent Advertisement with Agent Advertisement Challenge Extension (AACE) to 4

the Mobile. 5

2) Mobile sends a Mobile IP Agent Solicitation to the PDSN/FA. 6

3) PDSN/FA sends a Foreign Agent Advertisement with Agent Advertisement Challenge Extension (AACE) to 7

the Mobile. 8

4) Mobile sends a Registration Request (MIP_RReq) containing the Mobile NAI Extension (MN-NAI), the Mobile 9

–Home Authentication Extension (MN-HA AE), Mobile-AAA Authentication Extension (MN-AAA AE), and 10

the MN-FA Challenge Extension (MN-FA CE) to the PDSN/FA. 11

5) PDSN/FA sends RADIUS Access Request to the AAA Server including the MN-NAI, MN-HA AE, MN-AAA 12

AE, and the MN-FA CE to validate the MN-AAA AE. 13

6) The AAA returns a RADIUS Access Accept with Attributes to the PDSN/FA. 14

7) PDSN/FA sends MIP_RReq on to Home Agent (HA) with MN-NAI and MN-HA AE (optionally the MN-AAA 15

AE, and the MN-FA CE). 16

8) If the HA has the MN-HA key associated with the SPI, it validates the MN-HA-AE. Otherwise the HA sends 17

RADIUS Access Request to the AAA Server to request the MN-HA key for validating the MN-HA AE. 18

9) The AAA returns a RADIUS Access Accept with the MN-HA key to the HA. 19


3GPP2 Interworking

Page - 12


10) The HA issues a Registration Reply (MIP_RRep) with a Reply code of 0 – “registration accepted” which is sent 1

to the PDSN/FA. Also included are the MN-NAI and the MN-HA AE. 2

11) The PDSN/FA forwards the MIP_RRep “registration accepted” with the MN-NAI, MN-HA AE and the MN-3

FA CE to the Mobile. 4

1.6 Client MIP Requirements 5

As depicted in Figure 7-66 Stage 2 Section 7.8.1.9 [2], the MIP client resides above the Network Interface Card and 6

is part or integrated into the operating system stack. The basic connection setup procedure using CMIP4 is shown in 7

Stage 2 [2], Section 7.8.1.9.1. 8

The MIP4 client is common to both technologies and used by the dual-mode hybrid MS to connect to the 3GPP2 9

and WiMAX networks. Manual and automatic network selection mechanism SHALL be supported. If so enabled by 10

the provisioning operator, in manual mode the user SHALL be able to override any selection criteria. In automatic 11

mode, the MS will select one of the available networks. The automatic network selection procedure and criteria are 12

out of scope for this document. 13

The Mobile IPv4 Client behavior assumes that the Mobility stack in the MS conform to IETF standards such as RFC 14

3344 and SHALL support procedures defined in RFC 3012 for the 3GPP2 access. The remainder of this section 15

describes the detailed Stage 3 node requirements for each phase of the user’s session via CMIP4. 16

If the CMIP4 capable MS receives an Agent Advertisement from the FA that contains CHALLENGE extension, or 17

CHALLENGE extension was delivered to the Mobile IPv4 Client in the previous MIP_RRep during the existing 18

mobility session, the MS SHALL assume behavior according to IETF RFC 3012. 19

Accordingly, the MS SHALL include the CHALLENGE extension in the MIP_RReq. The MS SHALL generate the 20

MN-AAA Authentication Extension according to IETF RFC 3012 and include it in the MIP_RReq. If MS also 21

requests dynamic home agent assignment, it SHALL set the HA field to either 255.255.255.255 or 0.0.0.0 (termed 22

as ALL-ZERO-ONE-ADDR). The MS SHALL compute the MN-HA Authentication Extension according to IETF 23

RFC 3012 and include it in the MIP_RReq. Value of SPI SHALL indicate specific security association between the 24

MS and HA (MN-HA key) and algorithm used in computation of the MN-HA Authentication Extension3. 25

If the CMIP4 capable MS receives an Agent Advertisement from the FA that does not contain CHALLENGE 26

extension, or CHALLENGE extension was not delivered to the Mobile IPv4 Client in the previous MIP_RReply 27

during the same mobility session, the MS SHALL assume behavior according to the remainder of this section. 28

Due to the EAP based method of bootstrapping Mobility Keys, after successful Device/User Network Access 29

Authentication and Authorization, the Mobile IP Client SHALL have access to all the mobility keys that it requires, 30

such as MN-HA-CMIP4, and the outer NAI used during authentication. From the same EAP based bootstrapping, 31

the Mobile IP Client SHALL also have access to the value of the SPI associated with the MN-HA-CMIP4, namely 32

SPI-CMIP4. 33

A CMIP4 capable MS SHALL send a Mobile IPv4 RReq to the FA after it receives an Agent Advertisement (that is 34

received solicited or unsolicited) from the FA containing a new FA-CoA. In the MIP_RReq from the WiMAX 35

network , the MS SHALL include an NAI extension that is consists of the pseudoIdentity@realm that was used as 36

the outer NAI during EAP based Device/User Network Access Authentication and Authorization. 37

As mention before, when the MIP Client starts its access and MIP registration from the WiMAX network, it uses 38

pseudoIdentity@realm. The client will have to apply the same NAI and HoA values during the 3GPP2 MIP re-39

registration process in order to maintain its original mobility binding with the HA and the session. Similarly if initial 40

access is through the 3GPP2 network using a fully qualified user NAI, the same NAI and HoA values will be used 41

for re-registration (re-binding) through the WiMAX systems in order to maintain same HA mobility binding and the 42

session. 43

The MIP_RReq SHALL also contain MN-HA AE, the revocation support extension and may also contain MN-FA 44

AE and FA-HA AE. 45

3 For pre-provisioned value of MN-HA key the value of SPI will most likely also be pre-provisioned, or be opaque.

mailto:pseudoIdentity@realm


3GPP2 Interworking

Page - 13


In the HoA field in the MIP_RReq, if the MS desires a fresh dynamic address allocation by the home agent, it 1

SHALL include 0.0.0.0. 2

If the Mobile IP Client has access to the address of the Home Agent from the EAP based bootstrapping, the Mobile 3

IPv4 Client SHALL set the HA field in the MIP_RReq to this address. Although the address of the HA should be 4

obtained during the initial bootstrapping, the MIP client can also obtain it dynamically by setting the HA field in the 5

MIP_RReq to either 255.255.255.255 or 0.0.0.0 (ALL-ZERO-ONE-ADDR). 6

Upon receiving a MIP_RRep in response to the MIP_RReq with reply code = 0 (success), the MS SHALL use the 7

HoA contained in the MIP_RRep as the HoA for the mobility session. In this case, the HA address contained in the 8

MIP_RRep SHALL be treated as the assigned home agent for the session (if dynamic home agent assignment was 9

requested). 10

The MN-FA Challenge Extension as specified in [2] not supported in WiMAX networks but mandated for 11

cdma2000®. 12

The error handling and retransmission behavior of the MS SHALL be governed by the Mobile IPv4 standard RFC 13

3344. 14

When connected to a WiMAX network, if the MS uses MIP4, it SHALL NOT invoke DHCP for IPv4 address 15

acquisition before starting the Mobile IP procedures. The scenario when the MS performs CMIP4 registration after 16

the network performs PMIP4 procedures is out of scope. 17

1.7 HA and H-AAA Requirements 18

The common HA and AAA elements SHALL comply with both 3GPP2 and WiMAX®

requirements. The AAA 19

needs to support RFC-2865 and RFC-4372 and the HA needs to support NAS-Port-Type (Type 5) and the WiMAX 20

capability (Type 26) attributes. The WiMAX requirements for the HA and H-AAA are listed in Sections 2.7 and 2.8 21

and the ones for 3GPP2 are listed in X.S0011-D [1]. 22

1.8 QoS for IPv4 23

Mapping of service flows with different QoS attributes between 3GPP2 and WiMAX® access technologies during 24

handover is out of scope for this release. It is assumed that for service continuation, the service flow admission at the 25

target technology is done at a lower level and when a session is handed over to the target technology while anchored 26

at the HA, all the flows are handed over and contained within the respected FA to HA tunnels 27

2. WiMAX® PMIP – cdma2000® CMIP Interworking Solution 28

Model and Assumptions 29

2.1 Assumptions: 30

31

1. The dual mode device with Session Continuity is able to connect to WiMAX® networks using DHCP 32

exchange so that Proxy-Mobile IP (PMIP) can be used. Also, the dual mode device is able to connect to 33

cdma2000® networks so that Client Mobile IP can be used. 34

2. The dual mode device camps on one network while trying to acquire a target network without losing IP 35

connectivity or active data session. 36

3. It is assumed that the AAA servers used for cdma2000® access and WiMAX access are either the same or 37

they have access to the same session state and subscriber database. 38

The mechanism for maintaining the AAA session continuity after intertechnology handover where the AAA-39

Session-ID is removed due to the accounting stop message is FFS. 40

41

42


3GPP2 Interworking

Page - 14


WiMAX Network

IP Core Network

cdma2000 Network

MIP tunnel to support internetworking

IMS /non-IMS Core Network

Applications

PDSN (FA)

HA

ASN GW (FA)

CDMA BTS

WiMAX BS

MSMS

H-AAA

1

Figure 7 – Overview of the 3GPP2 – WiMAX® handoff scenario 2

2.2 Handoff Call Flows and description 3

4

This section describes the handoff call flows for mobility between cdma2000® and WiMAX® access systems. It is 5

assumed that the cdma2000® systems uses CMIP4 for network layer connectivity and mobility management and the 6

WiMAX system uses PMIP4 for network layer connectivity and mobility management. 7

2.2.1 3GPP2 CMIP4 to WiMAX® PMIP4 Handoff 8

9


3GPP2 Interworking

Page - 15


RRQ (NAI, CoA-2 , HA=0:0 , HoA=0:0 , CMN-HA AE,

CMN-HA SPI,MN-AAA AE, MN- AAA SPI, FACE)

MS

“Connection Manager”

CDMA WiMAX

PDSN: CoA-2 ASN: CoA-1

PMIPCMIPHA

MN handover to WiMAX

DHCPDISCOVER

a)

b)

c)

d)

e)

f)

g)

h)

i)

j)

k)

l)

m)

AR/AA (NAI,

PMN-HA key)PMIP: RRP

(MN-NAI, CoA-1,

HoA, HA

PMN-HA AE)

DHCPREQUEST

DHCPACK

HAAA

RRQ S=CoA-2 D=HA (HA=0, HoA=0, CMN-

NAI, CMN--HA-AE, FACE, CMN--HA-AAA-AE)

RRP (NAI, CoA-2, HA , HoA,

CMN-HA AE, CMN-HA SPI)

RRP (NAI, CoA-2 , HA, HoA,

CMN-HA AE, CMN-HA SPI)

Device/User Auth

( Initial NAI)

Device/User Auth (NAI, HA

PMN-HA key, PMN-HA SPI)

PMIP: RRQ

(MN-NAI, CoA-1,

HoA = 0, HA

PMN-HA AE)

HoA

WiMAX based RRQ

with different SPI and

extensions

n)

o)

p)

q)

HA value stored at

HAAA

Stored HA value

assigned during

EAP

HA

Access Request (NAI, FACE, CMN-AAA)

Access Accept (NAI, HA)

r)

HoA DHCPOFFER yaddr =

CDMA MIP

Procedure

ASN-HAAA

ASN-MS

s)

Registration Revocation

t)

X.S0011-D Procedures*

1

Figure 8 – 3GPP2 – WiMAX® (CMIP4 – PMIP4) Handoff Call Flow 2

X.S0011-D Procedures* - The transactions shown in this box are for illustrative purposes only. 3

The X.S0011 procedures [1] take precedence over any potential inconsistencies appearing in this box. 4

Description of the Steps: 5

6

a. It is assumed that the HRPD session is already established. The MS builds CMIP RRQ using ALL-ZERO-7

ONES value for HoA and HA fields (dynamic HA and HoA assignment). 8

b. The FA generates a RADIUS Access-Request message including the initial NAI (initial NAI = cdma2000 9

NAI) and MN-AAA Authentication Extension to authenticate MS (as per RFC 3012) and sends the 10

message to the HAAA. 11


3GPP2 Interworking

Page - 16


c. The H-AAA attempts to determine whether the MS has an ongoing mobility session or not. If not found, it 1

creates a new mobility session and stores the assigned HA. 2

d. The H-AAA returns the assigned HA value in a RADIUS Access-Accept message. 3

e. The PDSN/FA relays the RRQ to the assigned HA, FA includes the Revocation Support Extension. The 4

HA value in the MIP RRQ is not changed. The PDSN/FA may remove the MN-AAA AE in the RRQ. 5

Absence of the WiMAX PMIP Access Technology Type extension in the RRQ allows the HA to determine 6

that the RRQ is associated with MS’s cdma2000® access. 7

f. The HA detects that there is no existing mobility binding for the MS, and communicates with AAA to 8

obtain MN-HA key, using NAI as identifier. 9

g. HA validates the RRQ using the Client MN-HA AE (as per X.S0011-D specification [1]). Upon 10

successfully validating the RRQ, the HA assigns HoA for the MS and sends MIP RRP to PDSN/FA. 11

h. The PDSN/FA forward RRP to the MS. 12

i. The MS detects WiMAX coverage and decides to initiate WiMAX network entry procedures as per 13

(WiMAX Forum® Network ArchitectureR1.5 specification). Note that a new WiMAX session is 14

established at the time the MS decides to handover from the 3GPP2 network to the WiMAX network. 15

j. The MS uses the same NAI value (initial NAI = cdma2000 NAI) that it used to connect to the cdma2000® 16

network (ref step b) as the NAI for the outer value to perform access authentication (EAP) in the WiMAX 17

network. 18

k. Upon successful access authentication, the H-AAA retrieves the stored HA value from step c and generates 19

the mobility keys 20

l. The H-AAA sends the previously assigned HA and mobility keys to the Authenticator ASN at the 21

completion of access authentication for the MS. 22

m. Upon completion of WiMAX network entry, the MS broadcasts a DHCPDISCOVER message. In addition, 23

DHCPDISCOVER may carry previously assigned HoA in yiaddr. 24

n. The DHCP proxy receives the DHCPDISCOVER and determines the MS associated with the data path 25

over which the DHCP message was received. The PMIP client, on behalf of the MS, generates a MIP RRQ 26

using the NAI returned by the HAAA used for initial binding,, the HA, and the mobility keys received in 27

step l. RRQ SHALL contains PMIP Access Technology Type Extension (draft-leung-mip4-proxy-mode-28

06.txt) indicating WiMAX access type and SHALL also includes the Revocation support Extension. RRQ 29

may contain previously assigned HoA received from H-AAA or in DHCPDISCOVER 30

o. The HA receives MIP RRQ and detects the presence of PMIP Access Technology Type extension. This 31

determines that the RRQ is associated with MS’s session over a WiMAX ASN. The HA locates the 32

existing mobility binding by using the NAI value in the RRQ as the index. 33

p. In order to validate the RRQ, the HA (after detecting that SPI had changed) generates a RADIUS Access-34

Request message including the MN-NAI and MN-HA authenticator extensions and sends the message to 35

the H-AAA. The AAA server authenticates the user and sends an Access-Accept message back to the HA. 36

q. Upon successfully validating the RRQ, the HA updates the binding with the CoA of the WiMAX ASN-GW 37

(CoA-1) for the MS’s WiMAX access. .The HA also in step p replies to the PMIP client with MIP RRP. 38

r. After removing old binding HA sends a Registration Revocation message to remove the CDMA session. 39

s. Upon receiving the RRP from the HA with successful registration indication, the PMIP client prompts the 40

DHCP proxy to generate a DHCPOFFER and send it to the MS. 41

t. MS completes DHCP procedures (Request and Ack) as per WiMAX Forum® Network Architecture R1.5 42

[2] and continues with the data session over the WiMAX access. 43

Note: The session removal in the cdma2000® network is FFS. 44

45


3GPP2 Interworking

Page - 17


1

2.2.2 WiMAX® PMIP4 to 3GPP2 CMIP4 Handoff 2

a)

b)

c)

d)

e)

f)

g)

h)

i)

MN

“Connection Manager”

CDMA WiMAX

PDSN: CoA-2 ASN: CoA-1

CMIPHA HAAA

HoA

AR/AA (NAI ,

PMN-HA key)PMIP: RRP

(NAI, CoA-1,

HoA, HA

PMN-HA AE,

PMN-HA SPI)

PMIP: RRQ

(NAI, CoA-1,

HoA=0:0 , HA

PMN-HA AE,

PMN-HA SPI)

j)

k)

l)m)

n)

o)

p)

q)

r)

HA

s)

1 . Assigns HA2 . Stores assigned HA

MN handover to CDMA

PMIP

1 . Looks for assigned

HA from step “b”

2 . Returns HA value

1 . HA locates binding associated w / NAI

2 . HA obtains HoA for existing session

3 . HA updates the binding with CoA-2

Device User Auth (NAI

/

)

Device/User Auth HA,

PMNHA, PMN-HA SPI )

NAI( ,

-

DHCPDISCOVER

,

,

DHCPOFFER

DHCPREQUEST

DHCPACK

RRQ(CoA-2, HA = 0, HoA

FACE

= 0, CMN-NAI, CMN

CMN-AAA)

-HA,

, AR (NAI, FACE, MN-AAA)

AA (NAI, HA)

MIP RRQ S=CoA-2 =HA

CMN-NAI, CMN-HA-AE,, , FACE

(HA=0, HoA=0,

CMN-AAA)

D

MIP RRP (HA, HoA, CMN-HA-AE)

MIP RRP (HA, HoA, CMN--HA-AE)

ASN-HAAA /

ASN-MS/

CDMA MIP

Procedures-

t)

u)Registration

Revocation

X.S0011-D Procedures*

3

Figure 9 – WiMAX® – 3GPP2 (PMIP4 – CMIP4) Handoff Call Flow 4

X.S0011-D Procedures* - The transactions shown in this box are for illustrative purposes only. 5

The X.S0011 procedures [1] take precedence over any potential inconsistencies appearing in this box. 6


3GPP2 Interworking

Page - 18


1

Description of the Steps: 2

3

a. The MS connects to WiMAX network and initiates access authentication (EAP) using an initial NAI (initial 4

NAI = cdma2000 NAI). 5

b. Upon successful access authentication (i.e. EAP success), H-AAA assigns an HA for the MS’s session and 6

stores that HA value. 7

c. The H-AAA completes access authentication by sending an Access-Accept to the Authenticator ASN. In 8

this message it includes the assigned HA value and the necessary mobility keys. 9

d. Because there is no data session active, the MS broadcasts a DHCPDISCOVER message. 10

e. The DHCP proxy receives the DHCPDISCOVER and determines the MS associated with the data path 11

over which the DHCP message was received. The PMIP client, on behalf of the MS, generates a MIP RRQ 12

using the initial NAI, the HA, and the mobility keys, received in step c. The RRQ SHALL contain PMIP 13

Access Technology Type Extension (draft-leung-mip4-proxy-mode-06.txt) indicating WiMAX access type 14

and also SHALL include the Revocation support Extension. The PMIP Client then sends the MIP RRQ to 15

the HA. 16

f. Upon receiving the RRQ, the HA detects the presence of PMIP Access Technology Type Extension. This 17

determines that the RRQ is associated with the MS’s access over a WiMAX network. The HA detects that 18

there is no existing mobility binding for the MS (identified by the NAI). The HA initiates AAA interaction 19

as per WiMAX Forum® Network Architecture R1.5 spec to fetch the mobility keys necessary to validate 20

the authentication extensions in the RRQ. 21

g. After successfully validating the RRQ, the HA assigns HoA for the MS and responds to the PMIP client 22

with a MIP RRP. 23

h. The PMIP client validates the RRP and prompts the DHCP proxy to generate a DHCPOFFER with the 24

assigned HoA to the MS. 25

i. The MS responds to the DHCPOFFER with a DHCPREQUEST 26

j. The DHCPPROXY replies to the DHCPREQUEST with a DHCPACK and the WiMAX data session setup 27

is complete 28

k. The MS detects cdma2000® network coverage and decides to initiate network entry into the cdma2000 29

network. If the MS already has a dormant session in the cdma2000 Network, the session is re-activated. 30

l. Upon receiving Agent Advertisement from the PDSN/FA in the cdma2000® network, the MS constructs 31

CMIP4 RRQ using zero values in the HoA and HA fields. The MS also includes MN-FA CE, MN-AAA 32

AE and NAI extension as per X.S0011-D specification [1]. The value in the NAI extension contains the 33

same NAI (initial NAI = cdma2000 NAI) that the MS used to access the WiMAX network in step a. 34

m. The PDSN/FA receives the RRQ and generates a RADIUS Access-Request message in order to validate the 35

MN-AAA AE for the MS (identified by the NAI in the NAI extension) with the H-AAA server. This step is 36

performed as per X.S0011-D specification [1]. 37

n. The H-AAA searches for an HA IP value associated with the NAI. It assigns the same HA from the MS’s 38

session state database. This is the HA that the MS was assigned in the WiMAX system. 39

o. The AAA returns this HA IP value to the PDSN/FA along with the Access-Accept message. The AAA 40

server does not instruct the PDSN/FA to remove the MN-AAA AE from the RRQ while forwarding it to 41

the HA. 42

p. The PDSN/FA forwards the RRQ to the assigned HA from step o. The PDSN/FA may remove the MN-43

AAA AE from the RRQ. The PDSN includes the Revocation Support Extension. 44

q. The HA receives MIP RRQ and detects the absence of PMIP Access Technology Type extension. This 45

determines that the RRQ is associated with MS’s session over a cdma2000® network. The HA locates the 46


3GPP2 Interworking

Page - 19


existing mobility binding by using the NAI value in the RRQ as the index. In order to validate the RRQ, the 1

HA processes the included authentication extensions (MN-AAA AE, MN-HA and if present FA-HA AE). 2

The included SPI values in these extensions indicate to the HA that the security associations are different 3

than the one it currently has (i.e. security associations associated with the WiMAX access for the MS). If 4

the HA does not have the necessary security associations (mobility keys) corresponding to the SPI values in 5

these extensions, the HA initiates interaction with the AAA server (as per X.S0011-D specification [1]) 6

obtain MN-HA key, using NAI as identifier. 7

r. Upon successfully validating the RRQ, the HA updates the binding with the CoA of the cdma2000 8

PDSN/FA (CoA-2) for the MS’s cdma2000 access. 9

s. The HA generates a MIP RRP and sends it to the PDSN/FA including the HoA value associated with the 10

existing MIP session. 11

t. Upon receiving the RRP from the HA with successful registration indication, the FA/PDSN validates the 12

necessary authentication extensions (FA-HA if present) and then sends it to the MS. The MS in turn 13

validates the RRP and if successful moves ahead with the packet data session over the cdma2000® access. 14

u. The HA sends Registration Revocation to the FA in the ASN-GW, removing the WiMAX session. 15

16

Note: It should also be noted that assignment of the same address to another interface when the MN moves from one access type 17 to another does not guarantee session continuity. As an example, additional software such as a shim to hide the physical interface 18 may be required to enable session continuity. 19

2.3 Control Plane protocols and Procedures 20

2.3.1 Network Access Differentiation 21

22

The HA identifies that the RRQ came from WiMAX® by the presence of the PMIP Access Technology Type 23

Extension (draft-leung-mip4-proxy-mode-06.txt) indicating WiMAX access type. 24

2.4 CMIP4 Specific Requirements 25

The dual mode device SHALL use the same NAI that it used in the WiMAX® system as an outer NAI while 26

constructing the RRQ in the cdma2000® system. 27

28

2.5 PMIP4 Specific Requirements 29

30

1. The dual mode device SHALL use the NAI that is pre-provisioned for access in cdma2000® system while 31

performing access authentication in the WiMAX® system. The pre-provisioned cdma2000® system NAI 32

SHALL be used both as inner and as outer NAI in the WiMAX access. 33

2. The device and the network SHALL support all PMIP4 requirements documented in the WiMAX Forum® 34

Network Architecture [2]. 35

3. When the MS moves from cdma2000® to WiMAX, the HAAA SHALL assign the same HA that was 36

assigned when the MN was in the cdma2000® network. The Access Accept message includes the assigned 37

HA value as part of the access authentication procedure. 38

4. The PMIP4 RRQ message SHALL contain only the following extensions: 39

a. MN_NAI 40

b. MN_HA 41

c. PMIP Access technology type extension indicating the WiMAX access type. 42


3GPP2 Interworking

Page - 20


d. Revocation Support extension 1

e. FA-HA optional 2

5. The PMIP4 RRQ message SHALL NOT contain the MN-AAA AE. 3

4

2.6 Device Requirements 5

In this solution, the dual mode device camps on one network while trying to acquire a target network without losing 6

IP connectivity or active data session. 7

8

1. The dual mode MS SHALL use the static NAI (the NAI that is pre-provisioned for access to the cdma2000 9

system) on both cdma2000® and WiMAX network authentication. 10

2. The dual mode MS SHALL support simultaneous radio connections on each access network while 11

changing between cdma2000 EVDO and WiMAX networks, if coverage is available on both networks. 12

3. The dual mode MS SHALL use DHCP in WiMAX so that all PMIP4 specific requirements as documented 13

in WiMAX Forum® Network Architecture [2] apply. 14

4. The CMIP4 RRQ message SHALL contain the following extensions in the following order: 15

a. MN_NAI 16

b. MN_HA 17

c. MN_FA (Optional) 18

d. MN_AAA 19

e. Foreign Agent Challenge Extension (FACE) 20

21

2.7 HA Requirements 22

23

The Home Agent SHALL support the following requirements for dual mode device session continuity: 24

25

1. The HA SHALL recognize the identity of the radio access technology by examining the CVS Extension 26

appended by the ASN-GW. If in the future the PDSN also appends a CVSE, the value carried will provide 27

the access type. 28

2. The HA MAY update mobility bindings for different access technology types while temporarily 29

maintaining the prior binding. 30

3. The same HA SHALL be able to handle in-transit packets from the MS with the previous Care-of Address 31

when the mobility binding is already switched and pointing to a new Care-of Address. This is to mitigate 32

packet loss in the uplink during seamless mobility across access technologies. 33

4. The HA SHALL enforce the use of same NAI on both access networks. If the NAI in a RRQ message does 34

not match the same in existing mobility bindings, the HA SHALL treat the RRQ as a new MIP registration. 35

5. For PMIP4 based RRQ processing, the HA SHALL follow the procedures defined in [2] to interact with the 36

AAA server. For CMIP4 based RRQ processing, if the HA determines that the RRQ is associated with a 37

cdma2000® access, the HA SHALL use X.S0011-D specific procedures [1] to interact with the AAA 38

server. 39

6. The HA SHALL support session revocation. 40


3GPP2 Interworking

Page - 21


7. The HA MAY support simultaneous binding, in particular for the support of HO between PMIP and CMIP. 1

2

2.8 H-AAA Requirements 3

4

1. For WiMAX®, the AAA SHALL perform access authentication when the MS uses static NAI. The AAA 5

server shall perform the access authentication procedures as per WiMAX Forum® Network Architecture 6

R1. 0 Rev 1.3 specification. 7

2. For WiMAX, the AAA SHALL assign an HA upon successful access authentication (EAP completion) and 8

reply to the Authenticator ASN with the assigned HA (in Access-Accept). 9

3. For cdma2000® technology, the AAA SHALL perform MN-AAA AE authentication as per X.S0011-D 10

specification [1]. In cdma2000® systems, the MS uses static NAI by default. 11

4. For cdma2000® technology, the AAA SHALL assign an HA during MN-AAA authentication and reply 12

with an Access Accept including the assigned HA address. 13

5. The AAA SHALL store the assigned HA to support session continuity. 14

6. The AAA SHALL assign the same HA for both WiMAX and cdma2000® session set-ups. Re-registrations 15

and mobility management. 16

7. The AAA SHALL maintain the NAI to HA-IP@ association for a configurable duration after receiving an 17

indication of session termination from the source network. 18

19

20

21

Documents

Network Architecture - Stage 3 - Annex: 3GPP2 - WiMAX ...wimaxforum.org/sites/wimaxforum.org/files/technical_document/2011/... · 28 Figure 6 - CDMA CMIP Call Flow ... [1] X.S0011-D,