UMB and HRPD/1x Interworking

3GPP2 X.S0054-610-0 Version 1.0 Date: August 29, 2008

UMB and HRPD/1x Interworking

COPYRIGHT 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

This page is left blank intentionally.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

i 0BContents

UMB and HRPD/1x Interworking

CONTENTS 1 Introduction..............................................................................................................................................1

1.1 Scope..........................................................................................................................................1

2 References................................................................................................................................................2 2.1 Normative References................................................................................................................2 2.2 Informative References..............................................................................................................4

3 Interworking Architecture ........................................................................................................................5 3.1 UMB and HRPD/1x Interworking Architecture without Tunneling..........................................5 3.2 UMB and HRPD Interworking Architecture through IP Tunneling ..........................................5 3.3 UMB and 1x Circuit Interworking Architecture through IP Tunneling.....................................7

4 Target System Discovery .........................................................................................................................8 4.1 Local Domain Name Discovery.................................................................................................8

4.1.1 DHCPv4 Option ..........................................................................................................8 4.1.2 DHCPv6 Option ..........................................................................................................9

4.2 HRPD RAN/RAN-lite IP Address Resolution...........................................................................9 4.3 UMB RAN/RAN-lite IP Address Resolution ............................................................................9 4.4 1x RAN/RAN-lite IP Address Resolution ...............................................................................10 4.5 UMB to HRPD Handoff ISF IP Address Resolution...............................................................10 4.6 HRPD to UMB Handoff ISF IP Address Resolution...............................................................11 4.7 UMB to 1x Handoff ISF IP Address Resolution......................................................................11

5 IPsec Tunnel Operation..........................................................................................................................12 5.1 Tunnel Establishment...............................................................................................................12

5.1.1 AT Requirements.......................................................................................................12 5.1.2 ISF Requirements ......................................................................................................12 5.1.3 HAAA Requirements ................................................................................................13

6 CMIPv4 Based Approach.......................................................................................................................14 6.1 Common Requirements ...........................................................................................................14

6.1.1 AGW Requirements ..................................................................................................14 6.1.2 HA Requirements ......................................................................................................14 6.1.3 AAA Requirements ...................................................................................................14

6.2 Requirements for handoff from UMB to HRPD......................................................................14 6.2.1 AT Requirements.......................................................................................................14 6.2.2 PDSN Requirements..................................................................................................15

6.3 Requirements for handoff from HRPD to UMB......................................................................15 6.3.1 AT Requirements.......................................................................................................15 6.3.2 PDSN Requirements..................................................................................................15

7 CMIPv4/PMIPv4 Based Approach ........................................................................................................16

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

0BContents ii

7.1 Common Requirements............................................................................................................16 7.1.1 AGW Requirements...................................................................................................16 7.1.2 HA Requirements ......................................................................................................16 7.1.3 AAA Requirements ...................................................................................................16

7.2 Requirements for handoff from UMB to HRPD......................................................................16 7.2.1 AT Requirements.......................................................................................................16 7.2.2 PDSN Requirements ..................................................................................................17

7.3 Requirements for handoff from HRPD to UMB......................................................................17 7.3.1 AT Requirements.......................................................................................................17 7.3.2 PDSN Requirements ..................................................................................................17

8 PMIP Based Approach ...........................................................................................................................18 8.1 Requirements for Handoff from UMB to HRPD .....................................................................18

8.1.1 AT Requirements.......................................................................................................18 8.1.2 AGW Requirements...................................................................................................18 8.1.3 PDSN Requirements ..................................................................................................19 8.1.4 HA Requirements ......................................................................................................21 8.1.5 LMA Requirements ...................................................................................................21 8.1.6 AAA Requirements ...................................................................................................21

8.2 Requirements for Handoff from HRPD to UMB .....................................................................21 8.2.1 AT Requirements.......................................................................................................21

9 Call Flows ..............................................................................................................................................22 9.1 ISF Discovery ..........................................................................................................................22 9.2 Handoff Session Pre-setup overview call flow through L3 tunneling......................................23

9.2.1 UMB to HRPD Handoff ............................................................................................23 9.2.2 HRPD to UMB Handoff ............................................................................................24

9.3 IPsec Tunnel Establishment .....................................................................................................25 9.4 CMIP Based Approach Call Flow............................................................................................28

9.4.1 CMIP Based Approach Active Handoff from UMB to the HRPD AN ....................28 9.4.2 CMIP Based Approach Active Handoff from UMB to HRPD through HRPD

AN-Lite......................................................................................................................31 9.4.3 CMIP Based Approach Active Handoff from HRPD to UMB through UMB

AN-Lite/eBS..............................................................................................................34 9.5 CMIP/PMIP Based Approach Call flow ..................................................................................37

9.5.1 CMIP/PMIP Based Approach Active Handoff through HRPD AN-Lite...................37 9.5.2 CMIP/PMIP Based Approach Active Handoff to HRPD AN....................................40 9.5.3 PMIP/CMIP Based Approach Active Handoff from HRPD to UMB through

UMB RAN-Lite/eBS .................................................................................................43 9.6 PMIP Based Approach Call flow.............................................................................................45

9.6.1 PMIP Based Call Flow for Active Handoff through HRPD RAN-Lite using AGW-PDSN Interface ...............................................................................................45

9.6.2 PMIP Based Call Flow for Active Handoff through HRPD RAN-Lite .....................52 9.6.3 PMIP Based Approach Active Handoff from HRPD to UMB through UMB

RAN-Lite/eBS ...........................................................................................................58

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

iii 1BList of Figures

LIST OF FIGURES Figure 1 Architecture for Interworking between UMB and HRPD/1x packet without

Tunneling............................................................................................................................5 Figure 2 UMB-HRPD Interworking Architecture (From UMB to HRPD).......................................6 Figure 3 HRPD-UMB Interworking Architecture (From HRPD to UMB).......................................6 Figure 4 UMB-1x Circuit Interworking Architecture (From UMB to 1x Circuit) ............................7 Figure 5 ISF Discovery ...................................................................................................................22 Figure 6 UMB-HRPD handoff Session Pre-setup overview call flow............................................23 Figure 7 HRPD-UMB handoff Session Pre-setup overview call flow............................................24 Figure 8 Tunnel establishment flow................................................................................................26 Figure 9 CMIP Based Approach UMB-HRPD Handoff.................................................................29 Figure 10 CMIP Based Approach UMB-HRPD Handoff.................................................................32 Figure 11 CMIP Based Approach HRPD-UMB Handoff.................................................................35 Figure 12 CMIP/PMIP Based Approach UMB to HRPD Handoff (with HRPD AN-Lite) ..............38 Figure 13 CMIP/PMIP Based Approach UMB to HRPD Handoff to HRPD AN ............................41 Figure 14 PMIP/CMIP Based Approach HRPD to UMB Handoff...................................................43 Figure 15 PMIP based UMB to HRPD Interworking using AGW-PDSN Interface (PDSN

buffering) ..........................................................................................................................46 Figure 16 PMIP based UMB to HRPD Interworking using AGW-PDSN Interface (AGW

buffering) ..........................................................................................................................50 Figure 17 PMIP based UMB to HRPD Interworking .......................................................................53 Figure 18 IPv4 Addressing................................................................................................................56 Figure 19 IPv6 Addressing................................................................................................................57 Figure 20 PMIP Based Approach HRPD-UMB Handoff .................................................................58

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

2BList of Tables iv

LIST OF TABLES None

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

v 3BRevision History

REVISION HISTORY

Revision Date Remarks

0 v1.0 August, 2008 Initial release

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

4BForeword vi

FOREWORD (This foreword is not part of this Standard.)

This document was prepared by 3GPP2 TSG-X.

This document is a new specification.

This document is part of a multi-part document consisting of multiple parts that together describes Converged Access Network.

This document is subject to change following formal approval. Should this document be modified, it will be re-released with a change of release date and an identifying change in version number as follows:

X.S0054-610-X version n.0

where:

• X an uppercase numerical or alphabetic character [0, A, B, C, …] that represents the revision level.

• n a numeric string [1, 2, 3, …] that indicates an point release level.

This document uses the following conventions:

• “Shall” and “shall not” identify requirements to be followed strictly to conform to this document and from which no deviation is permitted.

• “Should” and “should not” indicate that one of several possibilities is recommended as particularly suitable, without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

• “May” and “need not” indicate a course of action permissible within the limits of the document.

• “Can” and “cannot” are used for statements of possibility and capability, whether material, physical or causal.

X.S0054-610-0 v1.0

3

4

5

6

7

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

1.1 Scope 1 1 Introduction

1

2 1 Introduction

8

9

This document defines the stage-2 and stage-3 requirements for interworking between Ultra Mobile BroadbandTM (UMBTM) 1 Wireless access and HRPD/1x Wireless access in the Converged Access Network

1.1 Scope This document is part of a multi-part document. The multi-part document together describes IP Network operation for the Converged Access Network.

The scope of this document covers support for handoff from UMB to HRPD/1x (Packet and Circuit) and handoff from HRPD/1x to UMB.

1 Ultra Mobile BroadbandTM and (UMBTM) are trade and service marks owned by the CDMA Development Group (CDG).

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

2 References 2 2.1 Normative References

2 References

2.1 Normative References This section provides references to other specifications and standards that are necessary to implement this document.

[1] IETF: RFC 2131, R. Droms, et al. ‘Dynamic Host Configuration Protocol’, March 1997.

[2] IETF: RFC 2132, S. Alexander, et al. ‘DHCP Options and BOOTP Vendor Extensions’, March 1997.

[3] IETF: RFC 3315, R. Droms, Ed. et al. ‘Dynamic Host Configuration Protocol for IPv6 (DHCPv6)’, July 2003

[4] IETF: RFC 3646, R. Droms, Ed. ‘DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)’, December 2003.

[5] 3GPP2: C.S0024-B v2.0, “cdma2000 High Rate Packet Data Air Interface Specification”, April 2007.

[6] 3GPP2: X.S0054-100-0 v2.0, “Basic IP Services for Converged Access Network Specification”, December 2007

[7] IETF: draft-yokota-mipshop-pfmipv6

Editor Note: The above document is a work in progress and should not be referenced unless and until it is approved and published. Until such time as this Editor’s Note is removed, the inclusion of the above document is for informational purposes only.

[8] 3GPP2: X.S0011-002-D, “cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Service”, March 2006.

[9] 3GPP2: X.S0054-102-0 v2.0, “Multiple-Authentication and Legacy Authentication Support for CAN”, December 2007.

[10] IETF: RFC 2406, Kent. S, Atkinson R., “IP Encapsulating Security Payload (ESP)”, November 1998.

[11] IETF: RFC 4306, Kaufman, C., “Internet Key Exchange (IKEv2) Protocol”, December 2005.

[12] IETF: RFC 3948, Huttunen A., et.al., “UDP Encapsulation of IPsec ESP Packets”, January 2005.

[13] IETF: RFC 3579, Aboba, B. and P. Calhoun, “RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)”, September 2003.

[14] 3GPP2: S.S0078-B, “Common Security Algorithms”, February 2008

[15] 3GPP2: X.S0054-110-0 v1.0, “MIP4 Specification in Converged Access Network Specification”, December 2007.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

2.1 Normative References 3 2 References

[16] 3GPP2: X.S0044-0 v1.0, “MIPv4 Enhancements, TBD

Editor Note: The above document is a work in progress and should not be referenced unless and until it is approved and published. Until such time as this Editor’s Note is removed, the inclusion of the above document is for informational purposes only.]

[17] 3GPP2: A.S0008-C v1.0, “Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network”, August 2007.

[18] 3GPP2: A.S0009-C v1.0, “Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Packet Control Function”, August 2007.

[19] 3GPP2: A.S0021-0 v1.0, “Inter-Technology Handoff for Ultra Mobile Broadband (UMB) Radio Access Network Interfaces”


[20] 3GPP2: C.S0084-0 v2.0, “Ultra Mobile Broadband (UMB) Air Interface”, July September 2007.

[21] IETF: RFC 2472, Haskin D., Allen E., “IP Version 6 over PPP”, December 1998.

[22] 3GPP2: X.S0054-220-A v1.0, “Network PMIP Support”, December 2007.

[23] IETF: RFC 2890, Dommetey G., “Key and Sequence Number Extensions to GRE”, September 2000.

[24] IETF: RFC 2784, Farinacci D., et.al.,“Generic Routing Encapsulation (GRE)”, March 2000.

[25] IETF: RFC4988, Koodli R., Perkins C., Mobile IPv4 Fast Handovers”, October 2007.

[26] 3GPP2: X.S0054-910-A v1.0, “CAN Data Dictionary”, December 2007.

[27] IETF: draft-leung-mip4-proxy-mode


[28] IETF: draft-ietf-mip4-dsmipv4


[29] IETF: RFC3543, Glass, et.al., “Registration Revocation in Mobile IPv4”, August 2003.

[30] IETF: draft-yegani-gre-key-extension


X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

2 References 4 2.2 Informative References

[31] IETF: draft-ietf-netlmm-proxymip6


[32] IETF: draft-ietf-netlmm-pmip6-ipv4-support


[33] IETF: draft-muhanna-mext-binding-revocation


[34] IETF: RFC 3925, Littlefield J., “Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)”, October 2004.

[35] IETF: RFC 3579, Aboba, B. and P. Calhoun, “RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)”, September 2003

[36] IETF: RFC 4072, Eronen, et.al, “Diameter Extensible Authentication Protocol (EAP) Application”, August 2005.

[37] IETF: RFC 4187, J. Arkko, “Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)”, January 2006

[38] 3GPP2: X.S0054-400-0 v1.0, “Converged Access Network Accounting Specification”, December 2007.

[39] 3GPP2: A.S0020-0 v1.0, “Interoperability Specification (IOS) for Ultra Mobile Broadband (UMB) Radio Access Network Interfaces”, November 2007.

[40] 3GPP2: X.S0061, “HRPD PMIP Support”


2.2 Informative References This section provides references to other documents that may be useful for the reader of this document.

<1> 3GPP2: X.S0054-000-A v1.0, “CAN Wireless IP Network Overview and List of Parts”, August 2008.

X.S0054-610-0 v1.0

4

5

6

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

40

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

3.1 UMB and HRPD/1x Interworking Architecture without Tunneling 5 3 Interworking Architecture

1

2

3 3 Interworking Architecture

This section specifies the requirements for Simple IPv4 with PMIP Operation

3.1 UMB and HRPD/1x Interworking Architecture without Tunneling

Figure 1 illustrates the architecture reference model for UMB and HRPD/1x packet data interworking without tunneling. In this architecture, the AT tunes to HRPD/1x packet data network to negotiate air interface session, PPP connection and TFTs. Similarly the AT can tune to UMB to negotiate UMB session.

7

8

AT

eBS

RAN PDSN

AGW

SRNC

HA/LMA AAA

A10/A11

HRPD/1x Packet Data Access

UMB

38

39 Figure 1 Architecture for Interworking between UMB and HRPD/1x packet without Tunneling

3.2 UMB and HRPD Interworking Architecture through IP Tunneling

Figure 2 illustrates the architecture reference model for UMB to HRPD handoff. IP tunneling between AT and HRPD RAN/RAN-lite (see [19]) is used to carry HRPD packets. An Interworking Security Function (ISF) serves as a termination point for secured tunnel between the AT and the target HRPD RAN/RAN-Lite over the UMB system.

41

42

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

3 Interworking Architecture 6 3.2 UMB and HRPD Interworking Architecture through IP Tunneling

ISF

AT eBS

PDSN

AGW

SRNC

HA/LMA AAA

A10/A11

HRPD

UMB

HRPD Packets over IP Tunneling

IPsec

RAN/RAN-Lite

Figure 2 UMB-HRPD Interworking Architecture (From UMB to HRPD)

Figure 3 illustrates the architecture reference model for the HRPD to UMB handoff. IP tunneling between AT and UMB RAN-lite/eBS (see [19]) is used to carry UMB packets. An Interworking Security Function (ISF) serves as a termination point for secured tunnel between the AT and the target UMB RAN/RAN-Lite over the HRPD system.

ISF

AT

SRNC

RAN

AGW

UMB RAN-Lite/eBS

HA/LMA AAA

A10/A11

HRPD

UMB Packets over IP Tunneling

UMB

IPsec

PDSN

Figure 3 HRPD-UMB Interworking Architecture (From HRPD to UMB)

X.S0054-610-0 v1.0

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

3.3 UMB and 1x Circuit Interworking Architecture through IP Tunneling 7 3 Interworking Architecture

1 3.3 UMB and 1x Circuit Interworking Architecture through IP Tunneling

Figure 4 illustrates the architecture reference model for the UMB to 1x circuit network handoff. IP tunneling between AT and 1x RAN/RAN-lite (see [19]) is used to carry 1x signaling messages for handoff from UMB to the 1x. An Interworking Security Function (ISF) serves as a termination point for secured tunnel between the AT and the target 1x RAN/RAN-Lite over the UMB system.

AT eBS

MSC/MSCe

SRNC

A1/A1p

1x Circuit

UMB

1x Signaling message over IP Tunneling

IPsec

1x RAN/RAN-Lite

AGW

ISF

A2/A2p

Figure 4 UMB-1x Circuit Interworking Architecture (From UMB to 1x Circuit)

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

4 Target System Discovery 8 4.1 Local Domain Name Discovery

4 Target System Discovery During UMB to HRPD/1x active handoff, the AT needs to discover the IP address of the HRPD/1x RAN (called Target RAN). Similarly for HRPD to UMB active handoff, the AT needs to discover the IP address of the UMB RAN (called Target RAN). In addition, the AT needs to discover the IP address of the Interworking Security Function (ISF) that serves as a termination point for secured tunnel between the AT and the target RAN over the source access networks. The Target RAN and ISF address discovery occurs in two steps. The first step (Section 4.1) is Local Domain Name Discovery where the AT discovers the local domain name that the AT will use in the formation of a FQDN. This step may occur as part of IP address assignment of the AT during power-up. The next step (Sections 4.2, 4.3, and 4.4) is the Target RAN or ISF IP address discovery. In this step the AT uses the FQDN to perform DNS query for resolution of Target RAN or ISF IP address. This step should occur once the HRPD/1x session (for UMB to HRPD/1x handoff) or UMB session (for HRPD to UMB handoff ) establishment through the IP tunnel is required.

4.1 Local Domain Name Discovery This section defines requirements for the Local Domain Name Discovery. The AT should discover the HRPD Operator Domain Name if it performs handoff from UMB to HRPD or discover the UMB Operator Domain Name if it performs handoff from HRPD to UMB via DHCP using DHCP Option or DHCPv6 Option. Upon discovery of Target System Domain Name, the AT shall use the discovered domain name for Target RAN or ISF IP address resolution (see Section 4.2).

4.1.1 DHCPv4 Option

The AT uses the DHCPINFORM message to acquire HRPD AN domain name using DHCP Option 15 (see [2]).

The DHCP server includes Domain Name in Domain Name Option of the DHCPACK message sent to the AT.

4.1.1.1 AT Requirements

See [6] for DHCP requirements on the AT.

The AT shall support DHCP Option 15 as specified in [2] if the DHCP is used to discover domain name.

The AT shall use the DHCPINFORM message to acquire the domain name as per [2].

4.1.1.2 DHCP Server Requirements

Upon receiving a DHCPINFORM message or a Relay message containing a DHCPINFORM message, if the DHCP server is configured with the Domain Name information, the DHCP server shall respond with DHCPACK which includes the Domain Name using DCHP Option 15 as defined in [2].

X.S0054-610-0 v1.0

2

3

4

5

6

9

10

11

12

13

14

15

16

17

18

19

21

22

23

24

25

26

27

28

29

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

51

52

53

54

55

56

57

58

59

60

4.2 HRPD RAN/RAN-lite IP Address Resolution 9 4 Target System Discovery

1 4.1

7

8

20

30

31

49

50

.2 DHCPv6 Option

The AT uses Option Request Option in the INFORMATION-REQUEST [3] message with requested option code set for Domain Search List Option [4].The DHCPv6 server includes Search List Option in the REPLY message to send Domain Name list to the AT.

4.1.2.1 AT Requirements

The AT shall support DHCPv6 Domain Search List Option as specified in [4] if the Domain Name Discovery is used to discover domain name.

If the AT sends INFORMATION-REQUEST message to request Domain Name, the AT shall use Option Request Option (option-code 6) in the INFORMATION-REQUEST message with the requested-option-code set to 24 for requesting domain search name list (see [4] and [3]).

See [6] for additional DHCPv6 requirements for the AT.

4.1.2.2 DHCPv6 Server Requirements

Upon receiving an Information-Request message or a Relay-Forward message containing an Information-Request message containing an Option Request Option with the requested-option-code set to 24 indicating that domain search list is requested, the DHCPv6 server shall include in a Reply the Domain Search List Option.

See [6] for additional DHCPv6 server requirements.

4.2 HRPD RAN/RAN-lite IP Address Resolution The AT resolves the IP address of the HRPD RAN/RAN-lite by performing a DNS query.

For DNS query the AT shall form the FQDN as follows:

<HRPD-subnetSectorID>.HRPD.RAN.<domain-name>

Where:

• <domain-name> is discovered via DHCP (Section 4.1)

• <HRPD-subnetSectorID> is the hex representation in ASCII of the HRPD subnet provided to the AT via the HRPD air-interface [5] or UMB air-interface.

4.3 UMB RAN/RAN-lite IP Address Resolution The AT resolves the IP address of the UMB RAN/RAN-lite by performing a DNS query.


<UMB-ANID>.UMB.RAN.<domain-name>

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

4 Target System Discovery 10 4.4 1x RAN/RAN-lite IP Address Resolution

where:


• <UMB-ANID> is the hex representation in ASCII of the ANID provided to the AT via the HRPD air-interface (See [5]) or UMB air-interface.

4.4 1x RAN/RAN-lite IP Address Resolution The AT resolves the IP address of the 1x RAN by performing a DNS query.

For DNS query the AT shall form the FQDN as follows for DNS query:

<1x-BSID>.1x.RAN.<domain-name>

where:


• <1x-BSID> is the BSID (i.e., SID, NID, BASE_ID) provided to the AT via the 1x air-interface or UMB air-interface. The BSID is a string resulting from the concatenation of SID+NID+ BASE_ID, where each item is encoded using four hexadecimal uppercase ASCII characters.

4.5 UMB to HRPD Handoff ISF IP Address Resolution The AT resolves the IP address of the ISF for establishing an IPsec tunnel by performing a DNS query.


<HRPD-subnet>. HRPD.ISF.<domain-name>

where:


• <HRPD-subnet> is the hex representation in ASCII of the HRBD subnet provided to the AT via the HRPD air-interface (See [5]) or UMB air-interface.

If operator’s policy allows the setup of the IP tunnel between the AT and the target RAN without establishing IPsec tunnel through ISF, the IP address of ISF may be configured to all zeros to indicate to the AT that the establishment of IPsec tunnel to the ISF is not required.

X.S0054-610-0 v1.0

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

4.6 HRPD to UMB Handoff ISF IP Address Resolution 11 4 Target System Discovery

1 4

25

26

.6 HRPD to UMB Handoff ISF IP Address Resolution The AT resolves the IP address of the ISF for establishing an IPsec tunnel by performing a DNS query.

For DNS query the AT shall form the FQDN as follows for DNS query:

<UMB- ANID>.UMB.ISF.<domain-name>

where:


• <UMB-ANID> is the hex representation in ASCII of the UMB ANID provided to the AT via the HRPD air-interface (See [5]) or UMB air-interface.

If operator’s policy allows to setup the IP tunnel without establishing IPsec tunnel through ISF, the IP address of ISF may be configured to all zero to indicate the AT that IPsec tunnel to the ISF is not required to be established.

4.7 UMB to 1x Handoff ISF IP Address Resolution

The AT resolves the IP address of the ISF for establishing an IPsec tunnel by performing a DNS query on the following FQDN.

The AT shall form the FQDN as follows for DNS query:

<1x-BSID>.1x.ISF.<domain-name>

where:


• <1x-BSID> is the BSID (i.e., SID, NID, BASE_ID) provided to the AT via the 1x air-interface or UMB air-interface. The BSID is a string resulting from the concatenation of SID+NID+ BASE_ID, where each item is encoded using four hexadecimal uppercase ASCII characters.

If operator’s policy allows establishing the IP tunnel without establishing IPsec tunnel through ISF, the IP address of ISF may be configured to all zero to indicate the AT that IPsec tunnel to the ISF is not required to be established.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

5 IPsec Tunnel Operation 12 5.1 Tunnel Establishment

5 IPsec Tunnel Operation

5.1 Tunnel Establishment IPsec is established between AT and the Interworking Security Function (ISF) that serves as a termination point for secured IP tunnel between the AT and the target RAN.

5.1.1 AT Requirements

The AT shall support IKEv2 and ESP as specified in [10] and [11].

The AT shall support EAP-AKA with AKA long-term credentials [6] for IKEv2 authentication.

The AT may support EAP-AKA based CAVE authentication mechanism [9] for IKEv2 authentication.

If the AT receives none zero IP address of the ISF through DNS query (see Section 4.5 and 4.6), the AT shall initiate Internet Key Exchange [11] in order to establish trusted relationships (i.e., mutual authentication with the ISF).

The AT shall initiate the EAP based authentication procedures as specified in section 2.1.6 of [11].

The AT shall send its NAI in the IDi payload with ID type set to ID_RFC822_ADDR within the IKE_AUTH request.

Upon completion of the IKEv2 procedures, the AT shall establish an IPsec ESP tunnel to the ISF according to [10].

The AT shall support the NAT traversal per IKEv2 [11] and the UDP encapsulation of IPsec ESP packets [12].

5.1.2 ISF Requirements

The ISF shall support IKEv2 and ESP as specified in [10] and [11].

As initiated by the AT, the ISF shall perform IKEv2 procedures [11] in order to establish trusted relationships (i.e., mutual authentication) with the AT.

The ISF shall extract the EAP messages received from the AT over IKEv2, and send them to the H-AAA via the RADIUS Access-Request or the DER command. The ISF shall extract EAP messages received from the H-AAA and send them to the AT over IKEv2.

Upon completion of the IKEv2 procedures, the ISF shall establish an IPsec ESP tunnel between itself and the AT [10].

In case of IPv6 access, the ISF shall assign a unique prefix to the AT via IKEv2 exchanges.

X.S0054-610-0 v1.0

1

2

3

6

7

8

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

5.1 Tunnel Establishment 13 5 IPsec Tunnel Operation

4

5 5

9

10

31

32

The ISF shall support the NAT traversal per IKEv2 [11] and the UDP encapsulation of IPsec ESP packets [12].

.1.3 HAAA Requirements

The H-AAA shall authenticate the user’s credentials identified by the NAI and perform authentication and authorization.

5.1.3.1 RADIUS Authentication and Authorization

Upon receipt of an Access-Request message from the ISF, if the H-AAA receives an Access-Request containing an EAP-message and Message Authenticator (80), the H-AAA shall execute the EAP method with the EAP peer (i.e., AT) and exchange EAP messages per [13] with the EAP authenticator (i.e., ISF).

If the authentication is successful, the H-AAA shall respond with an Access-Accept message containing the EAP message indicating EAP-Success, Message Authenticator (80), MS-MPPE-Send-Key, and MS-MPPE-Recv-Key.

The Message-Authenticator shall be computed using the HMAC-SHA-256 algorithm [14] over the entire RADIUS packet as specified in [13]. The message length is kept the same, and hence the first 16 octets of the output of the HMAC-SHA-256 function shall be used as the Message-Authenticator value.

If user authentication fails, the H-AAA shall respond with an Access-Reject message containing the EAP message indicating EAP-Failure, and Message Authenticator (80).

5.1.3.2 DIAMETER Authentication and Authorization

Upon receipt of a DER command, the H-AAA shall execute the EAP method with the EAP peer (in the AT) and exchange EAP messages per [11] with the EAP authenticator (in the ISF).

If the AT’s credentials are authenticated successfully, the HAAA shall return DIAMETER_SUCCESS in the Result code AVP via DEA to indicate successful authentication procedure. The HAAA shall also include EAP-Master-Session-Key in DEA.

If the authentication fails, the HAAA shall return DIAMETER_AUTHENTICATION_REJECTED in the Result code AVP via DEA.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

6 CMIPv4 Based Approach 14 6.1 Common Requirements

6 CMIPv4 Based Approach

6.1 Common Requirements This section describes requirements which apply for both handoff from UMB to HRPD and HRPD to UMB.

6.1.1 AGW Requirements

The AGW shall follow the requirements as specified in [8].

6.1.2 HA Requirements

The HA shall follow the requirements specified in [8] or [16] and [15] for CMIPv4 operation.

6.1.3 AAA Requirements

The HAAA shall follow the requirements specified in [8] or [16] and [15] for CMIPv4 operation.

6.2 Requirements for handoff from UMB to HRPD This section describes requirements for the CMIP based handoff from UMB to HRPD system.


Upon obtaining IP addresses of the HRPD RAN or HRPD RAN-Lite (see Section 4.2) and the ISF, and establishing IPsec tunnel with the ISF (see Section 5), the AT performs the HRPD session establishment and the access authentication (if required) with the AN-AAA as specified in [17] or [18] through IP tunnel.

After successful session establishment and access authentication, the AT shall perform the PPP negotiation with the PDSN for CMIPv4 access as required in [8] or [16] through IP tunnel by setting the destination address of the IP tunnel to the discovered target RAN IP address. When the AT receives an FA Advertisement message from the PDSN, the AT should hold sending a MIP RRQ message to the PDSN until the AT or eBS decides to handoff to the HRPD system.

After the PPP is established with the PDSN through IP tunnel, the AT may perform the TFT establishment as required in [8] by setting HoA address assigned by the HA over UMB.

If the AT or eBS decides to handoff to HRPD and HRPD Traffic Channel Assignment procedure completes [19], the AT should send a MIP RRQ message to the PDSN by setting HoA to the assigned IP address through IP tunnel. After the AT tunes to the HRPD system, the AT receives an MIP RRP in response to the RRQ. If the CMIPv4 registration successfully completes, the AT may send and receive data in the HRPD system.

For other procedures, the AT shall follow the requirements in [8] or [16].

X.S0054-610-0 v1.0

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

19

20

21

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

48

49

50

51

52

53

54

55

56

57

58

59

60

6.3 Requirements for handoff from HRPD to UMB 15 6 CMIPv4 Based Approach

1 6.2

17

18

22

23

46

47

.2 PDSN Requirements

If the PDSN supports the handoff from the UMB to HRPD system, the PDSN shall support the tunnel operation indicator as specified in [19].

After an A10 connection is established with the tunnel operation indicator [19], the PDSN shall perform the PPP negotiation as specified in [8].

If the AT performs the TFT establishment procedure before CMIPv4 registration completes, the PDSN shall accept the HoA sent by the AT assuming the same HoA is to be assigned during CMIPv4 registration. If a different HoA is assigned, the PDSN shall renegotiate PPP.

For other procedures, the PDSN shall follow the requirements in [8] or [16].

6.3 Requirements for handoff from HRPD to UMB This section describes requirements for the CMIP based handoff from HRPD to UMB system.


Upon obtaining IP addresses of the UMB eBS or UMB RAN-Lite (see Section 4.3) and the ISF, and establishing IPsec tunnel with the ISF (see Section 5), the AT performs the UMB session establishment [19] and the access authentication as specified in [6] through IP tunnel. Following access authentication, LinkID and DAP assignments are performed as specified in [20].

After successful session establishment and access authentication, the AT shall send an FA Solicitation message to the AGW as specified in [15] through IP tunnel by setting the destination address of the IP tunnel to the discovered target RAN IP address. When the AT receives an FA Advertisement message from the AGW, the AT shall hold sending a MIP RRQ message to the AGW until the AT or eBS decides to handoff to the UMB system.

If the AT or AN decides to handoff to UMB, target eBS is added to the Route Set and the Key Exchange is performed [20]. The AT should send a MIP RRQ message to the AGW through IP tunnel by setting HoA with the assigned IP address. After the AT tunes to the UMB system, the AT receives an MIP RRP in response to the RRQ. If the CMIPv4 registration successfully completes, the AT may send and receive data in the UMB system.

For other procedures, the AT shall follow the requirements in [6].

6.3.2 PDSN Requirements

The PDSN shall follow the requirements as specified in [8] or [16].

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

7 CMIPv4/PMIPv4 Based Approach 16 7.1 Common Requirements

7 CMIPv4/PMIPv4 Based Approach In this scenario, CMIPv4 is used in the UMB network access and PMIP is used in the HRPD network access.

7.1 Common Requirements This section describes requirements which can apply both handoff from UMB to HRPD and HRPD to UMB in CMIP/PMIP based approach.


The AGW shall follow the requirements as specified in [15].


The HA shall follow the requirements specified in [15] and Section 8. An HA for CMIP and a HA for PMIP shall be the same entity.


The HAAA shall follow the requirements specified in [8], Section 8 and [15].

7.2 Requirements for handoff from UMB to HRPD This section describes requirements for the CMIP/PMIP based handoff from UMB to HRPD system.


Upon obtaining IP addresses of the HRPD RAN or HRPD RAN-Lite (see Section 4.2) and the ISF, and establishing IPsec tunnel with the ISF (see Section 5), the AT performs the HRPD session establishment and the access authentication (if required) with the AN-AAA as specified in [17] or [18] through IP tunnel.

After successful session establishment and access authentication, the AT shall perform the PPP negotiation with the PDSN for Simple IPv4 access as required in [8] through IP tunnel. The AT shall set an IP Address Option of IPCP Configure Request message to the assigned HoA..

After the PPP is established with the PDSN through IP tunnel, the AT may perform the TFT establishment as required in [8] by setting IP address assigned during IPCP phase.

If the AT or eBS decides to handoff to HRPD, the AT tunes to the HRPD system as described in [19].

X.S0054-610-0 v1.0

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

27

28

31

32

33

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

7.3 Requirements for handoff from HRPD to UMB 17 7 CMIPv4/PMIPv4 Based Approach

1 7.2

25

26

29

30

34

35

.2 PDSN Requirements

If the PDSN supports the handoff from the UMB to HRPD system, the PDSN shall support the tunnel operation indicator as specified in [19]. If PDSN configures to use PMIP, it shall support PMIP as specified in Section 8.

After an A10 connection is established with the tunnel operation indicator [19], the PDSN shall perform the PPP negotiation as specified in [8]. In this case, the PDSN shall not perform PMIP binding update with the HA during PPP negotiation. The PDSN shall accept the AT’s proposed IP address in the IP address Option of IPCP Configure Request message.

When the PDSN receives A10 Xoff from HRPD RAN, the PDSN shall perform PMIP binding update as specified in Section 8.

If the AT performs the TFT establishment procedure before PMIP binding update completes, the PDSN shall accept the IP address sent by the AT assuming the same IP address is to be assigned during PMIP registration. If a different IP address is assigned, the PDSN shall renegotiate PPP.

For other procedures, the PDSN shall follow the requirements in [8] and section 8.

7.3 Requirements for handoff from HRPD to UMB This section describes requirements for the PMIP/CMIP based handoff from HRPD to UMB.


See Section 6.3.1.

7.3.2 PDSN Requirements

The PDSN shall follow the requirements as specified in Section 8.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

8 PMIP Based Approach 18 8.1 Requirements for Handoff from UMB to HRPD

8 PMIP Based Approach

8.1 Requirements for Handoff from UMB to HRPD


AT requirements are specified in [8] and [6]. Additional AT requirements are specified here.

8.1.1.1 Addressing with IPCP

IPv4 Address Assignment: A simple IPv4 AT that has no IPv4 address assigned to it and requires an IPv4 address shall send IPCP Configure-Request message to the PDSN including IP Address Option with all zeros. The AT shall accept the IP address received in IPCP Configure-Nak message. If the AT has an IP address assigned, it shall include that address in the IP Address Option of the IPCP Configure-Request message. If the PDSN replies with an IPCP Configure-Nak in response to the request in order to propose a different IP address, the AT shall accept the new address, and shall send an IPCP Configure-Request to the PDSN with the new IP address.

IPv6 Address Assignment: If the AT has not previously negotiated/selected an interface ID, the AT shall perform interface identifier negotiation as described in [21]. The AT shall send IPv6CP Configure-Request message to the PDSN including Interface-Identifier Configuration Option with all zeros. The AT shall accept the interface ID received in IPv6CP Configure-Nak message. If the AT previously negotiated/selected an interface ID and wants to continue using it, the AT shall send IPv6CP Configure-Request message to the PDSN including Interface-Identifier Configuration Option with negotiated/selected interface ID. If the PDSN replies with an IPv6CP Configure-Nak in response to the request in order to propose a different interface ID, the AT shall accept the new interface ID.


AGW requirements are specified in [22]. Additional AGW requirements are specified here.

8.1.2.1 Authentication and Authorization Support for UMB-HRPD Interworking

8.1.2.2 Context Transfer Protocol

If the AGW is configured to support context transfer protocol, the AGW shall follow the procedures specified in [7]. User data between PDSN and AGW shall be tunneled using GRE transport as specified in [23] and [24]. If the PDSN and AGW only support IPv4 transport, they shall follow the transport format specified in [25], and the HI/HAck message format and option parameters specified in [7].

If the AGW supports context transfer protocol, the AGW may send an Access Request message including the AGW IP address used for context transfer during the authentication procedure. Alternatively, based on the operator’s policy, the AAA may use the NAS-IP-Address for assigning the AGW IP address used for context transfer.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

22

23

24

25

28

29

32

33

34

35

38

39

40

41

42

43

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

8.1 Requirements for Handoff from UMB to HRPD 19 8 PMIP Based Approach

20

21 8.1.3 PDSN Requirements

26

27

30

31

36

37

44

Upon receiving HI message from the PDSN that includes MNID set to NAI or IMSI in MNID option field and GRE Key in Tunnel-ID option field, an AGW that supports context transfer protocol shall send HAck message and include AT’s IPv4 and/or IPv6 address and GRE key. The included GRE key shall be unique for node (e.g., PDSN) and MNID pair. If the AGW has more context for the MNID, it includes code = ‘more context available’ in HAck message. When the AGW completes transferring all context for the user, it includes code = ‘no more context available’ in HAck message.

If the AGW subsequently receives HI message from the PDSN that includes code = ‘transfer request’, the AGW shall respond with HAck message and start forwarding all data addressed to the AT’s IP address to the PDSN.

Alternatively, if the AGW subsequently receives HI message from the PDSN that includes code = ‘buffer request’, the AGW shall respond with HAck message and not forward any data addressed to the AT’s IP address to the PDSN until it receives HI message from the PDSN that includes code = ‘transfer request’. The AGW shall send HI message that includes code = ‘transfer complete’ to the PDSN when the AGW completes sending all the buffered data.

The PDSN may support PMIP4, PMIP6 as specified in [40] and this document, or context transfer protocol as specified in this section.

8.1.3.1 Authentication and Authorization Support for UMB-HRPD Interworking

8.1.3.2 Addressing with IPCP

PDSN requirements for IPv4 addressing with IPCP are specified in [40] with the additions specified in this section.

8.1.3.2.1 IPv4 Addressing

If the PDSN receives an IPCP Configure-Request message containing non-zero IP Address Option from the AT that is authorized for PMIP based mobility, and according to Section 8.1.3.4.1 PMIP signaling is not triggered, the PDSN shall acknowledge the requested IP address.

8.1.3.3 Context Transfer Protocol

If the PDSN is configured to support context transfer protocol, the PDSN shall follow the procedures specified in [7]. User data between PDSN and AGW shall be tunneled using GRE transport as specified in [23] and [24]. If the PDSN and AGW only support IPv4 transport, they shall follow the transport format specified in [25], and the HI/HAck message format and option parameters specified in [7].

If the PDSN receives RADIUS Access Accept message that contains AGW IP address in the AGW IP address 3GPP2 VSA field [26], and if PDSN previously received A11 Registration Request message containing tunnel operation indicator, the PDSN shall send a HI message to the AGW and include MNID. The PDSN shall also include a GRE key in Tunnel-ID option field. The included GRE key shall be unique for node (e.g., AGW) and MNID pair. If the PDSN receives HAck message that includes code = ‘more context available’, it shall send

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

8 PMIP Based Approach 20 8.1 Requirements for Handoff from UMB to HRPD

another HI message to obtain more context for the user. If the PDSN receives HAck message that includes code = ‘no more context available’, it shall not request context transfer for the user. If the PDSN receives RADIUS Access Accept message that does not contain AGW address, the PDSN shall not trigger context transfer protocol.

If the PDSN receives A10 Xoff message and if the PDSN previously received HAck message from the AGW as a response to the HI message, the PDSN shall send HI message to the AGW to indicate that it is either ready to receive data by including code = ‘transfer request’ or to request the AGW to buffer data by including code = ‘buffer request’. If the PDSN receives HI message that includes code = ‘transfer complete’ from the AGW, it shall responds with HAck message and get ready to transfer the data.

If the PDSN receives A11 Registration Request message containing Airlink Record indicating Active Start, and if the PDSN previously sent HI message to the AGW requesting the AGW to buffer the data, the PDSN shall send HI message to the AGW indicating that it is ready to receive data by including code = ‘transfer request’ in the HAck message.

8.1.3.4 PMIP Support

8.1.3.4.1 PMIP Triggers

PDSN supporting PMIP based mobility for Simple IP mobiles shall trigger PMIP procedures as specified in this section.

The PDSN shall trigger PMIP procedures as follows:

1. Initial access – Upon receiving IPCP Configuration Request from an AT, the PDSN shall trigger PMIP procedures if the PDSN supports PMIP, the AT is authorized for PMIP based mobility and the PDSN has not previously received A11 Registration Request message containing tunnel operation indicator for this AT.

2. Handoff with context transfer – Upon receiving A11 Registration Request message containing Airlink Record indicating Active Start, the PDSN shall trigger PMIP procedures if the PDSN supports PMIP, the AT is authorized for PMIP based mobility, the PDSN previously received A11 Registration Request message containing tunnel operation indicator, and the PDSN performed context transfer procedures as specified in Sections 8.1.2.2 and 8.1.3.3.

3. Handoff without context transfer – Upon receiving A10 Xoff message, the PDSN shall trigger PMIP procedures if the PDSN supports PMIP, the AT is authorized for PMIP based mobility, the PDSN previously received A11 Registration Request message containing tunnel operation indicator, and the PDSN did not perform context transfer procedures specified in Sections 8.1.2.2 and 8.1.3.3..

8.1.3.4.2 PMIP4 Tunnel Management

The PDSN supporting Simple IP ATs with PMIP4 shall act as a Proxy Mobility Agent (PMA) as specified in [40].

X.S0054-610-0 v1.0

2

3

4

5

8

9

12

13

14

17

18

19

20

21

22

23

24

25

26

27

28

29

30

33

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

8.2 Requirements for Handoff from HRPD to UMB 21 8 PMIP Based Approach

1 8.1.3.4

6

7

10

11

15

16

31

32

34

35

.3 PMIP6 Tunnel Management

The PDSN supporting Simple IP ATs with PMIP6 shall act as a Mobile Access Gateway (MAG) as specified in [40].


The HA supporting PMIP4 shall follow [40].

8.1.5 LMA Requirements

The LMA supporting PMIP6 shall act as a Local Mobility Anchor as specified in [40].


Requirements for AAA are specified in [6], [22] and [40].

If the HAAA determines the CAN Access session has not been terminated since the session is continued with the PDSN, the HAAA shall return the same HA/LMA address to the PDSN in the AAA messages specified during PPP authentication phase. For the case of PMIP4, the HAAA shall generate a new PMN-HA key and PMN-HA-SPI using the PDSN IP address and the previous HA IP address. The HAAA shall return the new values of PMN-HA key and associated PMN-HA-SPI to the PDSN during PPP authentication phase. HAAA may also return source AGW IP address if the context transfer protocol is supported in the AGW and the PDSN. HAAA may decide whether the AGW and the PDSN support context transfer protocol based on the NAS-IP-Address in the AAA message.

8.2 Requirements for Handoff from HRPD to UMB


Upon obtaining IP addresses of the UMB eBS or UMB RAN-Lite (see section 4) and the IWSG, and establishing IP tunnel with the IWSG (see section 5), the AT performs the UMB session establishment [39] and the access authentication as specified in [6] through IP tunnel. Then, LinkID and DAP assignments are performed as specified in [20].

After above processes successfully completes, and the AT or AN decides to handoff to UMB, an eBS is added to the Route Set and the Key Exchange is performed [20]. Then, the AT shall trigger IP address or .IPv6 address assignment procedure as required in [22]

After the AT tunes to the UMB system, the AT completes IP address or IPv6 address assignment procedure as specified in [22]. Then, AT may send and receive data in the UMB system.

For other procedures, the AT shall follow the requirements in [8] and [22].

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9 Call Flows 22 9.1 ISF Discovery

9 Call Flows

9.1 ISF Discovery Figure 5 illustrates an example call flow for discovery of ISF. Two alternatives are shown in the figure. One uses DNS Query and another one uses DHCP Vendor Specific Information.

Figure 5 ISF Discovery

Alternative 1:

1. The AT sends a DNS query to the DNS Server including FQDN as specified in section y.

2. The DNS server responds with a DNS answer including a ISF’s IP address.

X.S0054-610-0 v1.0

2

3

4

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9.2 Handoff Session Pre-setup overview call flow through L3 tunneling 23 9 Call Flows

1 9.2 Handoff Session Pre-setup overview call flow through L3 tunneling

9.2.1 UMB to HRPD Handoff

Figure 6 illustrates a call flow for handoff preparation overview from UMB to HRPD through L3 tunneling. HRPD RAN/RAN-Lite IP address is provided over the IPSec tunnel with ISF after IPsec tunnel is established between the AT and the ISF. All HRPD signaling packets during the pre-registration phase in the UMB-HRPD interworking is exchanged over the IP tunnel.

5

6

ATHRPD

RAN/RAN-LitePMIP

HA/LMA AAAPDSNISFUMB eBS

SRNC DNSAGWLocalDHCP

1. AT decides to start Handoff Preparation procedures .

3. IKEv2 Negotiation(INTERNAL_IP4/IPv6_DNS, Tunnel Inner Address)

AAA authentication

4. DNS query

5. DNS answer (RAN/RAN-Lite address)

6. HRPD Air/IOS signalingA11

signaling

7. PPP negotiation

2. ISF IP Address Discovery

Figure 6 UMB-HRPD handoff Session Pre-setup overview call flow

The steps in Figure 6 are described below.

1. The AT decides to perform handoff pre-setup procedures with the PDSN in order to prepare for the handoff from the UMB system to HRPD system.

2. The AT performs ISF IP address discovery (see Figure 5 ).

3. The AT performs IPsec tunnel establishment with ISF (see Figure 9 ). If a private IP address is assigned to the AT and if the HRPD ISF uses global IP address, the AGW shall support the NAT function. The NAT function in this case shall bind the global IP address to the RAN-PMIP tunnel.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9 Call Flows 24 9.2 Handoff Session Pre-setup overview call flow through L3 tunneling

4. The AT sends a DNS query to the internal DNS server received from the ISF during the IKEv2 negotiation over the IPSec tunnel.

5. The DNS server responds with a DNS answer including a RAN/RAN-Lite address.

6. The AT and the RAN/RAN-Lite exchange Air/IOS signaling packets over the IPSec tunnel. A11 signaling messages are also exchanged during this step. If the ISF and HRPD RAN/RAN-Lite are consolidated, the device authentication such as A12 authentication may be omitted.

7. The AT and the PDSN perform PPP negotiation. After the completion of the PPP negotiation, the pre-registration phase is done.

9.2.2 HRPD to UMB Handoff

Figure 7 illustrates a call flow for handoff preparation overview from HRPD to UMB through L3 tunneling. UMB RAN/RAN-Lite IP address is provided over the IPSec tunnel with ISF after IPsec tunnel is established between the AT and the ISF. All UMB signaling packets during the pre-registration phase in the HRPD-UMB interworking is exchanged over the IP tunnel.

AT UMBRAN/RAN-Lite

PMIPHA/LMA

AAAAGWISFUMB eBS

SRNCDNSPDSNLocalDHCP

1. AT decides to start Handoff Preparation procedures .

3. IKEv2 Negotiation(INTERNAL_IP4/IPv6_DNS,

Tunnel Inner Address)AAA authentication

4. DNS query

5. DNS answer (RAN/RAN-Lite address)

2. ISF IP Address Discovery

6. UMB Air session setup and authenticationUMB Air session setup

and authenticationAAA authentication AAA authentication

Figure 7 HRPD-UMB handoff Session Pre-setup overview call flow


X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9.3 IPsec Tunnel Establishment 25 9 Call Flows

20

21

22 9.3 IPsec Tunnel Establishment

1. The AT decides to perform handoff pre-setup procedures with the AGW in order to prepare for the handoff from the HRPD system to UMB system.

2. The AT performs ISF IP address discovery.

3. The AT performs IPsec tunnel establishment with ISF. If a private IP address is assigned to the AT and if the ISF uses global IP address, the PDSN shall support the NAT function. The NAT function in this case shall bind the global IP address to the A10 tunnel.

4. The AT sends a DNS query to the internal DNS server received from the ISF during the IKEv2 negotiation over the IPSec tunnel.

5. The DNS server responds with a DNS answer including a UMB RAN/RAN-Lite address.

6. The AT, the UMB RAN/RAN-Lite, SRNC, AGW and AAA perform UMB Air session setup procedure and authentication. AAA used for UMB authentication may be different from the one for IKE authentication.

Figure 8 illustrates an example call flow for Simple IPv6 address assignment.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9 Call Flows 26 9.3 IPsec Tunnel Establishment

AT ISF H- AAASource System

17. IPsec tunnel

14. IKE_AUTH Response [CP(CFG_REPLY, EAP (EAP-Success)]

15. IKE_AUTH Request [CP(CFG_REQUEST), AUTH]

16. IKE_AUTH Response [CP(CFG_REPLY), AUTH, TIA, SAs, TS)

3. IKE_SA_INIT Exchange

4. IKE_AUTH Request [CP (CFG_REQUEST), IDi, IDr, SAs, Traffic Selectors] 5. RADIUS Access-Request

orDiameter EAP-Request [EAP Response Identity]

7. RADIUS Access-Challenge or

Diameter EAP-Answer [EAP-Request/AKA-Challenge

(RABD, AUTN, and AT_MAC)]

10. RADIUS Access-Request orDiameter EAP-Request [EAP-

Response (AT_RES and AT_MAC)]

12. RADIUS Access-Accept or

Diameter EAP-Answer [EAP Success (MSK)]

8. IKE_AUTH Response [CP (CFG_REPLY), EAP (EAP-Request/AKA-Challenge]

9. IKE_AUTH Request [CP(CFG_REQUEST), EAP(EAP-Response/AKA-Challenge (AT_RES, AT_MAC)]

DNS

1. AT starts from the source system and obtains IP address and domain name

2. AT performs DNS query to obtain the ISF’s IP address

6. Generate AUTN, RAND, XRES

13. AUTH computed from

MSK

11. Verify RES= XRES and

generate MSK

Figure 8


1. The AT communicates with the source Access IP network (UMB network or

2. The AT performs ISF discovery. If DNS is used, the MS selects one ISF IP address

Tunnel establishment flow

HRPD/1x network). In source network, the AT acquires Local Domain Name and an IP address during IP address assignments. It also discovers the DNS server IP address(es).

from the DNS response.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9.3 IPsec Tunnel Establishment 27 9 Call Flows

3. The AT initiates the IKEv2 exchange with the ISF. The first set of messages is the IKE_SA_INIT exchange. The AT and ISF support NAT Traversal as outlined in Section 2.23 of [11], which implies that both the initiator and responder include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the first round of messages and support the negotiation of UDP encapsulation.

4. The AT initiates the IKE_AUTH exchange with the ISF. These messages are encrypted and integrity protected with the keys established through the IKE_SA_INIT exchange. The AT requests a tunnel inner IP address (TIA), by setting the CONFIGURATION payload (CFG_REQ attribute value set to INTERNAL_IP4_ADDRESS or INTERNAL_IP6_SUBNET depending on the IP version the AT supports) in the IKE_AUTH request. The AT includes its NAI in the IDi payload. The AT does not include the AUTH payload in the IKE_AUTH message to indicate it wants to use EAP.

5. When the ISF receives the IKE_AUTH request without the AUTH payload it contacts the H-AAA to request service authorization and user authentication information by sending the EAP-Response/Identity message in the RADIUS Access-Request message [35], or Diameter-EAP-Request (DER) Command [36].

6. Based upon NAI, an AKA long term credentials (agreed to beforehand by the user’s identity module and the Home AAA) and a sequence number, the Home AAA runs the AKA algorithms and generates an authentication vector comprising a random part RAND, an authenticator part AUTN used for authenticating the network to the user identity module, an expected result part XRES, a 128-bit session key for the integrity check IK, and a 128-bit session key for encryption CK. See [RFC] for details.

7. The Home AAA sends an AAA Message (RADIUS Access-Challenge or Diameter-EAP-Answer) to the ISF containing EAP message or EAP-Payload which encapsulates the EAP-Request/AKA-Challenge message. The AKA-Challenge subtype contains the AT_RAND and AT_AUTN attributes which in turn contain the RAND and AUTN, respectively, generated by the Home AAA. The AKA-Challenge subtype also contains the AT_MAC attribute which provides message integrity protection.

8. The ISF sends the IKE_AUTH Response message including the CP Payload (CFG_REPLY) and EAP Payload (EAP Request/AKA-Challenge) to the AT.

9. The AT verifies the authentication parameters in the EAP-Request/AKA-Challenge message and if the verification is successful, it responds to the challenge with an IKE_AUTH Request message to the ISF. The main payload of this message is the EAP-Response/AKA-Challenge message. If the verification is not successful, the MS re-initiates the IKEV2 AUTH or aborts the IKEv2 exchange.

10. The ISF forwards the EAP–Response/AKA-Challenge message to the H-AAA via either RADIUS Access-Request message or Diameter DER command.

11. The Home AAA verifies that RES = XRES (where XRES was generated by the Home AAA in Step 6). The Home AAA also generates the MSK using IK and CK (where IK and CK were generated by the Home AAA.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9 Call Flows 28 9.4 CMIP Based Approach Call Flow

12. Upon successful authentication the H-AAA sends a RADIUS Access-Accept message with EAP-Message attribute containing EAP Success when the RADIUS protocol is used or a Diameter–EAP-Answer command with a Result-Code AVP indicating success when Diameter is used. The H-AAA sends to the ISF the EAP Success and the MSK generated during the EAP-AKA authentication process [37]. In the case of RADIUS, as per EAP AKA [37], the 64-byte MSK is split into two 32-byte parts with the first 32-bytes sent in the MS-MPPE-REC-KEY [33] and the reaming 32-bytes sent in the MS-MPEE-SEND-KEY [33]. Both of these attributes are needed to construct the 64-byte MSK at the ISF. If any of those are missing, the ISF rejects the session. In the case of Diameter, the entire MSK 64-byte key is transmitted in the EAP-Master-Session-Key AVP.

13. The ISF calculates AUTH payload from the MSK.

14. Upon reception of a RADIUS Access-Accept message or a Diameter-EAP-Answer (DEA) Command with a Result-Code AVP indicating success, the ISF sends an IKE_AUTH response message including the EAP Success. If the OWSG receives a RADIUS Access-Reject message or a Diameter-EAP-Answer (DEA) Command with a Result-Code AVP indicating failure, the ISF rejects the tunnel establishment towards the AT by sending an IKE_AUTH response message with the Notify payload set to ‘AUTHENTICATION FAILED’.

15. The AT sends the IKE_AUTH request message including the AUTH payload calculated from the MSK which is generated upon successful EAP authentication.

16. The ISF uses the MSK to check the correctness of the AUTH payload received from the AT and calculates its own AUTH payload for the AT to verify [11]. The ISF sends the AUTH payload to the AT together with an assigned TIA, the configuration payload containing security associations and the rest of the IKEv2 parameters in the IKE_AUTH Response message, and the IKEv2 negotiation terminates.

17. When the IKE_AUTH exchange completes, an IPsec tunnel is established between the AT and the ISF. The AT and ISF also support UDP encapsulation of IPsec ESP packets [12] for the case when a NAT is detected in step 3.

9.4 CMIP Based Approach Call Flow

9.4.1 CMIP Based Approach Active Handoff from UMB to the HRPD AN

Figure 9 illustrates an example call flow to show CMIP based approach for UMB-HRPD handoff. In this call flow, CMIP is used in both UMB network and HRPD network. There are no changes needed for HRPD PDSN as specified in [8] in this call flow.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9.4 CMIP Based Approach Call Flow 29 9 Call Flows

ATUMB eBS/

SRNC

HRPD AN HAPDSN

27. Data 27. Data 27. Data


AGW

21. AT tunes to HRPDand completes HRPD connection setup

19. Connection Close

CSCF AAADNS

Server

1. AT starts from UMB (AT obtains Domain Name through DHCP and HoA is assigned to the AT)

3. HRPD AN Advertised

7. A11 RRQ (Conn AR, Tunnel Operation Indicator)

8. A11 RRP

23. HRPD Accounting Start

12. AT or eBS decides to handoff to HRPD

15. MIP RRQ (HA IP address, CoA, HoA)

17. MIP RRQ

18. MIP RRP

9. PPP Establishment between AT and PDSN

16. Authentication

29. CAN Accounting Stop

28. UMB RAN PMIP Tunnel is released

10. FA Advertisement

20. Accounting Stop

26. MIP RRP

5. HRPD Session Establishment

6. HRPD AN PPP Establishment

11. TFT Establishment between AT and PDSN

13. HRPD Traffic Channel Assignment14. Xoff

25. Xon

Data Data Data

Data Data Data

Data

22. A11 RRQ (Active Start)

24. A11 RRP

ISF

4. UMB-HRPD Handoff Session Pre-setup (See steps 1 to 5 in Section 10.2.1)

Figure 9 CMIP Based Approach UMB-HRPD Handoff


1. The AT communicates with UMB network. In UMB network, the AT acquires Domain Name and CMIP HoA during IP address assignments.

2. Data is being sent between AT and HA through AGW.

3. AT detects the edge of UMB network by finding a HRPD channel through the UMB over-the-air overhead message. The AT obtains the SectorID of the neighboring HRPD AN.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


4. The AT and network perform handoff session Pre-Setup steps 1 to 5 as specified in the call flow in. Section 9.2.1.

5. The AT establish the HRPD session with HRPD AN through the IP tunnel (see [19]).

6. The AT establish PPP with HRPD AN through the IP tunnel (see [19]).

7. The AN recognizes that no A10 connection associated with the AT is available and selects a PDSN. The AN sends an A11-Registration Request message to the PDSN with the tunnel operation indicator.

8. Once the A11-Registration Request message is validated, the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The A10 connection binding information at the PDSN is updated to point to the AN.

9. The AT performs PPP connection establishment procedure with the PSDN indicates it is MIP session (see [8]).

10. The PDSN sends FA Advertisement to the AT including FA CoA.

11. The AT establishes the TFT with the PDSN if needed.

At this point, the AT has successfully pre-established HRPD and PPP sessions. The following steps may occur at anytime later. The decision of when the handoff occurs may be made by either the eBS or the AT.

12. The AT or the eBS decides to handoff to the HRPD.

13. The AT performs HRPD connection setup and traffic channel assignment procedures with the HRPD AN through IP tunnel (See [19]).

14. The AN performs flow control with the PDSN through A10 Xoff to indicate that the PDSN should buffer the data.

15. After traffic channel assignment procedure is complete, the AT may tunnel a Mobile IP Registration Request to the HRPD AN. The AT does not wait for a Registration Response message before proceeding with the remaining of the call flow.

16. Triggered by MIP RRQ, the PDSN performs authentication with AAA as specified in [8].

17. The PDSN forwards the MIP RRQ to the AT’s Mobile IP home agent to update the AT’s binding record.

18. Upon receipt of the request from the PSDN, the AT’s MIP home agent updates its binding record for the AT, and confirms with the PDSN by replying a MIP Registration Reply message.

19. After step 16, the AT sends a ConnectionClose message to the eBS which is the FLSE with a flag set indicating the AT is tuning to other air-interface. Upon receiving the message, the eBS issues IOS messages with a connection close indication to all eBSs in the route set (See [19]).

20. The eBSs in the route set sends Accounting Stop to the AGW (see [38]).

21. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and complete HRPD connection setup (See [19]).

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


22

23 9.4.2 CMIP Based Approach Active Handoff from UMB to HRPD through HRPD AN-Lite

22. The AN sends an A11-Registration Request message to the PDSN with Active Start indication.

23. The PDSN sends Accounting Start to the HAAA including AT’s NAI, IP Address, IMSI.

24. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication.

25. The AN sends A10 Xon to the PDSN.

26. The PDSN forwards MIP RRQ to the AN and the AN forwards MIP RRQ to the AT.

27. Data is being sent between AT and HA through PDSN and AN

28. Sometimes later, the RAN PMIP primary tunnel between eBS and AGW is released either triggered by lifetime expiration or receiving PMIP RRQ with lifetime set to “0”.

29. The AGW sends Accounting Stop to the AAA (see [38]).

Figure 10 illustrates an example call flow to show CMIP based approach for UMB-HRPD handoff. In this call flow, CMIP is used in both UMB network and HRPD network. There are no changes needed for HRPD PDSN in this call flow.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


Figure 10 CMIP Based Approach UMB-HRPD Handoff




X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


4. The AT and network perform handoff session Pre-Setup steps 1 to 5 as specified in the call flow in Section 9.2.1.

5. The AT establish the HRPD session with HRPD AN-Lite through the IP tunnel (see [19]).

6. The AT establish PPP with HRPD AN-Lite through the IP tunnel (see [19]).

7. The AN-Lite sends an A11-Registration Request message to the PDSN with the tunnel operation indicator.

8. Once the A11-Registration Request message is validated, the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The A10 connection binding information at the PDSN is updated to point to the AN-Lite.






13. The AT performs HRPD connection setup and traffic channel assignment procedures with the HRPD AN-Lite through IP tunnel but it gets a reject code indicating the network is not capable of assigning traffic channel (see [19]).

14. The AN-lite performs flow control with the PDSN through A10 Xoff to indicate that the PDSN should buffer the data.

15. The AT may tunnel a Mobile IP Registration Request to the HRPD AN. The AT does not wait for a Registration Response message before proceeding with the remaining of the call flow.

16. Triggered by MIP RRQ, the PDSN performs authentication with AAA as specified in [8].

17. The PDSN forwards the MIP RRQ to the AT’s Mobile IP home agent to update the AT’s binding record.

18. Upon receipt of the request from the PSDN, the AT’s MIP home agent updates its binding record for the AT, and confirms with the PDSN by replying a MIP Registration Reply message. The PDSN buffers the packet for the AT.

19. After step 16, the AT sends a ConnectionClose message to the eBS which is the FLSE with a flag set indicating the AT is tuning to other air-interface. Upon receiving the message, the eBS issues IOS messages with a connection close indication to all eBSs in the route set (See [19]).


21. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and performs HRPD connection setup and traffic channel

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


assignment procedures. During this step, the HRPD AN fetches the AT’s HRPD session from the HRPD AN-Lite through A13 interface. See [19].

22. The AN sends an A11-Registration Request message to the PDSN. The A11-Registration Request message includes the Mobility Event Indicator (MEI).

23. The PDSN sends Accounting Start to the AAA including AT’s NAI, IP Address, IMSI.

24. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication.

25. The PDSN forwards MIP RRP to the AT through the AN. After this step, data flows between AT and HA through the PDSN and AN.

26. The PDSN initiates closure of the A10 connection with the AN-lite by sending an A11-Registration Update message.

27. The AN-lite responds with an A11-Registration Acknowledge message.

28. The AN -lite sends an A11-Registration Request message, with Lifetime set to zero, to the PDSN.

29. The PDSN sends an A11-Registration Reply message to the AN-lite. The AN -lite closes the A10 connection for the AT.



9.4.3 CMIP Based Approach Active Handoff from HRPD to UMB through UMB AN-Lite/eBS

Figure 11 illustrates an example call flow to show CMIP based approach for HRPD-UMB handoff. In this call flow, CMIP is used in both HRPD network and UMB network. There are no changes needed for HRPD PDSN in this call flow.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


Figure 11 CMIP Based Approach HRPD-UMB Handoff

1. The AT communicates with HRPD network. In HRPD network, the AT acquires Domain Name and CMIP HoA during IP address assignments.

2. Data is being sent between AT and HA through PDSN.

3. The AT detects existence of the UMB network by finding an advertised UMB pilot in the HRPD AN air interface overhead message. Alternatively, the AT can also periodically search for UMB pilots. The AT obtains the ANID of the UMB RAN-Lite/eBS.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


4. The AT and network perform handoff session Pre-Setup steps 1 to 5 as specified in the call flow in Section 9.2.1.

5. The AT performs UMB session establishment with the UMB RAN-Lite/eBS and authentication with the SRNC if the UMB session does not exist or cannot be retrieved by the UMB RAN-Lite/eBS. Otherwise, the UMB RAN-Lite/eBS retrieves the UMB session from the SRNC. The UMB RAN-Lite/eBS also becomes the FLSE for the AT and sends IPT-Notification (FLSE) message to the SRNC. Refer to [39] for details of the UMB session establishment.

6. UMB RAN-Lite/eBS assigns a LinkID for the AT so that the AT can start IP services on UMB.

7. Upon assignment of the LinkID, if the AT is configured to use AT-assisted DAP handoff, the AT sends a DAPMoveRequest message to the UMB RAN-Lite/eBS to trigger initial PMIP tunnel setup with the AGW. If the AT-assisted DAP handoff is not configured, UMB RAN-Lite/eBS autonomously continues the following step.

8. The UMB RAN-Lite/eBS sends a PMIP-Registration Request message to the AGW to initiate PMIP tunnel setup.

9. The AGW sends a PMIP Registration Reply message to complete PMIP tunnel setup with UMB RAN-Lite/eBS, which is now the DAP for the AT.

10. The UIF sends a DAPAssignment message to the AT.

11. The UMB RAN-Lite/eBS sends an IOS message to the SRNC to indicate it is the current DAP. (See [39])

12. The AT sends FA Solicitation message to the AGW.

13. The AGW sends FA Advertisement to the AT including FA CoA.

At this point, the AT has successfully pre-established UMB sessions. The following steps may occur at anytime later. The decision of when the handoff occurs may be made by either the network or the AT.

14. Either the AT or the UMB RAN-Lite/eBS decides that it is preferable to handoff to UMB.

15. If the UMB RAN-Lite/eBS decides handoff, the UMB RAN-Lite/eBS sends RouteCreate message to trigger the AT to create a route to eBS1. If the AT decides handoff, the AT sends a RouteOpenRequest message to the eBS1, via the tunnel through UMB RAN-Lite/eBS.

16. The AT may tunnel a Mobile IP Registration Request to the UMB RAN-Lite/eBS. The AT does not wait for a Registration Response message before proceeding with the remaining of the call flow.

17. The AGW forwards the MIP RRQ to the AT’s Mobile IP home agent to update the AT’s binding record.

18. Upon receipt of the request from the AGW, the AT’s MIP home agent updates its binding record for the AT, and confirms with the AGW by replying a MIP Registration Reply message.

19. The AGW forwards the MIP RRP to the UMB RAN-Lite/eBS.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

32

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9.5 CMIP/PMIP Based Approach Call flow 37 9 Call Flows

30

31 9.5 CMIP/PMIP Based Approach Call flow

33

34

20. After step 17, the AT sends a Connection Release message to the HRPD RAN.

21. The HRPD RAN sends A11 signaling message to the PDSN (see [19]).

22. The AT tunes its radio to UMB network and selects the eBS1 as its new FLSE and eBS1 sends IPT notifications to Route Set members. See [39].

23. The UMB RAN-Lite/eBS sends the buffered MIP Registration Reply and other data to the FLSE, which is the eBS1. The FLSE then forwards them to the AT.

24. If the AT is configured to use AT-assisted DAP handoff, the AT sends a DAPMoveRequest message to eBS1 to trigger PMIP tunnel setup with the AGW. If the AT-assisted DAP handoff is not configured, eBS1 autonomously continues the following step. This step may occur any time after step 22.

25. The eBS1 updates the PMIP binding with the AGW by sending a PMIP-Registration Request message to the AGW.

26. The AGW confirms the binding update by sending back a PMIP-Registration Reply message to the eBS1.

27. The eBS1 sends a DAPAssignment message to the AT.

28. The eBS1 sends IPT-Notification message to the all eBS in Route Set (SRNC and UMB RAN-Lite/eBS) with the indication it is the new DAP. See [39].

9.5.1 CMIP/PMIP Based Approach Active Handoff through HRPD AN-Lite

Figure 12 illustrates an example call flow to show CMIP/PMIP based approach for UMB-HRPD handoff. In this call flow, PMIP is used in HRPD system and CMIP is used in UMB system. In this scenario, HRPD AN-lite will be deployed.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9 Call Flows 38 9.5 CMIP/PMIP Based Approach Call flow

AT UMB eBSHRPD AN-

Lite PDSN

Data Data Data


AGW(FA)

4. AT decides to establish DO session


AAADNS Server


5. DNS Query (AT obtains HRPD AN-Lite’s IP Address

8. A11 RRQ (SO59, Conn AR, Tunnel Operation Indicator)

9. A11 RRP

18. Accounting Start (NAI, IMSI, IP Address, SO59)


10. LCP/CHAP/PAP through IP Tunnel between AT and HRPD AN-Lite 10. Authentication (Access Request/Access accept)

29. Accounting Stop

28. RAN PMIP is released

HA


11. IPCP Through IP Tunnel between AT and HRPD AN-Lite

21. AT tunes to HRPDand performs HRPD connection setup and TCA

And Reservation ON

HRPD AN

16. PMIP RRQ

17. PMIP RRP (HoA)


23. A11 RRP

24. A11 RU

25. A11 RA

26. A11 RRQ (Lifetime=0)

27. A11 RRP

15. A10: Xoff

1. AT starts from UMB (Domain Name and DNS server are sent to the AT through DHCP). AT acquires CMIP HoA from HA in UMB network.

14. AT attempts connection setup but it gets rejected

20. Accounting Stop



Figure 12 CMIP/PMIP Based Approach UMB to HRPD Handoff (with HRPD AN-Lite)



X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60



4. The AT decides to establish HRPD session.

5. The AT acquires FQDN of the selected AN and issues a DNS query to resolve the IP address of the HRPD AN. Upon receipt of the request, the DNS server looks up the IP address of the HRPD AN and sends it back to the AT. This call flow assumes that the returned IP address is the IP address of the AN-Lite.

6. The AT establish the HRPD session with HRPD AN-Lite through the IP tunnel (see [19]).

7. The AT establish PPP with HRPD AN-Lite through the IP tunnel (see [19]).

8. The AN-Lite sends an A11-Registration Request message to the PDSN.

9. Once the A11-Registration Request message is validated, the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The A10 connection binding information at the PDSN is updated to point to the AN-Lite.

10. The AT performs PPP LCP/CHAP/PAP procedure with the PSDN (see [8]).

11. The AT performs IPCP with the PDSN indicates IP address (HoA).




14. The AT performs HRPD connection setup and traffic channel assignment procedures with the HRPD AN-Lite through IP tunnel but it gets a reject code indicating the network is not capable of assigning traffic channel (see [19]).

15. The AN-lite performs flow control with the PDSN through A10 Xoff to indicate that the PDSN should buffer the data.

16. The PDSN sends PMIP RRQ to the HA.

17. The HA sends PMIP RRP with AT’s HoA back to the PDSN.

18. The PDSN sends HRPD Accounting Start to the AAA.

19. The AT sends a ConnectionClose message to the eBS which is the FLSE with a flag set indicating the AT is tuning to other air-interface. Upon receiving the message, the eBS issues IOS messages with a connection close indication to all eBSs in the route set (See [19]).


21. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and performs HRPD connection setup and traffic channel assignment procedures. During this step, the HRPD AN fetches the AT’s HRPD session from the HRPD AN-Lite through A13 interface. See [19].

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


22. The AN sends an A11-Registration Request message to the PDSN with Active Start indication.

23. The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. After this step, the data flows between AT and HA through the PDSN and AN.

24. The PDSN initiates closure of the A10 connection with the AN-lite by sending an A11-Registration Update message.

25. The AN-lite responds with an A11-Registration Acknowledge message.

26. The AN-lite sends an A11-Registration Request message, with Lifetime set to zero, to the PDSN.

27. The PDSN sends an A11-Registration Reply message to the AN-lite. The AN -lite closes the A10 connection for the AT.



9.5.2 CMIP/PMIP Based Approach Active Handoff to HRPD AN

Figure 13 illustrates an example call flow to show CMIP/PMIP based approach for UMB-HRPD handoff. In this call flow, PMIP is used in HRPD system and CMIP is used in UMB system.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


AT UMB eBS HRPD AN PDSN

Data Data Data


AGW(FA)

21. AT tunes to HRPDand completes HRPD connection setup

4. AT decides to establish DO session


CSCF

14. HRPD Traffic Channel Assignment

AAADNS

Server

1. AT starts from UMB (Domain Name and DNS server are sent to the AT through DHCP). AT acquires HoA from HA in UMB network.


5. DNS Query (AT obtains HRPD AN’s IP Address

8. A11 RRQ (Conn AR, Tunnel Operation Indicator)

9. A11 RRP

18. Accounting Start


10. LCP/CHAP/PAP 10. Authentication (Access Request/Access accept)

26. Accounting Stop


HA


11. IPCP

20. Accounting Stop



15. A10: Xoff


24. A11 RRP

22. A10: Xon

16. PMIP RRQ

17. PMIP RRP (HoA)

Figure 13 CMIP/PMIP Based Approach UMB to HRPD Handoff to HRPD AN





5. The AT acquires FQDN of the selected AN and issues a DNS query to resolve the IP address of the HRPD AN. Upon receipt of the request, the DNS server looks up the IP address of the HRPD AN and sends it back to the AT.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


6. The AT establish the HRPD session with HRPD AN through the IP tunnel (see [19]).

7. The AT establish PPP with HRPD AN through the IP tunnel (see [19]).

8. The AN recognizes that no A10 connection associated with the AT is available and selects a PDSN. The AN sends an A11-Registration Request message to the PDSN.

9. Once the A11-Registration Request message is validated, the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The A10 connection binding information at the PDSN is updated to point to the AN.






14. The AT performs HRPD connection setup and traffic channel assignment procedures with the HRPD AN through IP tunnel (See [19]).

15. The AN performs flow control with the PDSN through A10 Xoff to indicate that the PDSN should buffer the data.

16. The PDSN sends PMIP RRQ to the HA.

17. The HA sends PMIP RRP with AT’s HoA back to the PDSN.

18. The PDSN sends HRPD Accounting Start to the AAA.

19. The AT sends a ConnectionClose message to the eBS which is the FLSE with a flag set indicating the AT is tuning to other air-interface. Upon receiving the message, the eBS issues IOS messages with a connection close indication to all eBSs in the route set (See [19]).


21. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and complete HRPD connection setup (See [19]).

22. The AN sends A10 Xon to the PDSN.

23. The AN sends A11 RRQ to the PDS with Active Start indication.

24. The PDSN reply with A11 RRP to the AN. Data is being sent between AT and HA through PDSN and AN.



X.S0054-610-0 v1.0

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


1 9.5.3 PMIP/CMIP Based Approach Active Handoff from HRPD to UMB through UMB RAN-Lite/eBS

Figure 14 illustrates an example call flow to show PMIP/CMIP based approach for HRPD-UMB handoff. In this call flow, PMIP is used in HRPD system and CMIP is used in UMB system.

Figure 14 PMIP/CMIP Based Approach HRPD to UMB Handoff

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


1. The AT communicates with HRPD network. In HRPD network, the AT acquires Domain Name and Simple IP address with PMIP during IP address assignments.


3. The AT detects existence of the UMB network by finding an advertised UMB pilot in the HRPD AN air interface overhead message. Alternatively, the AT can also periodically search for UMB pilots. The AT obtains the ANID of the UMB RAN-Lite/eBS.

4. The AT performs session Pre-Setup as specified in the call flow in section 9.2.

5. UMB RAN-lite/eBS assigns a LinkID for the AT so that the AT can start IP services on UMB.

6. Upon assignment of the LinkID, if the AT is configured to use AT-assisted DAP handoff, the AT sends a DAPMoveRequest message to the UMB RAN-lite/eBS to trigger initial PMIP tunnel setup with the AGW. If the AT-assisted DAP handoff is not configured, UMB RAN-lite/eBS autonomously continues the following step.

7. The UMB RAN-lite/eBS sends a PMIP-Registration Request message to the AGW to initiate PMIP tunnel setup.

8. The AGW sends a PMIP Registration Reply message to complete PMIP tunnel setup with UMB RAN-lite/eBS, which is now the DAP for the AT.

9. The UIF sends a DAPAssignment message to the AT.

10. The UMB RAN-lite/eBS sends an IOS message to the SRNC to indicate it is the current DAP. (See [39])

11. The AT sends FA Solicitation message to the AGW.

12. The AGW sends FA Advertisement to the AT including FA CoA.

At this point, the AT has successfully pre-established UMB sessions. The following steps may occur at anytime later. The decision of when the handoff occurs may be made by either the network or the AT.

13. Either the AT or the UMB RAN-lite/eBS decides that it is preferable to handoff to UMB.

14. If the UMB RAN-lite/eBS decides handoff, the UMB RAN-lite/eBS sends RouteCreate message to trigger the AT to create a route to eBS1. If the AT decides handoff, the AT sends a RouteOpenRequest message to the eBS1, via the tunnel through UMB RAN-lite/eBS.

15. The AT may tunnel a Mobile IP Registration Request to the UMB RAN-lite/eBS. The AT does not wait for a Registration Response message before proceeding with the remaining of the call flow.

16. The AGW forwards the MIP RRQ to the AT’s Mobile IP home agent to update the AT’s binding record.

17. The HA and HAAA exchanges AAA messages. The HA obtains MN-HA key from HAAA if needed. Note if CMIP NAI is different from PMIP NAI, the HAAA can indicate to the HA that they are associated with the same AT so that the HA can assign the same IP address to the AT.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

43

44

45

46

49

50

51

52

53

54

55

56

57

58

59

60

9.6 PMIP Based Approach Call flow 45 9 Call Flows

41

42 9.6 PMIP Based Approach Call flow

47

48

18. Upon receipt of the request from the AGW, the AT’s MIP home agent updates its binding record for the AT, and confirms with the AGW by replying a MIP Registration Reply message.

19. The AGW forwards the MIP RRP to the UMB RAN-lite/eBS.

20. After step 15, the AT sends a Connection Release message to the HRPD RAN.

21. The HRPD RAN and PDSN exchanges A11 signaling message (see [19]).

22. Triggered by PMIP binding (steps 18 and 20), the HA sends MIP Registration Revocation to the PDSN.

23. The PDSN clean up the PMIP state and sends MIP Revocation Ack to the HA.


25. The UMB RAN-lite/eBS sends the buffered MIP Registration Reply and other data to the FLSE, which is the eBS1. The FLSE then forwards them to the AT.





30. The eBS1 sends IPT-Notification message to the all eBS in Route Set (SRNC and UMB RAN-lite/eBS) with the indication it is the new DAP. See [39].

In this section, PMIP is used in both HRPD system and UMB system. If PMIP is used, one of the following three options may be used.

9.6.1 PMIP Based Call Flow for Active Handoff through HRPD RAN-Lite using AGW-PDSN Interface

Figure 15 illustrates an example call flow for PMIP based UMB to HRPD interworking through HRPD RAN-Lite using AGW-PDSN interface by buffering at PDSN. In the Figure 16 , AGW buffers data. If context transfer is not used, the interface between PDSN and AGW is not required.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

9 Call Flows 46 9.6 PMIP Based Approach Call flow

ATUMB eBS/

SRNCHRPD RAN/RAN-

LitePMIP

HA/LMA

41. Data Data

2. Data Data Data

AGW AAA

1. AT starts from UMB (AT acquires Simple IP address in UMB through PMIP.)



38. PRRQ or PBU (AT’s IPv4 address or IPv6 prefix)

40. PRRP or PBA (accept)

31. Accounting Stop


11. Access Request (NAI, IMSI, etc.)

12. Access Accept (HA/LMA IP address, AGW IP address)

24. A11 RRQ(AirlinkRecord=ConnectionSetup)

25. A11 RRP

7. A11 RRQ (MEI, AirlinkRecord=ConnectionSetup,

Tunnel Operation Indicator)

8. A11 RRP


9. PPP LCP phase

19. A10: Xoff




4. AT decides to establish HRPD session

10. PPP Authentication phase

15. PPP NCP phase/Router Advertisement

13. HI (MNID, GRE key)

14. HAck (AT’s IPv4 or IPv6

address, GRE key, QoS)

20. HI (code=transfer

request)

Data Data37. Data

PCRF

39. PCRF interaction

PDSN

18. Route Update/Connection Request

29. Accounting Stop28. Connection Close

27. Traffic Channel Assignment

33. A11 RRQ(AirlinkRecord=ActiveStart)

34. A11 RRP

22. Data Data

36. Buffered Data

23. IOS Signaling

32. AT tunes to HRPD and Traffic Channel Complete/IOS Signaling

26. IOS Signaling

21. HAck

Figure 15 PMIP based UMB to HRPD Interworking using AGW-PDSN Interface (PDSN buffering)

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60



1. The AT communicates with UMB network. In UMB network, the AT acquires the IP address through the PMIP based IP address assignment.

2. Data is being sent between AT and HA/LMA through AGW.

3. AT detects the edge of UMB network by finding a HRPD channel through the UMB over-the-air overhead message. The AT obtains the Sector-ID of the neighboring HRPD AN.


5. The AT establishes an HRPD session with HRPD RAN-Lite.

6. The AT establishes PPP session with HRPD RAN-Lite to authenticate the AT with A12 interface.

7. The RAN-Lite sends an A11-Registration Request message with AirlinkRecord=ConnectionSetup to the PDSN, including MEI (Mobility Event Indicator) and tunnel operation indicator.

8. Once the A11-Registration Request message is validated, the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The A10 connection binding information at the PDSN is updated to point to the RAN-Lite.

9. The AT performs PPP LCP phase with the PDSN.

10. The AT performs PPP authentication phase such as PAP and CHAP with the PDSN.

11. During step 10, the PDSN sends an Access Request message including NAI, IMSI, etc. to the AAA.

12. The AAA sends an Access Accept message to the PDSN including HA/LMA address which is the same as UMB network. AAA may also include the previous AGW’s IP address so that the PDSN can use the AGW-PDSN interface based on operator’s policy. If the Access Accept message does not have any AGW’s IP address, the PDSN follows “PMIP Based Call Flow for Active Handoff through HRPD RAN-Lite” procedure defined in section X-2.

13. The PDSN sends a HI message (see [7] in IPv6 case, and [25] in IPv4 case) including MNID to the AGW.

14. The AGW sends a HAck message including AT’s IPv4 or IPv6 address to the PDSN.

15. The AT and PDSN perform NCP negotiation. The PDSN assigns the AT’s IPv4 or IPv6 address received at step 14 through IPCP, IPv6CP and Router Advertisement procedure.




X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


18. The AT performs HRPD Route Update and Connection Setup procedures with the HRPD RAN-Lite. (see [19]).

19. This step is optional. The RAN-Lite may perform flow control with the PDSN through A10 Xoff to indicate that the PDSN buffers the data.

20. By triggering step 19, if the PDSN supports buffering mechanism, the PDSN sends a HI message (see [7]) with the transferring request as a confirmation to the AGW in order to indicate that the AGW can send data to the PDSN at this point. If the PDSN does not support buffering mechanism, the PDSN sends an unsolicited HAck message with the buffering request and follows the ”PMIP based UMB to HRPD Interworking using AGW-PDSN Interface (AGW buffering)” procedure.

21. AGW responds with a HAck message and starts transferring the packets from the HA/LMA to the PDSN.

22. Data flows from the HA/LMA to the PDSN through the AGW. The PDSN buffers the packets for the AT until it receives an A11-Registration Request message with AirlinkRecord=ActiveStart.

Step 23 through step 26 are optional (see [19]).

23. The HRPD RAN/RAN-Lite performs IOS session transfer. (see [19])

24. The target RAN sends an A11-Registration Request message with AirlinkRecord=ConnectionSetup to the PDSN.

25. The PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication.


27. The HRPD RAN-Lite sends a Traffic Channel Assignment message to the AT.

28. After step 16, the AT sends a ConnectionClose message to the eBS which is the FLSE with a flag set indicating the AT is tuning to other air-interface. Upon receiving the message, the eBS issues IOS messages with a connection close indication to all eBSes in the route set (See [19]).

29. The eBSes in the route set sends Accounting Stop to the AGW. (see [38])

30. The RAN PMIP tunnel between eBS and AGW is released either triggered by lifetime expiration or receiving a RAN PMIP Registration Request message with lifetime set to zero.

31. The AGW sends an Accounting Stop message to the AAA. (see [38])

32. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and performs HRPD Traffic Channel Complete and IOS procedure with the target RAN. (See [19])

33. The target RAN sends an A11-Registration Request message with AirlinkRecord=ActiveStart to the PDSN.


35. The PDSN sends an Accounting Start message to the AAA.

36. The PDSN sends buffered data to the AT.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


37. The AT sends/receives data via PDSN, AGW and HA/LMA.

38. The PDSN may send a PMIP Registration Request message or PMIP Binding Update message to the HA/LMA by triggering step 33. If the PDSN has not received A10 Xoff before this step, the PDSN shall send a PMIP Registration Request message or PMIP Binding Update message to the HA/LMA by triggering step 33.

39. The HA/LMA may interact with PCRF for policy control.

40. The HA/LMA responds with a PMIP Registration Reply message or PMIP Binding Acknowledgement message.

41. After step 40, data flows between the AT and HA/LMA through the PDSN.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


ATUMB eBS/

SRNCHRPD RAN/RAN-

LitePMIP

HA/LMA

45. Data Data

2. Data Data Data

AGW AAA






31. Accounting Stop30. RAN PMIP is released


12. Access Accept (HA/LMA IP address, AGW IP address)

24. A11 RRQ(AirlinkRecord=ConnectionSetup)

25. A11 RRP



8. A11 RRP


9. PPP LCP phase

19. A10: Xoff






15. PPP NCP phase/Router Advertisement

13. HI (MNID, GRE key)

14. HAck (AT’s IPv4 or IPv6

address, GRE key, QoS)

20. HI (code=buffer request)

Data Data41. Data

PCRF


PDSN





34. A11 RRP

22. Data

38. Buffered Data

23. IOS Signaling


26. IOS Signaling

36. HI (code=transfer request)

Buffered Data

39. HI (code=transfer

complete)

21. HAck

37. HAck

40. HAck

Figure 16 PMIP based UMB to HRPD Interworking using AGW-PDSN Interface (AGW buffering)

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


The steps in Figure 16 are described below. Step 1 through step 19 are same as Figure 15 .

20. By triggering step 19, the PDSN sends a HI message (see [7]) as a request of AGW buffering.

21. The AGW responds with a HAck message.

22. Data flows from the HA/LMA to the PDSN. The AGW buffers the packets for the AT until it receives a transfer confirmation massage from the PDSN.

Step 23 through step 26 are optional (see [19]).


24. The target RAN sends an A11-Registration Request message with AirlinkRecord=Setup to the PDSN.








32. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and performs HRPD Traffic Channel Complete and IOS procedure with the target RAN. (See [19])




36. By triggering step 33, the PDSN sends a HI message (see [7]) as a confirmation to the AGW in order to indicate that the AGW can send buffered data to the PDSN at this point.

37. The AGW responds with a HAck message.

38. The AGW sends buffered data to the AT via the PDSN.

39. The AGW sends a HI message to the PDSN as a completion of transferring buffered data.

40. The PDSN responds with a HAck message.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


41. The AT sends/receives data via PDSN, AGW and HA/LMA.

42. The PDSN may send a PMIP Registration Request message or PMIP Binding Update message to the HA/LMA by triggering step 39. If the PDSN has not received A10 Xoff before this step, the PDSN shall send a PMIP Registration Request message or PMIP Binding Update message to the HA/LMA by triggering step 33.


44. The HA/LMA responds with a PMIP Registration Reply message or PMIP Binding Acknowledgement message.

45. After step 44, data flows between the AT and HA/LMA through the PDSN.

9.6.2 PMIP Based Call Flow for Active Handoff through HRPD RAN-Lite

Figure 17 illustrates an example call flow for PMIP based UMB to HRPD interworking through HRPD RAN-Lite without context transfer.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


ATUMB eBS/

SRNCHRPD RAN/RAN-

LitePMIP

HA/LMA

Data

2. Data Data Data

AGW AAA






25. Accounting Stop



12. Access Accept (HA/LMA IP address)



8. A11 RRP


9. PPP LCP phase

17. A10: Xoff






13. PPP NCP phase

Data31. Data

PCRF


PDSN





28. A11 RRP

30. Buffered Data


Figure 17 PMIP based UMB to HRPD Interworking

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60



1. The AT communicates with UMB network. In UMB network, the AT acquires the IP address through the PMIP based IP address assignment.

2. Data is being sent between AT and HA/LMA through AGW.

3. AT detects the edge of UMB network by finding a HRPD channel through the UMB over-the-air overhead message. The AT obtains the Sector-ID of the neighboring HRPD AN.


5. The AT establishes an HRPD session with HRPD RAN-Lite.

6. The AT establishes PPP session with HRPD RAN-Lite to authenticate the AT with A12 interface.

7. The RAN-Lite sends an A11-Registration Request message with AirlinkRecord=ConnectionSetup to the PDSN, including MEI (Mobility Event Indicator) and tunnel operation indicator.

8. Once the A11-Registration Request message is validated, the PDSN accepts the connection by returning an A11-Registration Reply message with an accept indication. The A10 connection binding information at the PDSN is updated to point to the RAN-Lite.

9. The AT performs PPP LCP phase with the PDSN.

10. The AT performs PPP authentication phase such as PAP and CHAP with the PDSN.

11. The PDSN sends an Access Request message including NAI, IMSI, etc. to the AAA.

12. The AAA sends an Access Accept message including HA/LMA address which is the same as UMB network to the PDSN.

13. The AT and PDSN perform NCP negotiation. AT includes its IP address during NCP negotiation and PDSN accepts the AT IP address if the UMB IWK was received in A11 RRQ during step 7. In this case, PMIP RRQ/BU is not sent from the PDSN during PPP negotiation until XOFF is received.




16. The AT performs HRPD Route Update and Connection Setup procedures with the HRPD RAN-Lite. (see [19])

17. The RAN-Lite performs flow control with the PDSN through A10 Xoff to indicate that the PDSN buffers the data.

18. The PDSN sends a PMIP Registration Request message or PMIP Binding Update message to the HA/LMA triggered by step 17 if tunnel operation indicator was received and HI/HAck was not performed.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60



20. The HA/LMA responds with a PMIP Registration Reply message or PMIP Binding Acknowledgement message. Data flows from the HA/LMA to the PDSN. The PDSN buffers the packets for the AT until it receives an A11-Registration Request message with AirlinkRecord=ActiveStart.






26. After sending the ConnectionClose message on UMB, the AT tunes to the HRPD and performs HRPD Traffic Channel Complete and IOS procedures with the target RAN. (See [19])




30. The PDSN sends buffered data to the AT.

31. The AT sends/receives data via PDSN and HA/LMA.

Figures below provide additional details for PPP IPCP and IPv6CP exchanges occurred in Figure 17 . Figure 18 is for IPv4 addressing and Figure 19 is for IPv6 addressing.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


Figure 18 IPv4 Addressing


13a. The AT sends PPP/IPCP Configuration Request and includes its IPv4 address in the IP Address Option.

13b. The PDSN sends Configuration Ack and includes the same IPv4 address in the IP Address Option.

18. The PDSN sends a PMIP Registration Request message or PMIP Binding Update message to the HA/LMA including IPv4 address.


20. The HA/LMA check the received IPv4 address and for the case of the successful registration responds with a PMIP Registration Reply message or PMIP Binding Acknowledgement message including the same IPv4 address.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


Figure 19 IPv6 Addressing


13a. The AT sends PPP/IPv6CP Configuration Request and includes its Interface Identifier in the Interface-Identifier Option.

13b. The PDSN sends Configuration Ack and includes the same Interface identifier in Interface-Identifier Option.

18. The PDSN sends to the HA/LMA a PMIP Registration Request message including AT’s interface identifier in IPv6 Prefix option or PMIP Binding Update message including AT’s interface in MN Interface ID Option with.


20. The HA/LMA checks the binding entry for the received NAI and interface identifier and for the case of the successful registration responds with a PMIP Registration Reply message or PMIP Binding Acknowledgement message including the IPv6 prefix associated with the received NAI and interface identifier.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


20a. PDSN sends Router advertisement to the AT including the received IPv6 prefix.

9.6.3 PMIP Based Approach Active Handoff from HRPD to UMB through UMB RAN-Lite/eBS

Figure 20 illustrates an example call flow to show PMIP based approach for HRPD-UMB handoff. In this call flow, PMIP is used in both HRPD network and UMB network.

ATHRPD RAN

UMB RAN-Lite/eBS

HAeBS1

Data Data


PDSN

18. Connection Release

AGW AAASRNC

3. UMB RAN-lite/eBS ANID Advertised

7. PMIP RRQ

8. PMIP RRP

11. AT or HRPD RAN decides to handoff to UMB

14. PMIP RRQ

16. PMIP RRP

17. DHCPACK with Rapid Commit

19. A11 Signaling Message

21. DHCPACK with Rapid Commit, or other data

DNS server

20. AT tunes to UMBand selects eBS1 as FLSE and eBS1 sends IPT notification to Route Set members

12. AT adds eBS1 in Route Set and perform Key Exchanges (see IOS)

5. LinkIDAssignment

6. DAPMoveRequest

9. DAPAssignment

13. DHCPDISCOVER with Rapid Commit

23. PMIP RRQ

24. PMIP RRP

22. DAPMoveRequest

25. DAPAssignment

26. IPT-Notification

26. IPT- Notification

15.Authentication

DataData

Data

10. IOS Signaling

IWSF

4. Session Pre-setup (see Call Flow 9.3)

1. AT starts from HRPD (AT Obtains Domain Name through DHCP and Simple IP Address through network PMIP)

Figure 20 PMIP Based Approach HRPD-UMB Handoff

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


1. The AT communicates with HRPD network. In HRPD network, the AT acquires Domain Name and simple IP address during IP address assignments.


3. The AT detects existence of the UMB network by finding an advertised UMB pilot in the HRPD AN air interface overhead message. The AT obtains the ANID of the UMB RAN-lite/eBS. Alternatively, the AT can also periodically search for UMB pilots.

4. The AT performs session Pre-Setup as specified in the call flow in section 9.3. The AT performs UMB session establishment with the UMB RAN-lite/eBS and authentication with the SRNC if the UMB session does not exist or cannot be retrieved by the UMB RAN-lite/eBS. Otherwise, the UMB RAN-lite/eBS retrieves the UMB session from the SRNC. The UMB RAN-lite/eBS also becomes the FLSE for the AT and sends IPT-Notification (FLSE) message to the SRNC. Refer to [39] for details of the UMB session establishment.

5. UMB RAN-lite/eBS assigns a LinkID for the AT so that the AT can start IP services on UMB.

6. Upon assignment of the LinkID, if the AT is configured to use AT-assisted DAP handoff, the AT sends a DAPMoveRequest message to the UMB RAN-lite/eBS to trigger initial PMIP tunnel setup with the AGW. If the AT-assisted DAP handoff is not configured, UMB RAN-lite/eBS autonomously continues the following step.

7. The UMB RAN-lite/eBS sends a PMIP-Registration Request message to the AGW to initiate PMIP tunnel setup.

8. The AGW sends a PMIP Registration Reply message to complete PMIP tunnel setup with UMB RAN-lite/eBS, which is now the DAP for the AT.

9. The UMB RAN-lite/eBS sends a DAPAssignment message to the AT.

10. The UMB RAN-lite/eBS sends an IOS message to the SRNC to indicate it is the current DAP.

11. Either the AT or the UMB RAN-lite/eBS decides that it is preferable to handoff to UMB.

12. If the UMB RAN-lite/eBS decides handoff, the UMB RAN-lite/eBS sends RouteCreate message to trigger the AT to create a route to eBS1. If the AT decidse handoff, the AT sends a RouteOpenRequest message to the eBS1, via the tunnel through UMB RAN-lite/eBS.

13. The AT sends DHCPDISCOVER with Rapid commit option to the AGW.

14. The AGW sends PMIP RRQ to the HA.

15. If the HA doesn’t have the latest PMN-HA key, the HA performs authentication with HAAA through AAA messages. The HAAA returns PMN-HA key to the HA.

16. The HA sends PMIP RRP to the AGW.

X.S0054-610-0 v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


17. The AGW uses the PMN-HA key to verify the MN-HA Authentication Extension in the PMIP RRP message. The AGW sends a DHCPACK message with the Rapid Commit option to the AT.

18. The AT sends a Connection Release message to the HRPD RAN. The AT does not need to wait for DHCPACK.

19. The HRPD RAN sends A11 signaling message to the PDSN (see [19]).


21. The UMB RAN-lite/eBS sends the buffered data (including DHCPACK) to the FLSE, which is the eBS1. The FLSE then forwards them to the AT.





26. The eBS1 sends IPT-Notification message to the all eBS in Route Set (SRNC and UMB RAN-lite/eBS) with the indication it is the new DAP. See [39].

UMB and HRPD/1x Interworking

Documents

Transcript of UMB and HRPD/1x Interworking